PHD2 guiding algorithm sometimes oscillates?

[ch...@beyondmonochrome.co.uk]

I have been using Sequence Generator Pro and PHD2 for several months now and overall it is a fantastic combination. I'm using an OAG Lodestar via ST4 to a Paramount MX and guiding with the mount connection enabled too. Automated Meridian flips work fine. I'm using the low pass filter option for DEC at default settings and default for RA. I dither my exposures. During the calibration process the response to N-S reversals is immediate so I don't think I have appreciable DEC backlash.

Here is the problem. I have noticed a Jekyll and Hyde effect.  Over the course of every imaging session I can divide my subs into two categories; those with flatline tracking, 0.3" RMS or better and those that oscillate, maybe 1.5"-2" peak to peak.  Only one in a dozen is oscillating and  most of these frames are usable, there is room for some optimization.

I think it is PHD2 because:

• The oscillation continues for an entire subframe, until the next exposure / dither.
  
• It starts immediately after a dither, not during an exposure (however long)
  
• If I stop the guider and immediately restart it, it fixes the issue.
  

Things I have tried and appear to make no difference:

• Turn fast recenter on and off
  
• Changed DEC guiding parameters - slope in low pass mode and tried resist switch 
  
• Pulse guide / ST4
  

I have yet to try:

• Continue guiding through all SGP processes (focusing / download etc)
  
• Turn dither off
  
• Continually turn the guider on/off to see if I can trigger a bad 'start up'
  

It seems that the algorithm gets into a cycle that is just sends the mount into overcorrection a classic stability issue. Stop/starting the guiding off again seems to fix the immediate issue. That and the fact I have never seen it go unstable during an exposure - strongly suggests it is not a disturbance (wind)  or  mount issues.

This image below shows the guider trace - it had been oscillating since the dither, I started to change slope values, no difference and then you can see where I stopped and restarted the guider in PHD2.

Ideas:  something in the dither / restart routine has a random behavior - or a  corrupted start up value. Can we have a Maxim - like algorithm - not so intelligent - that simply issues a guiding command which is a proportion of the last tracking error value?  This would also be useful for diagnostics .

This screen capture occurred at 22:10 in the guide log (enclosed):

Any ideas?

regards

Chris

[Bret McKee]

Chris:

