Help with interpreting log from CGX-L mount

[Stephen Pattinson]

Hi,

Ref log file - https://openphdguiding.org/logs/dl/PHD2_logs_IRPv.zip

I'm relatively inexperienced with PHD2 & guiding, and my Celestron CGX-L mount is pretty new too, but from my examination of the PHD2 log using the PHD2 Log Viewer, and just watching the RA & DEC variations when logging, the guiding and perhaps the performance of the mount does not seem up to expectations. I don't however really know what to expect, so some experienced advice would be great.

Relevant equipment is a ZWO 280mm guide scope with an ASI178MC OSC camera mounted on a CGX-L mount. The imaging equipment is current a C9.25 in the Hyperstar config (FL 540mm) with an ASI071 camera.

Log section (ie as shown by the Log viewer program) shows the calibration. This I think looks ok to my untrained eye. See also attachment Phd2Cal.png.

There are two log sections where I have run the guiding assistant, sections 5 & 6. The attached file GuidingAssist4.png captures the screen at the end of the section 5 guiding assist. Unfortunately I failed to capture the screen at the end of the section 6 guiding assist, however, in that case, I did get a figure for backlash (unfortunately not noted at the time)

In both the guiding assistant runs, the Dec performance seems okish, but the RA deviates a long way before the guiding re-commences and it's yanked back to the correct position. In run 5, the RA deviates about 30" in 12 minutes, and in run 6, the deviates about 13" in about 134 minutes in the other direction. Is that reasonable? Does it indicate a hopeless RTC in the mount?

Perhaps the long term drift may be compensated by PHD2, but the RA performance seems to have other issues.  There is a significant short term variation of about 2-3" p-p at about 21.3 hz according to the frequency analysis. This is admittedly only a couple of pixels, but reading other posts, it does seem high. 

Using a 4sec samples, I don't think this is seeing, but maybe it is? Could my use of an OSC camera as the guide camera be causing problems?

Presumably the variation at about 400 seconds or so is periodic error. I can't find a reliable number for the RA gear period of this mount. It may be different to the CGX. I guess the periodic error is correctable, but it seems to be swamped by the larger long term variation.

At the end of the guiding assistant run 6, I did accept the recommendations. Section 11 shows an actual guiding session about half an hour long.

The RA performance seems pretty awful. Is this typical. I see lots of suggestions that the RMS error should be less than 1". There also appears to be uncorrected periodic error, but it's the jagged nature of the RA position that concerns me most. 

So, some general or maybe specific advice would be welcome. Is this reasonable or have I got a serious problem.

Thanks very much.

Cheers

Steve

[bw_msgboard]

Hi Steve, welcome to the group.  Thanks for taking the time to look at this yourself and provide all this context.  Since you asked some specific questions, I’ll answer them in-line and then I’ll make some suggestions at the bottom.

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Stephen Pattinson
Sent: Friday, November 29, 2019 1:35 AM
To: Open PHD Guiding
Subject: [open-phd-guiding] Help with interpreting log from CGX-L mount

Hi,

 

Ref log file - https://openphdguiding.org/logs/dl/PHD2_logs_IRPv.zip

 

I'm relatively inexperienced with PHD2 & guiding, and my Celestron CGX-L mount is pretty new too, but from my examination of the PHD2 log using the PHD2 Log Viewer, and just watching the RA & DEC variations when logging, the guiding and perhaps the performance of the mount does not seem up to expectations. I don't however really know what to expect, so some experienced advice would be great.

 

Relevant equipment is a ZWO 280mm guide scope with an ASI178MC OSC camera mounted on a CGX-L mount. The imaging equipment is current a C9.25 in the Hyperstar config (FL 540mm) with an ASI071 camera.

 

Log section (ie as shown by the Log viewer program) shows the calibration. This I think looks ok to my untrained eye. See also attachment Phd2Cal.png.

 

Yes, the calibration looks fine.  As a general rule, if the calibration completes without significant alert messages, it should be fine.  You can help things a long a bit with your mount by manually clearing the Dec backlash right before you start the calibration.  You can do this by briefly slewing north or using the hand-controller to move the scope north at guide speed until you clearly see the stars moving in the PHD2 display.  You did encounter a number of lost-star events during calibration which is not a good thing although not a big problem in this case – more on that below.

 

There are two log sections where I have run the guiding assistant, sections 5 & 6. The attached file GuidingAssist4.png captures the screen at the end of the section 5 guiding assist. Unfortunately I failed to capture the screen at the end of the section 6 guiding assist, however, in that case, I did get a figure for backlash (unfortunately not noted at the time)

 

All of this info is in the logs, so you don’t need to worry about recording these results or doing screen-shots.  Screen shots are usually unnecessary unless you’re looking at a very specific thing that you want us to see.

 

In both the guiding assistant runs, the Dec performance seems okish, but the RA deviates a long way before the guiding re-commences and it's yanked back to the correct position. In run 5, the RA deviates about 30" in 12 minutes, and in run 6, the deviates about 13" in about 134 minutes in the other direction. Is that reasonable? Does it indicate a hopeless RTC in the mount?

 

Nothing hopeless here.  Remember, during a guiding assistant (GA) run, guiding is disabled so you’re looking at the unaided tracking behavior of your mount, warts and all.  That’s why the guide star is “yanked back” to its starting location, it’s just a consequence of guiding being turned on again. You have quite a bit of drift here because of your polar alignment error, but the RA data you’re looking at is the sum of the drift and uncorrected periodic error.  

 

Perhaps the long term drift may be compensated by PHD2, but the RA performance seems to have other issues.  There is a significant short term variation of about 2-3" p-p at about 21.3 hz according to the frequency analysis. This is admittedly only a couple of pixels, but reading other posts, it does seem high. 

 

The best view of your RA mount behavior is in guiding session 11 and it clearly shows the periodic error situation:

 

 

 

You probably want to find a way to program a periodic error correction into the mount.  I don’t know what the worm period is on this mount, I thought most Celestron mounts had a period of 478 seconds.  The high-frequency error at 21 sec is definitely a headache and is unfortunately well-known for some of these mounts.  It’s too fast to be guided out and I don’t know if people have found mechanical solutions for it.  Peter Wolsley is on the forum here and he has an in-depth understanding of these Celestron drive systems so he will hopefully offer his opinions.

 

Using a 4sec samples, I don't think this is seeing, but maybe it is? Could my use of an OSC camera as the guide camera be causing problems?

 

I think the guide camera is exacerbating a lot of the problems.  You’re getting too many lost-star events and even with long guide camera exposures, the SNR is fairly meager.  You’ll notice the GA recommendations said to re-examine the focus on the guide camera.  If the guide camera isn’t critically focused, PHD2 is going to be working large, mushy guide star images and the guiding will suffer.  Using an OSC for a guide camera is generally not a good idea although it can obviously be done.  The Bayer filters on the sensor really reduce the overall sensitivity.  All of this pushes you in the direction of longer guide exposure times, but your mount probably won’t tolerate that.  You probably need to be done in the 1-2 sec range of exposure times in order to help tame the RA tracking error you have.  One thing you can do to reduce some of the lost-star events is to disable the ‘star mass detection’ feature in PHD2, it’s not helping you at this point. (Advanced Dialog/Guiding tab).

 

