Question Large declination backlash reported by PHD2 guiding assistant

Hi Ken,
Thanks for taking a look at this!

As I wrote above the forum settings are very restrictive. You are not allowed to upload files bigger than 100kb. A zipped guidelog is bigger than this... Also the images may only have a very small size.

I really hope Avalon relaxes those forum settings to more useful values.

Anyway, I uploaded the guide logs, the initial screenshot of the guiding assistant with the extreme backlash and the two screenshots of the log viewer from above to this folder:
drive.google.com/drive/folders/1-k7GQ0Op...EHhPqDmX?usp=sharing

The screenshots show, that typically more pulses are required in DEC to get back on track - most likely related to the backlash.

Regards,
Stephan

Hi Stephan
Some observations from your log file - in no particular order:

Overall the guiding looks fine. There is no sign of any backlash during normal guiding so it seems that only the settling after a large dither is an issue. Even that is not so bad.

The calibration results versus the guide rate settings suggest that the focal length of your guide scope is actually a bit longer than specified (188mm) so the Normalized guide rates are both higher than expected. This does not affect guiding but couldmake guiding results look worse than they really are.

There is a significant delay in your guide image capture. The guide images average about 2.5 seconds apart. The time between images consists of: the exposure time (1000ms), some overhead in the driver (typically 500ms or so), download time and time spent guiding on each axis. The guide time averages only 0.075 seconds so is negligible. That would suggest that the download time from the guide camera is quite large - as much as 1 second on average. This would delay the settling after a dither.

It looks like the "Fast Recenter" option is selected. Fast Recenter causes PHD2 to automatically issue a correction to a dither without waiting for a guide image and IIRC bypasses the guide algorithm. This could help to speed up settling after dither. So lets say you dithered in dec by 4.0 pixels (e.g. at 22:49 on 5-May). This is 12.7" which at the guide rate should be corrected with a pulse of 790ms. The fast recenter pulse is shown in the guide log and subsequent corrections are issued via the LowPass2 algorithm.

Your MinMove setting with the LowPass2 algorithm is 0.02. What this means is that whenever there is a deviation of 0.08 pixels or more then the LowPass2 algorithm resets. After a reset the next 4 corrections are then just the deviation x aggressiveness. You have aggressiveness of 100 so after a reset your corrections are the same as the deviations. The chances of a deviation of 0.08px every 4 samples is very high so you are effectively guiding unfiltered. This is part of the issue with your dithering.

If we analyse the calibration there is a backlash removal stage (which is standard). Each step is 500ms and in Dec the guide rate is 14.3"/s so in 500ms you expect a movement of around 7.2" and at a pixel scale of 3.18" that makes 2.2 pixels. The actual movements during the backlash steps are (in pixels): 1.6, 1.7, 2.3, 3.2. So the initial movements are a bit smaller than expected but then overshoot. During the rest of the dec calibration there is similar variablility in the step sizes as measured in pixels. The biggest variation is a bit more than 1 pixel beyond expected or 3.2" so it could be down to poor seeing.

This variability also seems to be present in the screen shot of the GA backlash module. However, the actual data is not in the guide log so it might just be an artefact of the graphic. The backlash data should be in the debug log so if you could upload that (the one with the GA Backlash session) I could have a look at it.

This variability could be down to belt stretch as Stefano mentioned. As I understand it, if you make a large guiding movement and the mount is not well balanced in Dec the resulting torque causes the belt to stretch momentarily as the mount moves so it does not immediately move by the full amount. It then takes a small time to recover so the guiding result is delayed while this happens.

I compared your dither results using the LowPass2 algorithm against a similar dither on my M-Uno using the Z-filter. What it shows in both cases is that in response to the Fast Recenter pulse the mount does not move fully to its target position. It looks like it takes another second or so to complete the mvoement. After the first recenter pulse the guide algiorithm takes over. In my case the Z-filter picks up where it left off and issues very small corrections so the mount quickly settles to the new position. In your case the LowPass2 issues a large correction for (what looks like) the belt stretch and subsequently overshoots.

Hi Ken,

Thanks a lot for this deep dive into PHD2 analysis! Let me comment your findings below:

The focal length of my guide scope is specified as 180mm, but I checked with platesolving through ASTAP which reported 188mm, so I'm using this value now. But you think it is even more?

May be the download time for the image from the guiding cam might be affected by the enabled Noise Reduction (2x2 mean)? No idea what else might slow it down. The cam is connected through the native ZWO driver, not ASCOM. I'm using an i5-5300U CPU at 2.3GHz

Yes, Fast Recenter is enabled.

I started with a MinMove of 0 as suggested by Avalon but slightly increased it. So you suggest either increasing it or/and decreasing aggressiveness?

I uploaded a DebugLog and a corresponding GA screenshot within a single ZIP file to the same folder. It has slightly different values than the first screenshot, but still close to 4000ms of reported backlash. May be you can find even more details:
drive.google.com/file/d/1-ICM1IcNVWFbWAO...Cka/view?usp=sharing

So may be I should try your Z-filter algorithm again? I used it but couldn't see a big difference to LowPass2 - now with your explanation I know what to look for!

Thanks again for your time!
Stephan

Hi Stephan,
With the LowPass2 algorithm I'd suggest leaving the minmove at 0.2 and aggression at 80%. These are the defaults and GA also recommends a minmove of 0.2
Its hard to tell what is causing the delays. it could be the download time due to the sensor size on the 290 or it could be the processing time to locate the guide star position (for the same reason). You could try using the Use Subframes option in PHD2 Camera settings and see if it helps. This downloads and processes only the search region around the guide star.
You could also try binning but your guide pxel scale is already more than 3 arcsec/pixel and doubling it to 6 makes a coarse scale.
With the delay the choice of algorithm is a bit moot so it would be worth addressing that.
As for the backlash I graphed the backlash test raw movements against time.
Moving north the mount initially responds with smaller movements than commanded but after about 20 seconds the movements are as commanded.
Moving south is much the same but even after 20 seconds the mvoements are smaller than commanded. The large spike to the south is where GA is trying to move the guide star back to its starting position.
The smaller movements could be caused by belt stretch but it shouldn't take 20 seconds for it to recover.
It looks a bit like stiction somewhere in the drive train.
And the south moving issue suggests some sort of imbalance on the dec axis.