Thanks for the detailed email. I have created issue 354 to track this (https://code.google.com/p/open-phd-guiding/issues/detail?id=354)

You mention you are using low-pass for Dec.  While that algorithm is expected to work, I suspect that not very many people are using it, and it is possible it has a problem. Could you turn on debug logging and attach the log to the issue? To be helpful, the log should contain at least 1 "good" dither and 1 "bad". Please let us known the time of each dither -- maybe the log will have a clue about what is happening.

You request a Maxim like algorithm "that simply issues a guiding command which is a proportion of the last tracking error value". I've never guided with Maxim, but I think you can get the behavior you are asking for by selecting "None" as the guide algorithm, and setting Aggressiveness to the percentage of the error you would like to try to eliminate. With None and 100%, PHD2 would try to eliminate all the error every time (this will cause it to chase seeing, but hopefully you get the idea)

Bret

[bw_msgboard]

Getting the log data will be the important thing to do.  But another thing you could try to help isolate the problem is to do dithering only in RA – that might help to show whether this problem is triggered by the external dithering or by something else.  

 

Bruce W.

 

---

--
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.
For more options, visit https://groups.google.com/d/optout.

[ch...@beyondmonochrome.co.uk]

I have made some changes to my setup and it has changed the error behaviour - I feel that it is narrowing down. Bruce noticed in my logs that I pause my guiding for dither and autofocus. I stopped that and now guide throughout the sequence of subs in SGP.  I left dither on.

Friday night it went without a hitch for a 7 hour stint. Tonight it started off OK but the problem came back immediately after a dither from SGP but - and this is the crucial bit, the problem continued for the subsequent subs - that was until I stopped and restarted the guiding and it went back to less than half the RMS error.

I have recorded the logs and will post shortly - the trigger certainly appears to be the dither. The dither is changing the behaviour of the subsequent guide algorithm.  As I am writing this I'm looking at the DEC error and corrections before and after i stopped/restarted. I took a screen grab and will highlight several DEC errors where the correction value appears to be the same, but the actual response of the mount is much greater in its less stable mode.

I'm wondering if there is some legacy from the fast recenter command that is not clearing out after a dither command? I'm assuming there is an algorithm that decides when the fast recenter is disabled for normal guiding. Maybe there is a loop hole?

When this session is done, I'll get some sleep and highlight the log files at the right areas.

regards

Chris

[ch...@beyondmonochrome.co.uk]

Here are the two files - overall the difference between good/bad was not as striking as it has been on prior occasions but it serves to illustrate the point.

One thing I learned from the debug files is that I need to create dark libraries for each optical configuration - I'll know for next time.

Image exposures were 8 seconds. I was dithering between frames but autoguiding is not paused during download. Image exposures were at about 5:20 minute intervals.

A dither occurred at 20:49 and you can see the response became suddenly worse and continued -  through subsequent sub exposures / dither. This is new behavior and did not occur if I paused the guiding during image download. The issue in those cases was limited to a single sub.

I did a stop/start at 21.51 and the guider response went good again.

I noticed the RA was a bit reactive to seeing noise and I changed the settings to 60/40 at 21.55 and then to 40/20 which seemed to be ideal with a 0.15 min move.

Hope this helps:

https://www.dropbox.com/sh/teee18sxtzpbv1s/AADT1ekJRxM0iliA2mVH7LVia?dl=0

[Andy Galasso]

Hi Chris,

I just had a chance to look at your guide log. The symptom looks like something we see with mounts that have backlash compensation turned on. Is that something you have on your mount? If so, can you try turning it off?

Here's a graph of the dec offsets and corrections sent by phd2 at the start of one of the oscillations:

The vertical axis units are milliseconds (dec offsets in blue are [pixels / dec_calibration_rate], i.e., the dec pulse corresponding to the offset.) Corrections in red are the actual corrections sent.

It looks like the mount may be over-reacting to the dec pulses, which is a symptom of backlash compensation.

One other thing I noticed was your calibration completed in only 6 steps. You may want to try decreasing you calibration step size so that it completes in ~ 12-15 steps. That will ensure an accurate calibration; 6 steps may be a bit small.  You can recalibrate and look at your guide log and see if you get the same calibration rate. If not, we'll know that an inaccurate calibration was contributing to the problem.

Andy

[ch...@beyondmonochrome.co.uk]

Hi Andy -  the mount is a Paramount MX - there is no appreciable backlash and I have no software backlash being enabled.

A couple of points to keep in mind - 

• If it was a mount (or setting) issue, one would see the issue at other times, not just after a dither - I have no evidence of the issue occurring in the midst of a sub exposure, even though there are movements in both directions.
  
• The guiding issue is not restricted to DEC, it sometimes affects RA too.
  
• It occurs in hysteresis, resist switching and low pass modes

On account of the calibration - yes, I do need to shorten the time -  I was using a longer scope on this occasion but previously I had used shorter focal lengths, which took about 12 steps to complete. The issue occurs with all three of my refractors. I also calibrate at low DEC, for maximum accuracy.  ... But again, the calibration is a common mode effect - it does not really explain a special cause issue.

regards

Chris

[bw_msgboard]

Andy and I are collaborating on this one, looking hard at the guiding algorithm behaviors and how they’re affected by things like dither operations.  After Andy posted this question, we realized you were using a Paramount and likely had no backlash issues.  So stay tuned…

 

Bruce W.

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of ch...@beyondmonochrome.co.uk
Sent: Monday, November 03, 2014 4:29 AM
To: open-phd...@googlegroups.com
Subject: Re: PHD2 guiding algorithm sometimes oscillates?

 

Hi Andy -  the mount is a Paramount MX - there is no appreciable backlash and I have no software backlash being enabled.

--

[ch...@beyondmonochrome.co.uk]

Thanks Bruce - when the clouds part, I'll do my next exposure sequence without dither but with pause/resume during each image download.

regards

Chris

[bw_msgboard]

Ok, we may have something for you to try by then anyway.  One other thing to try would be to run for awhile dithering only in RA.  If that showed the Dec guiding performance to be normal, it would really be convincing. J

 

---

[bw_msgboard]

Hi Chris.  Andy and I have spent quite a bit of time on this, and we have some things for you to try.  One involves testing some code changes and the other involves some changes to guiding parameters.  The code changes made by Andy will clear the history in the guiding algorithms whenever there is a pause/resume or a dither operation.  Depending on the algorithm being used, we think this can reduce the cases where the guiding is too slow to react to a legitimate change in direction, especially with dithering.  Clearing of history in this way is already done when you stop/start guiding, so now it would be done for any of these operations.

 

The second thing involves the choice of guide algorithm for Dec.  Your mount apparently has near-zero backlash and you also seem to enjoy good seeing conditions.  We think that’s relatively unusual among the community of PHD users, so the “resist-switch” algorithm may not be your best option.  This algorithm applies damping only in the sense of trying to avoid changes in the direction of Dec guiding.  Once it decides to issue a guide command, though, it tries to correct for the full amount of the star deflection – there is nothing like an “aggressiveness” property here to attenuate the correction.  This seems to work pretty well for most users, perhaps because the full guide pulse helps to overcome backlash.  But after looking at your data, we think it contributes to instability in your case.  We suggest that you start using the “hysteresis” algorithm in Dec.  We know you tried this with mixed results, but it seems like you were running with the default parameters for that algorithm when it was applied to Dec.  Those parameters are probably reasonable for RA, but we think you would need more damping in Dec.  If you increase the hysteresis parameter, that should act to reduce the number of directional changes.  Changes in direction could still occur if there was a clear need but not with the regularity you’re accustomed to seeing in the RA guiding.  You could also reduce the aggressiveness parameter to further reduce the likelihood of over-shoot in Dec.  I see you already use a low aggressiveness factor with RA, and I would try an even lower value in Dec as a starting point.  Just to throw some numbers out there, I’d maybe start with a hysteresis up around 50 and an aggressiveness down around 30, something like that.  

 

As you well know, it’s difficult to evaluate performance in short time spans.  Seeing is never constant, and it may take awhile for a guide algorithm to stabilize.  To the extent you can afford the time, it would be good to let things run a bit unless it’s obvious that something is completely out-of-whack.  Everything we’ve said here is based on code inspection, “theory”, and lots of testing with the simulators.  But to paraphrase a military expression, a good guiding theory rarely survives its first contact with an actual mount. J   But hopefully we will learn something from these experiments and hopefully get you closer to your goal.  

 

We don’t want to do a full build yet with Andy’s code changes, so I’ll attach a new test executable in a subsequent private e-mail.

 

Thanks.

Bruce W.

 

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of ch...@beyondmonochrome.co.uk
Sent: Sunday, November 02, 2014 8:36 AM
To: open-phd...@googlegroups.com
Subject: Re: PHD2 guiding algorithm sometimes oscillates?

 

Here are the two files - overall the difference between good/bad was not as striking as it has been on prior occasions but it serves to illustrate the point.

--

[ch...@beyondmonochrome.co.uk]

Bruce -  thanks for the files. I think there is a clear sky tonight but a full moon, ideal for testing!  I will do these trials.

I will try:

1) My normal guiding setup (the one that has issues) but with your new code. (pause with download, dither)