Presumably the variation at about 400 seconds or so is periodic error. I can't find a reliable number for the RA gear period of this mount. It may be different to the CGX. I guess the periodic error is correctable, but it seems to be swamped by the larger long term variation.

 

At the end of the guiding assistant run 6, I did accept the recommendations. Section 11 shows an actual guiding session about half an hour long.

 

The RA performance seems pretty awful. Is this typical. I see lots of suggestions that the RMS error should be less than 1". There also appears to be uncorrected periodic error, but it's the jagged nature of the RA position that concerns me most. 

 

Session 11 is not a great estimator of your performance because you were pointing too low in the sky.  You started with a pointing altitude of 29 degrees, so you were down in the seeing weeds, shooting through 2x the atmospheric mass.  Even so, the RA tracking performance is clearly your limiting factor at this point.

 

So, some general or maybe specific advice would be welcome. Is this reasonable or have I got a serious problem.

 

Just to recap then:

1. Try to insure you have a critical focus on the guide camera.  The “Star Profile” section in the Help guide describes one approach to this although other techniques also work. You should probably be trying for HFD star values that are 3 or below – yours were over 5 in this log.
2. Try to reduce your exposure times down to the 1-2 second range while getting lost-star events.  You may need to consider upgrading your guide camera to avoid the color sensor limitations.
3. Look into doing a periodic error correction on the mount.

 

Hope this helps,

Bruce

 

Thanks very much.

Cheers

Steve

 

 

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/9c5b05c2-6bb0-4d8b-abec-7beecd1f9201%40googlegroups.com.

[Norman McCall]

Hi Steve,

 

I too own a CGX-L mount.   One issue I notice in your data is the same 21.4 second harmonic in RA that I had in mine.  (See attached frequency analysis from the PHD2 Log Viewer tool.)  Note, this was the analysis from your Guide log dated 2019-11-29 section 11 when guiding for 32m & 53 sec.

 

This harmonic has its source in the RA drive train.  Essentially given the 300 second time period of the RA worm gear which when divided by 21.4 one gets a occurrence of 14 times per worm cycle. 

 

In visually studying the mechanics of RA drive train I noticed that this is the exact number of teeth on the drive sprockets.  Upon close inspection of the drive belt as the mount slowly turned (via the HC), I observed the  issue is caused by a stretched timing belt in which the pitch of the timing belt is longer than the pitch of the sprocket on the drive motor.  As the timing drive belt meshes with the sprocket as each tooth snaps into the sprocket it pulled the belt causing uneven (spike) movement in RA and hence the observed spike in the charts.  As you are operating at F/2.2 or so, this movement will be less evident in your pictures. For me at f/7.0 it was a significant problem. 

 

I purchased a quality replacement timing belts for both RA & Dec.  BTW, the belt is 10mm wide with T2 (5mm) pitch and 165mm long having 33 teeth.  It is described by vendors as model PN: 10T5/165.   The belt I purchased had stainless steel mesh was highly flexible and did not stretch! (Unlike the low cost rubber one supplied on the mount.)   To install them, I actually sent the unit back to Celestron who installed my replacements and tuned the mount under warranty.  Unfortunately I have not yet tested the fix as I’ve been running my old mount in my Obs and did not want to take the time to reinstall my CGX-L. (BTW,  I will know the results in the next month or so.)

 

Hope this is helpful.

 

Norm

 

From: open-phd...@googlegroups.com <open-phd...@googlegroups.com> On Behalf Of Stephen Pattinson
Sent: November 29, 2019 4:35 AM
To: Open PHD Guiding <open-phd...@googlegroups.com>
Subject: [open-phd-guiding] Help with interpreting log from CGX-L mount

 

Hi,

--

[Stephen Pattinson]

Hi Bruce,

Thank you for the detailed and informative reply.

I know I'm slightly pressing my luck with the colour camera, it' one I have for planetary. It does have really small pixels however (2.4um), but I'll take your advice about getting a mono camera and paying more attention to focus etc. 

I gather you didn't think the unguided performance was really really bad, but I note the comments from Norman McCall about the possible reason for the 21.4 second harmonic. I shall have to follow that up.

Session 11 was low in the sky, about 20degrees. I was trying to photograph M1 which was pretty low. Should have mentioned that I'm in Australia! I think the guiding assistant run was done at a higher altitude however.

Anyway, I'll take your advice, and when I've done that, I'll maybe post again and get some more feedback.

Thanks again

Rgds

Steve

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd...@googlegroups.com.

[Stephen Pattinson]

Bruce,

I forgot ask in my reply. I gather you did not see a huge problem in my PHD2 settings. Why wouldn't guiding completely remove the effect of periodic error?

Thanks again

Steve

[Stephen Pattinson]

Hi Norman,

Thanks for taking an interest in my post. Your analysis of the reason for the 21.4 sec spike sounds very convincing, and somewhat disconcerting. Sending the mount back to Celestron is a bit problematic for me, being in Melbourne Australia, but the local distributor may be able to service the mount. I didn't expect this sort of problem.  Whilst I am operating at F/2.2 at the moment, I also have the 0.63 reducer when imaging in the more conventional way, and certainly it would be more of a problem then.

I'd certain like to see how your belt replacement goes, although I'm not sure I can wait a month or so.

How did Celestron feel about using  3rd party belts?

Thanks and rgds

Steve

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd...@googlegroups.com.

[bw_msgboard]

Hi Steve.  The PHD2 guider settings generally take care of themselves unless you’ve entered the wrong information into the new-profile-wizard (yours are fine).  You’re in the situation that many beginners encounter, your guiding results are being limited by the capabilities of your mount.  Whether this actually limits your imaging results is a different question, something only you can determine.  I would say, if you’re taking an engineering perspective and expect to see excellent mechanical performance from your mount, you may not be happy with anything in this price range.  

 

With regard to periodic error, this is *approximately* what the native tracking behavior of the mount looks like:

 

 

 

It’s approximate because it’s an imputed curve from the session 11 guiding period, which as I said before was done in a poor part of the sky.  If you do a GA run over a time interval that covers a couple of worm periods, you’ll get a direct measure of the PE.  Anyway, this looks like a peak-peak PE of somewhere between 20 and 35 arc-sec, which is pretty poor.  I don’t know what you should expect from the mount but I’ve seen commentary elsewhere to suggest it’s worse than expected.  If we now look at the guided performance for the same session, we see this:

 

 

So PHD2 guiding has reduced your 20-35 arc-sec periodic error to something that looks more like 5-7 arc-sec.  And in this view, many of the large variations in RA are no longer occurring at the worm frequency, they are much more rapid.  I think this is about all you can expect from reactive guiding algorithms, and a 4-5x improvement seems pretty good to me. Your next step should clearly be to get a good periodic error correction programmed into the mount.  In the meantime, you could try the PHD2 predictive PEC algorithm (PPEC), giving it an initial period length of 300 seconds.  That should improve the RA guiding, with or without PEC programmed into the mount.

 

I’m also attaching a long-winded explanation of what PEC really is and how it’s different (and complementary to) the PHD2 PPEC algorithm.

 

Good luck,

Bruce

1.      Try to insure you have a critical focus on the guide camera.  The “Star Profile” section in the Help guide describes one approach to this although other techniques also work. You should probably be trying for HFD star values that are 3 or below – yours were over 5 in this log.

2.      Try to reduce your exposure times down to the 1-2 second range while getting lost-star events.  You may need to consider upgrading your guide camera to avoid the color sensor limitations.

3.      Look into doing a periodic error correction on the mount.

 

Hope this helps,

Bruce

 

Thanks very much.

Cheers

Steve

 

 

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/9c5b05c2-6bb0-4d8b-abec-7beecd1f9201%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/8926cbe8-a136-441c-bacb-5dc406bc93f4%40googlegroups.com.

[Stephen Pattinson]

Hi Bruce,

Thanks again. One more question.

I haven't found a definitive statement about where in the sky to do a/ calibration & b/ get representative GA result. Perhaps you could suggest.

Thanks

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/8926cbe8-a136-441c-bacb-5dc406bc93f4%40googlegroups.com.

[bw_msgboard]

https://openphdguiding.org/phd2-best-practices/

 

Or in the help file under ‘Automatic Calibration’ (4^th paragraph):

 

https://openphdguiding.org/manual/?section=Basic_use.htm#Automatic_Calibration

 

If you’re way the heck south in Australia, the pointing position for Dec=0 might be low in the sky.  If so, you can move the scope further south to improve that situation, down to Dec -20 won’t have any effect.  For you, it may be a trade-off between seeing and proximity to Dec = 0.  All of this is equally true for the GA run although there’s less sensitivity for the GA.  You don’t want to do GA runs at low sky altitudes, again because of the seeing.

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/c8fd3cac-ee4f-41e4-b982-c23f162e7e56%40googlegroups.com.

[peter wolsley]

Stephen,
I am a Celestron CGEM owner so I don't have any experience with the CGX but there are things w.r.t. Celestron that I have studied a lot. I looked at your guiding log and I believe your DEC axis has roughly 33 arc-seconds of backlash.  At 75% autoguiding gain this works out to 2,933mS for your backlash comp pulse. I think you can increase your backlash comp pulse up to 2500mS to see if this helps your DEC guiding.  You may also try using 100% autoguiding gain which will lower the required 2,933mS down to 2,200mS.

Your biggest priority is to improve your RA guiding but only if you want to image at larger focal lengths than 540mm (C9.25 hyperstar config).  I don't know what your imaging scale is for this config but if your stars are not oval blobs then you may be ok for now.  It's always what the image looks like that decided if you need to improve.

I am going to assume that you want to put that ASI071 on the back-end of your C9.25 and image at 2000+mm.  To accomplish this you will need to deal with the 21.6 second oscillation your are seeing in your RA guiding.  There is lots of chatter on the Cloudy Nights forum about the belt drive system on the CGX and how to improve it.  I think this is in the cards for you to pursue.  

Bruce has already mention that your guide camera needs to be better focused.  A HFD around 3 is a better solution.  Your guider cam pixel scale of 1.77a-s/px is great.  I guide with a pixel scale of 6a-s/px which takes care to maintain.  Bruce also mentioned that you will most like need to change your exposure time from 3,500mS to 1,000mS.  This will give PHD2 a better chance at controlling this 21.6 second oscillation which should reduce the total RMS error for your guiding.

The other point that Bruce mentioned was that you need to look into training your mount's PEC.  There may be some CGX owners on this site that can help you with this.  There are some youtube videos as well.  The Celestron software available to train your mount's PEC is called PECTool. AFAIK this is the only Celestron product that can be used to train your CGX's PEC.  There is also a 3rd party program called PEMpro which can be used to train your CGX's PEC.  I believe your RA axis has roughly 25 arc-seconds of periodic error.  If you are successful in training your mounts PEC you will see an improvement in your RA guiding.  On the Cloudy Nights forum there are CGX users claiming they can achieve 1a-s total RMS guiding when they have both solved the 21.6second belt drive issue and trained their mount's PEC.

I have used PECTool with my CGEM  Here are some comments regarding how to use PECTool.
PECTool is a very old program which can be downloaded from the Celestron site.  Installing it is tricky because it will fail to install and direct you to the windows compatibility troubleshooter.  If you select win7 or winXP compatibility it will install in win10.
PECTool does not understand ASCOM at all.  It assumes that it can either talk to the mount directly thru a COM port or thru an additional program called NexRemote. I don't know if NexRemote is compatible with the CGX.  I assume it's not compatible.  This creates some issue which you will need to address as a "one-off configuration" to get the PEC training done.

Here are the steps to run this "One-off" PEC training. This is a great task to perform when the moon is full and taking photos is not on the job list for the evening. 
This is best done by creating a new equipment profile.  You will need to connect an ST-4 cable between your guide camera and your CGX mount.   You are going to change the configuration on the Connect Equipment window so that for Mount is says On-camera.  For Aux Mount you should specify None. Doing this causes PHD2 to send the guiding commands to your guide camera ZWO ASI178MC.  This will cause the guiding commands to be present on the ST-4 connector on this camera.  The ST-4 cable will then pass these guiding commands to your CGX.   This also causes PHD2 to not use ASCOM to communicate to your mount.  Be aware that PHD2 will not know what the RA and DEC values are so you will need to calibrate after every time you perform a GOTO.  You can get these modifications done during the day.

Beginning PEC training after sunset.
Position your mount on a suitable calibration star using whatever software you prefer.  Do not run PECTool yet.  Fire up PHD2 and connect to your guide camera using this PEC training profile.  Have PHD2 calibrate and begin guiding.
Now close all of the software you have running that is connected to your CGX via ASCOM.  Once you have this done, PHD2 should continue guiding and you should notice that the Celestron ASCOM driver is no longer active.  This is important because if the Celestron ASCOM driver is running then PECTool will not be able to connect to the mount.
Now you can fire up PECTool.  Once PECTool is running select the correct COM port that is connected to the CGX and click the connect button.
If there are no errors your next step will be to click on the Seek Index button.  Seeking the index will move the mount's RA axis enough that PHD2 will stop guiding and generate an error.  Once the Seek Index function finishes it will move the mount back to where it started which should allow you to resume guiding once again.

Whew!  If you have gotten this far then you should have PECTool talking to your CGX and PHD2 should be happy guiding.  Now click on the PECTool File tab and select Batch Training.  Now Select Star at: 1 and Runs: 6 or more...the more the better but realize that 10 runs will take roughly an hour.   Now click on the Start Batch Training button and let PECTool run.