2) My normal guiding setup with currently released PHD2 version and with dither disabled. (for RA and DEC)

Does that sound like a plan, or would you prefer me to try something different?

regards

Chris

On Thursday, October 30, 2014 10:44:16 AM UTC, ch...@beyondmonochrome.co.uk wrote:

[bw_msgboard]

Yes, those two test cases but also some experimentation with hysteresis on Dec using heavily damped settings.  I’d suggest doing that with the test executable, there’s really no reason to do that part twice.  In the end, we’re hoping to get good results in whatever situation you *want* to run in with regard to dithering, pausing, all that.  Obviously, it would be helpful to keep track of time ranges when you run the tests so we can more quickly find things in the log files (debug and guide)

 

Thanks.

Bruce

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of ch...@beyondmonochrome.co.uk
Sent: Wednesday, November 05, 2014 6:27 AM
To: open-phd...@googlegroups.com
Subject: Re: PHD2 guiding algorithm sometimes oscillates?

 

Bruce -  thanks for the files. I think there is a clear sky tonight but a full moon, ideal for testing!  I will do these trials.

--

[ch...@beyondmonochrome.co.uk]

Thanks for the quick responses. My first test only covered a few hours but I had no issues with the worse-case scenario - resist -switching DEC algorithm + dither + pause during download. Fireworks and fog stopped play.

Friday is looking good for a more extensive test. I probably need to acquire 50-100 subs to statistically verify the fix - but I have high hopes. If a stop/start fixes an oscillation and you have in effect put in the start-up reset code into the front end of the dither routine - it makes sense and just as importantly, I cannot obviously think of a down-side.

I'll keep everyone posted.   Has anyone else seen this issue?  If you have, verification is more robust with several systems.

regards

Chris

[T. Acker]

 Sorry to hijack this thread but I have had / still have similar problems posted in https://groups.google.com/forum/?fromgroups#!searchin/open-phd-guiding/oscillation/open-phd-guiding/8bEFHau_ZJ0/o4ZBVx6mYIkJ , maybe this could help.

I have tried everything out what was mentioned to me (but connecting the guiding camera Lodestar X2   directly to the mounts ST4 interface) but still got oscillation by random in DEC .  I  have a other mount and using a other ASCOM driver , but I stop guiding after every exposure and restart guiding after auto-refocusing (doing that with a self coded app -connecting PHD2 server interface- and scripting AquireStar-> Focusmax)  this may could cause similar effects with  the history data's ?

Best regards

Thomas

[ch...@beyondmonochrome.co.uk]

Another 30 subframes, with a mixture of different guiding parameters - with dither enabled and pause enabled during image download. Out of about 50 frames, one stood out but it was also accompanied by a lower SNR. I'm trying to keep my cool with the incessant fireworks and I reckon it may have just been smoke in the path. It does look promising - and if there is no downside to the modification, why not leave it in?

regards

Chris

[bw_msgboard]

Yes, the changes are already in the source base and will be included in the next release, which I believe Andy is about to push out.  Maybe you can give us additional feedback when things settle down for you.  I had no idea Guy Fawkes day was such an extended event… J

 

---

From: open-phd...@googlegroups.com [mailto:open-phd...@googlegroups.com] On Behalf Of ch...@beyondmonochrome.co.uk
Sent: Sunday, November 09, 2014 12:48 PM
To: open-phd...@googlegroups.com
Subject: Re: PHD2 guiding algorithm sometimes oscillates?

 

Another 30 subframes, with a mixture of different guiding parameters - with dither enabled and pause enabled during image download. Out of about 50 frames, one stood out but it was also accompanied by a lower SNR. I'm trying to keep my cool with the incessant fireworks and I reckon it may have just been smoke in the path. It does look promising - and if there is no downside to the modification, why not leave it in?

--