Once PECTool is done the training run it will have saved files for every run and will be waiting to find out what to do next.  Click on the PECTool File tab and select Average.  This calls up a file dialog where you can select all of the training runs that were stored to disk.  Once the files are selected PECTool will average all of these runs and display the final result.  The last step to perform with PECTool is to now click the Upload Data To Mount button.  This will transfer the averaged PEC data to your CGX where it will be saved in EEPROM memory so that it will be available whenever the mount it powered up.

Once you are here you need to enable PEC playback using your mount's handcontroller.  This has to be done every time you power up the mount.  You will also need to seek the index every time you power up the mount. 

It's a lot of work but it will improve your guiding.

Peter

[Stephen Pattinson]

OK - Thanks again.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/c8fd3cac-ee4f-41e4-b982-c23f162e7e56%40googlegroups.com.

[Stephen Pattinson]

Hi Peter,

Thank you for all your wonderful advice. I'll try your suggestions re the backlash number next time I get out with the rig. Also,  I actually orderd a mono camera today. It will be nearer 2"/pixel, but still ok I think. 

As you say, the biggest problem is the RA guiding and that 20sec oscillation. I'll check out the discussions on Cloudy Nights you suggest. Also, your right, I do want to put the camera on the conventional end of the scope and image at F/10 or at least at F/6.3 with the reducer, so I need to get that sorted . At F/2.2, the stars are pretty round anyway. An OAG is on my Christmas list!

I am aware of the PECTool and I've trained my older AVX with it some time back, but I haven't been able to get it to talk to the CGX-L. After reading your post, I was determined to give it another go. The problem turned out to be the com port. The prolific driver selected Com14, but the PECtool only works with the low numbers, COM1..4 I'm guessing. Anyway it's working now so I shall train the PEC as you suggest. Really annoying to have to use ST4 guiding for that, I'm not even sure what I did with that cable. Thanks for the detailed instructions.

Many thanks

Steve

[Norman McCall]

Hi Steve,

 

Celestron said it would take 5 weeks for them to get a replacement.  (And it would cost be the same low-cost clone.) The original belt was made of rubber with a few cotton internal thread and subject to stretching due to over tension. 

 

The polyurethane replacement belt would not stretch at all and therefore requires the gear mechanism to be loosened off then tightened once the belt was installed on the sprocket.  The old one meanwhile can be stretched off/onto the sprocket with relative ease. 

 

To my surprize they had no issue replacing it with the one I supplied.  To me it is sad that they would risk using a low quality clone timing belt in their high-end mount which is specifically rated to carry a C14 EdgeHD scope for use in astrophotography. But I guess that is all one gets for a product made in China where they do anything to save a dollar.  

 

Here is a link to a typical replacement belt:  https://beltzoom.com/products/10t5-165ug-synchro-link-trapezoidal-metric

 

BTW, I’m delayed from the testing the CGX-L since I want to put a PEC table into my iEQ45 PRO portable mount and in ON, Canada there are very few clear night right now. 

 

I will post the results when they are available. 

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/ae4e4e74-47ad-4fe2-a16a-1368391420a7%40googlegroups.com.

[JohnS]

A warning about tightening belts on the CGX range of mounts.  I'm a CGX owner and I've become aware that you can run into problems with the gearboxes on these mounts after tightening the belts.  The bearings are simple and without any kind of rollers.  The shaft is pulled in the direction of the worm drive and over a fairly short period wears into the softer metal of the bearing.  There are a few cases of owners running into this problem online and I've battled for two years to improve the guiding results with mine.  I have a noticable off centering of the shaft on both the RA and Dec motors on mine.  The adjustments vary with temperature variations over the changing seasons and it's a case of readjusting over and again to get results you can live with.  The design seems to be workable (and it's quite simple) but Celestron just haven't used quality parts.  This may be why they used a stretchy belt in the first place in order to take the pressure of the bearings and make the whole thing work.  I envy you guys who are in the USA - I'm in New Zealand where Celestron doesn't have any kind of real presence.  They won't sell parts separately and my only option is to return the mount to the USA for any kind of repair or servicing at my own cost with resulting lack of facility for many months. 

JMTC

John Smith

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/ae4e4e74-47ad-4fe2-a16a-1368391420a7%40googlegroups.com.

[Stephen Pattinson]

Hi Norman. Thanks for the additional information. I'll checkout those links. Cheers Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/ae4e4e74-47ad-4fe2-a16a-1368391420a7%40googlegroups.com.

[Stephen Pattinson]

Hi John,

I'm actually in Australia. I'm not sure what the situation here is with respect to service. I'll try all the good suggestions I've received on this forum first and see what the result is image wise, and then decide what to do.

Cheers

Steve

[Stephen Pattinson]

Hi Peter,

I now have PECTool working after much mucking around. Turns out it only works on low com ports like COM1..4. Typical for such an old program. 

I have however also found out that you can do PEC training and turn playback on and off with the new CPWI tool as well, and what's more, stay with ASCOM guiding. Celestron support gave me the CGX-L worm guide period as well, it is 299.180870 seconds in theory. 299 should do in practice I'd say.

Thanks

steve

On Sunday, 1 December 2019 15:04:29 UTC+11, peter wolsley wrote:

[peter wolsley]

Stephen,

Good to know that you can do PEC training with CPWI via ASCOM.  My old CGEM is not compatible with CPWI unless I upgrade my handcontroller so I have never used CPWI.  I can use ASCOM with PECTools but it's because I can configure Nexremote to communicate directly to the mount and then have Nexremote provide a virtual port for ASCOM communications and configure PECTool to communicate directly to Nexremote.  Older vintage equipment use older tools.

Clear Skies

Peter

[Stephen Pattinson]

Hi Peter,

Yes indeed. It looked like it only did one trial though & it doesn't seem to show the curve. I'll ask on teamcelestron.com.

Rgds

Steve

[Stephen Pattinson]

Hi,

I have an interim result from some more testing. I managed to focus a little better, although since the mono camera has not arrived, I'm still using the ASI178MC. Cal and testing was done higher in the sky. Also, I managed to train the CGX-L PEC & get better polar alignment. All the runs in the attached log have PEC replay turned on.

Section 1 - Calibration - ok I think

Section 2 - 8 minutes of guiding. Large periodic error at 299 secs (RA period) is mostly gone, but the 21.4sec harmonic is still present despite 1sec exposures.

Section 3 - Guiding assistant run. The 20.4 s ra wobble is at about the same level, guiding or not.

Sections 4 - 11 are short tests varying the RA aggression, Hysterysis, MinMo etc. Runs 10&11 are even at 0.5sec exposure. There are small differences, but nothing significantly better.

When I set the exposure to 1 second as suggested, I expected that there would be the opportunity for 20 corrections during the period of the 21.4 ra wobble, but that doesn't seem to be the case as there are only roughly 8 or 9 pulses shown in this period. Have I done something wrong?

The 21.4 sec period is exactly the time for the RA belt to move 1 tooth, so I pretty convinced it's a belt issue. Also looking at some other results on cloudy nights, it seems others have exactly the same characteristic with this mount. I'm wondering why moving from the 4 sec exposures I was using originally to 1sec and every 0.5sec has not had a more beneficial effect on the ra wobble. I wonder if the mount just doesn't respond fast enough to corrections, and/or if the inherent delay either prevents the corrections from having the desired effect of even creates a +ve feedback problem.

Any further thoughts would be welcome.

Cheers

Steve

[Stephen Pattinson]

PS I just had a look at my PEC correction curve. It also shows the 20sec ra wobble even after averaging 5 runs. Since the 20sec wobble is not adequately corrected by guiding, the PEC correction may even be hindering the result. I'll post my 1sec guiding without PEC correction later today together with the PEC curve. 

Thanks Steve

[Brian Valente]

Hi Steve

 

If you are referring to the mount-based PEC, it doesn’t surprise me it won’t take care of a smaller harmonic like a 20 second period.

 

My G11T has a similar situation, where PEC takes care of the primary periodic error but leaves a 39 second secondary.

what I do is guide at 1 second exposure using the PPEC algorithm and I set the period of PPEC at 39 seconds and turn off the auto adjust period. It’s a bit of a brute force approach but it works surprisingly well for me. So just a thought for you

 

 

 

 

 

Thanks

 

Brian

 

portfolio https://www.brianvalentephotography.com/

--

You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/c5aaf353-4858-469e-9bd0-b375012f1b7b%40googlegroups.com.

[peter wolsley]

Stephen,

-You need to get the RA belt mod done before you are going to see any significant improvement.  The 21.4 second oscillation is far too dominant.

-You should be able to get faster pulse guide updates to your mount.  You have 1sec exposures selected but it is taking 2.5 seconds to complete the update.  The actual guide pulses are roughly 120mS so there is something slowing down this interface.  To troubleshoot this time delay we are going to need for you to upload the debug log as well as the guide log.  Typically Andy or Bruce are the best a troubleshooting communications issues.  They typically find that the camera is slow to provide the image to PHD2.  Have you selected sub-frames for your guide camera?  This will dramatically reduce the amount of data passing thru your USB ports which may reduce any data delays.  Your camera has a lot of pixels and to download all of them for each image when only a sub-set is required is not the best method.

-When you create your next guide log please try to get at least 30 minutes of continuous guiding,  It makes it easier to perform frequency analysis and to establish steady state performance.

Peter

[Stephen Pattinson]

Thanks Brian,

I'll try that. Thanks for taking an interest.

Cheers

Steve

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd...@googlegroups.com.

[Stephen Pattinson]

Thanks Peter,

The camera is USB3 and I can normally image planetary at it's full res at about 30fps, so I'm not sure what the trouble might be. I though there must be some setting or other that governs the guide rate other than the exposure setting. A communications issue would surprise me. 

Anyway, the mono camera arrived today, so at the weekend, I'll try again and fwd the debug log next time.

Cheers

Steve

[peter wolsley]

Stephen,

I'm glad your new camera arrived.  PHD2 uses a different strategy for obtaining images from a guide camera.  These cameras typically have a "video" method and a "stillframe" method.  PHD2 uses the stillframe method which has more overhead than the video method.  Remember that PHD2 is always trying to use longer exposures so that more stars are candidates for selection as the guide star.  The sub-frame option is available within PHD2 to reduce overhead.

Peter

[Stephen Pattinson]

Hi Peter,

OK, I'll check that out. 
The mono camera (ASI120MM-S) has significantly less pixels than the ASI178MC anyway, so maybe the problem will go away. Pixel size is bigger however, so I think I wind up with 2.5ish a-s/pixel. (Forget the exact number.) I did however give it a quick try last night and easily got a HFD of about 3, but then it clouded over and that was that. 

I'll have a go at the weekend again - clouds permitting.

Thanks

[peter wolsley]

Stephen,

I think you will be fine at 2.5a-s/px.  I use a much higher value and PHD2 guides without issue.  The other "benefit" of using a higher a-s/px scalefactor is that a typical calibration cycle will physically move your DEC axis further which, in some cases, allows the calibration logic to deal with larger DEC backlash values.  There are other ways of having PHD2 move your RA and DEC axis further during a calibration but the default calibration movement for PHD2 is 25 pixels per axis.  At 2.5a-s/px this works out to 62.5a-s which would be ideal for your CGX.

A HFD of 3 should be just fine.  I am looking forward to you seeing faster updates when using 1sec exposures.  Hopefully PHD2 will be able to take advantage of this faster update yielding tighter guiding.

Peter

[Stephen Pattinson]

Hi again,

I've had another go at guiding after putting the good advice I found here into practice.

1-Guide camera now ASI120MM-S (ie mono) 2.76 a-s/pixel

2-PEC corrected in mount

3-1 Sec guiding

4-Decent polar alignment

The log is attached (I found the upgrade tool in PHD2 confusing in respect of identifying the correct log)

The following sections are relevant

Section 3 - Calibration - Seems pretty good

Section 6 - Guiding assistant.  Shows whooping big (20"p-p) periodic error corresponding to 299s RA period and the annoying 21.4sec variation of about 2.5"p-p.

Section 8 - Guiding assistant with PEC corrections in mount. 299 sec periodic error much reduced.

Section 9 - Guiding at 1sec with PEC corrections.  The long term errors are totally suppressed. The 21.4 sec variation is still apparent, but reduced quite a bit. 0.78" rms although still about 3"p-p.

Maybe this is about as good as I am going to get without addressing the problem with the belt? Is this an ok result? 

At 540mm (hyperstar) on the main scope, I don't think there is a problem, but at the full SCT F/10 2300mm, it could be another story. One second guiding may be ok with the F/4.6 guide scope I'm currently using, but at F/10 (or even F/6.3 with reducer) and changing to an OAG, I may have trouble getting a bright enough star some of the time.

The PEC correction was quite instructive. I conducted 5 PEC training runs with the old Celestron PECTool. (This was done earlier with the old colour camera, and 2ish sec corrections - the suppression of the 21.4s wobble was marginal or non-existent) . The runs are plotted in Excel (see attachment). The red line is the average. The most striking feature to me is the repeat-ability of the 21.4s wobble, it's not even slightly reduced by averaging. Last week when I used this as PEC correction, the results were not promising. Since the correction of the 21.4s wobble was not good, the 21.4s wobbles in the PEC curve are out of synch with the actual error. This week, I fitted a 6th order curve to the PEC error (the black dotted line), and wrote that back to the mount. The result is the run in Section 8 referred to above with suppresses the 299sec periodic error without adding to the faster problem. 

Given then repeat-ability of the 21.4sec issue, it does occur to be that maybe it could be nulled out. I think I'd need to run the PECTool (or maybe PemPro) without corrections, and isolate the 21.4s signal. This is not really a PHD2 issue of course, so sorry for the digression.

Rgds

Steve

[Brian Valente]

Hi Stephen

 

Things look better

 

The main challenge you have right now is your RA (as you’ve pointed out), but more specifically your RA is about 2x your DEC RMS, so I recommend looking at your stars closely and checking for eccentricity (roundness). I’m guessing they are a bit oblong

 

One thing you can try regarding improving the 21 sec is using PPEC algorithm on your RA

 

Set the period to 21.9 and turn off auto  adjust period

 

Keep guiding around 1 sec – maybe experiment between 0.5 and 1 sec

 

You are going to be on the cusp of chasing seeing but also trying to tame this short period.

 

I’ve had good luck with this approach and a 39 second harmonic periodic error

 

 

 

Thanks

 

Brian

 

portfolio https://www.brianvalentephotography.com/

 

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of Stephen Pattinson
Sent: Saturday, December 14, 2019 4:05 PM
To: Open PHD Guiding <open-phd...@googlegroups.com>
Subject: [open-phd-guiding] Re: Help with interpreting log from CGX-L mount

 

Hi again,

--

You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/14d71121-8efa-47a0-9298-b66bdb6d09fd%40googlegroups.com.

[Stephen Pattinson]

Thanks Brian,

I'll give that a go. I ran out of cloud-free sky last night, so I need to wait for next weekend now :-(

The stars still look round, but that's at 540mm. 

Thanks

Steve

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd...@googlegroups.com.

[Brian Valente]

Steve if you are satisfied with your results, that's really what matters.

My thought was only if you had problems with round stars, or maybe as you move to the non hyperstar longer focal length

Brian

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/df358696-8331-4a4e-89f9-2f37aa3aa47f%40googlegroups.com.

--

Brian 

Brian Valente

portfolio brianvalentephotography.com 

[Stephen Pattinson]

Hi Brian,

Yes, certainly I want to use the longer focal lengths as well. I have a communication from Celestron suggesting it can be nulled out with PEC, but unless I can get PHD2 to do that first, it won't create the appropriate PEC correction. A bit of a chicken and egg problem.  I will however try using PHD to correct the 21 sec wobble with the PPEC guiding as you suggest. If it can do a half decent job, I can record the PEC while it's running - or just run with that?

Thanks

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/df358696-8331-4a4e-89f9-2f37aa3aa47f%40googlegroups.com.

[Brian Valente]

In my experience mount-based PEC won't do a good job of correcting a periodic error that short. 

I'd say start with running PPEC and see if that makes a difference in the guiding results- if it does you can always try both ways.

Brian

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/b401452f-e00f-43f2-9144-7f2eebf997d6%40googlegroups.com.

[peter wolsley]

Stephen,

Very good job...you have tackled a lot of work lately. Section 9 of your latest guide log shows a total rms error of 0.88" which is good and a significant improvement. I especially like the PEC_Training.PNG image.  I can tell that Celestron is still using an 88 element PEC table for their PEC correction.  This translates into a new PEC correction every 3 seconds.  This is better than for my old CGEM (5 seconds).  Just to clarify a point you had made...The averaging of multiple runs that PECtool performs is intended to cancel out random errors that are typically caused by seeing.  Unfortunately, your 21 second oscillation is always present so it will not be attenuated by this averaging.

I am a bit of a "Mad Scientist" when it comes to PEC.  I have studied the Celestron PEC logic extensively and it is specifically designed to correct slow moving phenomenon.  I believe it can be "tweeked" to cater for fast phenomenon if the user has some skills with Excel which you appear to have.  The "tweek" is to simply shift the PEC values in the Excel file so that the nth value becomes the (n-1)th value.  This means that the first value will now become the 88th value.  The 2nd value will become the 1st value...the 3rd value will become the 2nd value. All of the PEC values are shifted one row up.  I deliberately used the phrase "PEC values" because the first and last values in the csv files that PECtool creates  in my files have the values 88 and 7200.  These two values need to stay put otherwise PECtool will not understand what to do.  When you shift these PEC values by one row upwards you will have created some "anticipation" in the data.  When the mount uses this modified PEC table it will be better able to anticipate the fast changing 21s oscillation and should be more successful in correcting it.  Theoretically you could shift these values as much as 4 rows to provide the maximum possible "anticipation" for correcting this 21s oscillation. Be sure to click on the "Remove Drift" button before you upload a modified PEC table to the mount.  Just be careful to save your work with good filenames so you can go back and forth as you experiment.

The downside of this approach is that it does degrade the ability of the PEC logic to correct for the slower PEC issues.  In your case, the 21s oscillation is so dominant that this approach should significantly reduce your guide rms error. Just be sure to experiment with your "averaged" PEC table.  These averaged values have the best quality when experimenting with reducing the 21s oscillation.

Good Luck

Peter

[Stephen Pattinson]

Hi Peter,

I've been thinking of something similar to what you suggest. The trick (amongst others) would be to not wreck the corrections for the 299sec large scale error in the process. I think with a bit of work I could manipulate the figures to do the shifting you suggest, without changing the 299sec correction. Of course if I ever had occasion to remove the RA belt and put it back again with the teeth in a different position, I have to do it all over again.

One possible additional problem I think is that the PEC training has been done with less than perfect correction of the 21.4 sec wobble, so the PEC curve doesn't accurately represent the error in the mount. It's probably lagging as you say, but distorted as well. Actually, my PEC training was done the week before when I was still using the colour camera and 4s guiding, so I should probably repeat with the 1sec guiding to get a more accurate PEC result before manipulating the result.

I could also try what Brian has suggested - ie use the PPEC RA algorithm set to 21.4 sec which might give a better result and hence more accurate PEC training to feed into the above process.

Another more radical approach occurs to me. I could take my smoothed PEC curve which corrects the 299s variation pretty well, and combine it with a suitably scaled version of the unguided PHD2 result, after filtering out say components with period of more than 100sec and less than about 5 seconds - Ie 0.01Hz to 0.2 Hz. - A bit of a challenge !

Of course, it would just be nice to fix the mechanical root cause of the problem. Where I work, its a common joke that any any mechanical or electronic problem can be fixed by software - I guess it's true sometimes. I should also say that I've reported to the problem to Celestron support, and they have just asked to see the PHD logs, so I'll wait and see what they say too.

Cheers

Steve

[peter wolsley]

Stephen,

You sound like a fellow "Mad Scientist".  My perspective on tackling your 21 s oscillation is that it is very very fast compared to the 299s worm period.  Shifting the PEC table one to 4 elements is equivalent to a time advance of  3 to 12 seconds.  Because your 299s worm PE is very smooth, it would be my opinion that the shifting will have little or no effect.  Remember that PHD2 is more than capable of handling a smooth 299s PE all by itself...even without using the PPEC method.  PHD2 cannot handle the faster 21s oscillation without enlisting the PPEC algorithm but this will be pushing it's capabilities.

I agree that if you try shifting the PEC table that you should strive to start with the best data.  I don't think you will ever get to the point where the 21s oscillation will appear as a nice sinewave no matter how many runs you end up averaging.  I think the belt/gear oscillation is most likely a spikey noisy sinewave that may exhibit differences from tooth to tooth as the belt/gear rotates.  There will most likely be a strong fundamental frequency but this may represent only a fraction of the total problem.  The other effect that is occurring here is that as PHD2, or your PEC logic, is making corrections they are actually increasing or decreasing the rotational speed of your RA axis.  This means that the 21s oscillation is always speeding up or slowing down slightly.  Because the mount's PEC table it synched to the rotation of the wormgear, the 21s oscillation contained in the PEC table is always phase locked to the belt/gear phenomenon.

The interesting aspect of all this is that there are tasks that you can experiment with that only represent your commitment of time.  Always refer back to your captured images to ultimately decide if you have done enough.

My CGEM has a 15s oscillation with a 480s worm period.  In my case I wrote a program that talks, via ASCOM, to my mount every second and has the ability to change the tracking rate of the mount in real-time.  My program also samples the motor encoder on the RA axis so that it maintains synchronization with the wormgear.  My program contains a discrete Fourier transform that is tuned to the 15s oscillation.  This logic is listening to the RA guidestar deviations being provided via the PHD2 server.  The logic continuously maintains a representation of this 15s oscillation which is then sent back, in real-time, to the mount as a correction to the RA tracking rate.  The end result is that a frequency analysis of my guiding shows zero periodic error at 15 seconds.

My program also provides full PEC for the mount.  The logic in the mount is not used.  The CGEM has none-integer gears which means it takes three full revolutions of the wormgear for the periodic error waveform to repeat.  This means it takes 1440 seconds for my mount to complete one full repeat of it's PE.  Both your CGX and my CGEM have an 88 element PEC table available in the mount for PEC.  My program maintains a 1440 element PEC table in software which updates the mount every second by adjusting the tracking rate.  The PEC waveform for my CGEM is very agressive with many fast transitions (see attached jpg).  I have also built a custom version of the PECtool algorithm into my program so that it can learn/refine the 1440 element PEC table while I am imaging.  The end result is that I can routinely image with 500 second exposures and a total guiding rms of 0.5".

Mad Scientist?

Peter

[Stephen Pattinson]

Hi Peter,

Sorry it's taken so long to reply. I think you might still have the edge on me in the "Mad Scientist" stakes, but I'm trying to catch up.

Not great viewing conditions here in southern Australia as you might have gathered from the news, so I've been mainly fiddling with various guide parameters, with some success. (I'll post results separately). 

In respect of PEC, I've been having quite a discussion with Celestron about this. To quote them "First, PEC is preemptive. It does not apply a large correction at the end of the bin, as a guider would. Instead it adjusts the tracking rate by just enough, so that the mount ends up where it should have been at the end of PEC bin period. There is no way to achieve that with a guider because you can’t send guide correction 300 times a second. PEC is taking advantage of the fact that it KNOWS the mount is drifting and prevents it from doing so."

So, Celestron believes that PEC can take care of the 21.4 sec RA gear wobble to a useful extent, but they they have uncovered a possible problem with the current PECTool and the CGX/-L mounts which they are investigating. A new PECTool may be coming soon. I guess this won't affect you with your CGEM. Your method seems more sophisticated anyway.

Rgds

Steve

[peter wolsley]

Steve,

Glad to hear from you. In Canada, where I live, we have seen all kinds of news coverage of the forest fires in Australia.  I'm glad you haven't had to pack-up and leave. I agree with Celestron's interpretation of how PEC works.  The PEC table in the mount is actually a list of speed adjustments that have been derived from the positioning movement observed while PECtool was performing a training run.  These speed adjustments are applied all the time that PEC is enabled.  The end result is that the RA position is always slowly ramping forwards or backwards. It "knows" when to ramp forward to anticipate an upcoming change in PE.  If, for some reason, it's prediction is out slightly, this is where PHD2 will "see" the error in positioning and trim the RA position to keep everything locked on to the guide star.  PEC and autoguiding are designed to work together.  I have heard of some mounts that don't play nice with autoguiding but I believe Celestron mounts work well with PEC and autoguiding.

I'm glad that Celestron is investigating PECtool.  It's very old and needs work...it doesn't understand ASCOM and insists that it exclusively talk to the mount which really makes it a pain to work with.

The PEC logic could help a bit with the 21.4s oscillation but it will be a challenge. 

Peter

[William Hansen]

I have followed this thread with much interest, as I too have the CGX-L mount. I have used PHD with so-so success. I get decent stars, but not perfect. I’ve enabled ppec on phd. However, I have not used the cpwi tool. Do I need to first use the mount pec tool and then go to phd ppec?

I am still trying to get my arm around the entire process. Are there well detailed instructions as the the proper sequence of events that should be followed in getting the mount calibrated through setting up pec?

Any assistance is much appreciated. It’s hard to get this set up when in December I only had 1 good night and so far this year only 2 nights , with no good nights expected in the next 2 weeks.

Bill Hansen

On Jan 9, 2020, at 12:55 PM, peter wolsley <wols...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/18cc200c-88aa-4742-b904-8bdf95601ffb%40googlegroups.com.

[Stephen Pattinson]

Hi Peter,

I'm actually a few hundred km from the worst of the fires, but most of southern Australia is affected by smoke and bad air quality. 

I'll let you know how it goes with Celestron.

Rgds

Steve

[Stephen Pattinson]

Hi,

Thought I should report back after some more experimentation and discussion with Celestron. At the Celestron's suggestion, I've done some more experiments with the camera at the focal plane rather than using Hyperstar configuration (540mm) which I started with. So the attached log file is captured at a a focal length of 1235mm, and guiding via an OAG using a ASI120MM-S mono camera.

The most relevant sections of the log are 12-guide assistant, 16-calibration and 21-guided. As you can see from the latter, the RA RMS error is 0.66a-s. Maybe not astounding, but better than before. This was done without using PEC in the mount, but using the PHD2 PPEC as Brian suggested with the period set to 21.4seconds. This suppresses the 21.4 sec gear tooth induced wobble, but as can be seen from the analysis, induces many other frequency components. The long term 299 sec periodic error is perhaps not quite as well suppressed as it is with the default RA algorithm, but it's small anyway.

Celestron are looking at the issue, and may be able to offer some more advice soon, although they point out with average seeing in the 2-3"a-s range, maybe the 21.4 sec wobble is swamped by seeing, and not the issue I thought it might be. Their current advice is that both PEC in the mount and Guiding will produce a better result than either one alone. They suggest using CPWI to capture the PEC curve, but there is a hint that maybe an update to PECTool will also happen. 

The good news is that with the PHD2 PPEC set to 21.4 as was the case with section 21 in the attached log, the 21.4sec wobble is not apparent in my images. While this guiding was running, I took a series of exposures from 4 seconds to 900 second. I can not see a difference in the star shape between the 4 and 900 sec images, so I was pretty pleased with that.

I do have another small issue however whilst using the OAG, (apart from finding a decent star with 1 sec guiding) in that due to probable collimation issues, the star shape seen by the guide camera hanging of the OAG is far from ideal (see attached image) , and the HFD is in the 5-6 range. The pixel scale is 0.63 a-s/pixel however which may help. I'm assuming that if PHD2 tracks the COG of the guide start ok, it's shape may not be critical, but some advice on that would be welcome. I'll try and improve the collimation of course, but it's not great way off to the side of the image where the OAG prism is.

Thanks

Steve

PS I would have uploaded the log file using PHD2, but with the way PHD2 displays the log files, I just couldn't be sure I was going to upload the correct file with I had looked at with the log file viewer. Perhaps if the file name were displayed it would help? 

[peter wolsley]

Steve,
For the guiding assistant run on Dec 9th I can tell that the 21.4s oscillation is 2.4" P-P and that the very fast 5.5s oscillation is 0.5" P-P. It's important to note that the PEC logic in the mount was enabled during the guiding assistant.  The guiding run that follows did not use the PPEC logic but the PEC logic in the mount was still enabled.  PHD2 (and PEC) managed to reduce the 21.4s oscillation to 1.3" P-P.  To accomplish this PHD2 was issuing guide pulses that represented a RA axis movement of 2.7" P-P.  This situation is not uncommon in real-time control systems.  The control system (PHD2) is trying to correct a fast moving disturbance and it lags behind because it always needs to react to what has happen and has no knowledge of what is about to happen.  The end result is that the control system is very active but doesn't seem to achieve all of the desired benefit. Dec was -12.5 degrees for this session.

For the guiding assistant run during your latest run (Jan 8th, 2020) the 21.4s oscillation has grown to 3.1" P-P and the very fast 5.5s oscillation is still 0.5" P-P.  The PEC logic was not enabled for this session so the larger 21.4s oscillation may be due to PEC not being enabled.  The guiding run that follows used the PPEC logic but the PEC logic in the mount was OFF.  The PPEC algorithm, without the PEC logic in the mount, was able to reduce the 21.4s oscillation to 0.6" P-P which is an impressive result.  To accomplish this, the PPEC logic had to issue guide pulses that represented a RA axis movement of 1.8" P-P which also demonstrates the advantage of a control algorithm that has knowledge of what is about to happen. Dec was -20.8 degrees

This is a very good result and your images demonstrate that you are getting nice round stars.  It would be justified for you to say your system is now capable and your guiding issue is resolved.

My gut feeling is that the PEC logic in your mount can still be of benefit.  I can tell that the PPEC logic is also catering for the slower periodic error in your mount.  When you had PEC enabled in your mount I could tell that PHD2 was not trying to cater for these slow periodic errors.  I believe that PEC and PPEC are compatible with each other.  The philosophy is that PEC does the lion's share of addressing periodic errors with the PPEC algorithm playing "clean-up".  I still believe that shifting the PEC table, as I mentioned in a previous post, can also play a role in improving your mount's performance.  If you understand these concepts then they could be something to persue on moon lit nights when taking photos is not on the books.  I like to think that I tinker with the mount on moon lit nights and implement my "best practise" during imaging sessions.

Congratulations on accomplishing your improvements.  The concepts are intricate but...that's what keeps all of us astrophotographers up at night.

Peter

[peter wolsley]

William,
You don't need to have PEC enabled in the mount to use the PPEC algorithm.  You could try to follow what Steve did during his last post and see how that goes for you.  I can't use CPWI with my mount so I can't help with that.  The PECtool software is very old but Steve has been able to use it with some success.

You might want to post a guiding log from a night where you calibrate, perform a guiding run and then guide for 1/2 hour or so.  There's always lots of good info in those logs.  I would suggest that you also start a new topic with a good description. Most visitors to this site will scan the various topics but they may not drill down thru all of the posts within a topic.

Good Luck

Peter

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd...@googlegroups.com.

[bw_msgboard]

Hi Steve.  You’re not likely to get a better analysis than this one from Peter, certainly not from me. J  So I’ll just respond to your question about the guide star image in the OAG. This looks typical for these Schmidt-Cassegrain systems, where the star shape suffers from a combination of coma and field curvature.  You might be able to get some benefit from re-collimation but I think the comatic star-shape will probably still be present this far off-axis.  It shouldn’t be a problem for guiding because the centroid algorithm doesn’t make any assumptions about star shape.  The only downsides are similar to those of having a soft focus – the SNR for the star is lower than it could be and you may not be able to take advantage of fainter stars in the field of view.  But people have been guiding with stars like these for a very long time.

 

Hope this helps,

Bruce

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of peter wolsley
Sent: Saturday, January 11, 2020 1:06 PM
To: Open PHD Guiding
Subject: [open-phd-guiding] Re: Help with interpreting log from CGX-L mount

 

Steve,

--

You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/d4d7539f-2be0-43f9-b778-d3fc35ea83fa%40googlegroups.com.

[Stephen Pattinson]

Hi Peter,

Thank you for the detailed analysis of my results. Yes, the PPEC algorithm in PHD2 seems to do a good job. I should also be using PEC in the mount, but I just wanted to do one thing at a time. I think as I mentioned Celestron are promising some more information or a new PECTool soon, so when that happens, I'll try that soon. Anyway, I think I've made considerable progress with help from yourself and others in this forum, so thanks for that.

Cheers

Steve

[Stephen Pattinson]

Hi Bruce,

Thanks for your help in this matter. Certainly I need to improve my collimation (just ordered some Bob's knobs!), but as you say, PHD2 seemed to cope with the wonky star shape. The SNR was pretty low also, but this may have been due to conditions being very var from optimal. 

Many thanks

Rgds

Steve

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd...@googlegroups.com.

[Brian Valente]

Hi Steve

 

Just to clarify, you should collimate your scope for your imaging, don’t sacrifice that for a ‘good’ star shape in PHD. The OAG is on the periphery and with a Schmidt-Cassegrain it will likely never be as round and good as the imaging portion of your telescope. In other words, expect it will be a little wonky. If you are happy with your images, don’t collimate it for PHD’s sake

 

 

Brian

To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/b51f2dff-449e-4d44-bd97-2517071262e3%40googlegroups.com.

[Stephen Pattinson]

Hi Brian,

I appreciate that. My images do show the effect of less than satisfactory collimation however. It's good that PHD2 is tolerant of that. My latest guiding effort (PHD2 PPEC @ 21.4s) yielded 0.74"RMS @ 1225mm despite a wonky looking guide star with a HFD of 6ish, so I'm fairly happy with that. No obvious star elongation in a 300sec exposure, or at least nothing obviously showing that's not hidden by other defects.

Cheers

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/b51f2dff-449e-4d44-bd97-2517071262e3%40googlegroups.com.