SGP 2.4 Dither Not behaving as expected - PHD2 2.5 Pre

I just started using 2.4 tonight along with PHD2 2.5 pre. I never had any issues with dithering in the previous version of SGP. Dither would happen right on cue and integration would continue as expected.

Tonight however, I see that SGP is requesting PHD2 to dither but it does not actually dither in PHD2. SGP then checks for the guider settling limit which it gets quickly since no dither took place then it starts integrating again.

I observed one instance where eventually the dither command was acted upon by PHD2 but seconds later (after SGP started integrating again…).

You can find the SGP log here.


Update, I enabled manual guiding in PHD2 to see how dithering behaves there, what I observe is that when I hit “dither”, the PHD2 graph freezes and takes 10 seconds to come back. when I returns I see the dither. So it seems like the issue is with PHD2 not responding to dithering or being very slow to respond.


The PHD2 logs shows that dither is actually happening. What was it that made you think the dither was not happening?

One example from the log (and there are several more):

23:49:28.389 00.100 4104 evsrv: cli 00BA08F8 request: {"method":"dither","params":[5,false,{"pixels":0.3,"time":4,"timeout":300}],"id":1002} 23:49:28.389 00.000 4104 PhdController::Dither begins 23:49:28.389 00.000 4104 dither: size=5.00, dRA=-1.50 dDec=3.96 23:49:28.389 00.000 4104 MountToCamera -- mountTheta (1.93) + m_xAngle (1.45) = xAngle (3.38 = -2.90) 23:49:28.390 00.001 4104 MountToCamera -- mountX=-1.50 mountY=3.96 hyp=4.23 mountTheta=1.93 cameraX=-4.11, cameraY=-1.02 cameraTheta=-2.90 23:49:28.390 00.000 4104 setting lock position to (642.52, 189.18) 23:49:28.390 00.000 4104 dither: clearing mount guide algorithm history 23:49:28.390 00.000 4104 Status Line 0: Dither by -1.50,3.96


Did you check the images to see if they were or were not actually dithered? PixInsight “Blink” is a super easy way to check that.

I do indeed see that Andy. I went back and looked at the pictures. Some were indeed dithered. A couple however showed that the dithering occurred later after integration had already restarted.

Question is does SGP wait for confirmation that the dither was completed or does it immediately look at guider settling?

I am attaching one of those images where you can see a trail on every start consistent with mount movement during integration.

Thanks. I checked them, some did indeed get dithered, but not all. Blink is definitely awesome…



Could you post your PHD2 Guide log? That will help us quickly see if the problem was right after the dither or later in the guiding. Also, could you please indicate the time of that bad sub so we know where to look in the log?


Here are the dithers that are present in the log:

23:32:23.869 00.000 4104 Status Line 0: Dither by -4.99,0.64 23:38:24.153 00.000 4104 Status Line 0: Dither by -3.07,3.09 23:43:53.199 00.000 4104 Status Line 0: Dither by 0.85,-0.20 23:49:28.390 00.000 4104 Status Line 0: Dither by -1.50,3.96

As you can see the third one is less than a single pixel. This is normal and expected. Your dither setting corresponds to a dither of up to +/-5 pixels on each axis. PHD2 picks a random value from -5 to +5 for each axis as the dither. Sometimes by chance that can turn out to be be nearly zero. In practice this scheme works out very well for removing hot pixels when stacking images.


The one that failed occurred at 23:43 which I see above to be a very small dither…

The guide log is at:

I will collect more data an actually check the images to verify if they were actually dithered.


For the image that started around 23:43 I do not see any evidence that SGP started the exposure before the dither settled. PHD2 reports settling done here:

23:44:10.743 00.000 4104 evsrv: {"Event":"SettleDone","Timestamp":1427611450.743,"Host":"ASTRO-PC","Inst":1,"Status":0}

And SGP starts the exposure right around that time:

[3/28/2015 11:44:08 PM] [DEBUG] [Sequence Thread] Distance stayed below 0.3 for 4 seconds, done settiling... [3/28/2015 11:44:08 PM] [DEBUG] [Sequence Thread] Auto guider has settled... [3/28/2015 11:44:08 PM] [DEBUG] [Sequence Thread] Finished sending frame capture. Entering wait mode... [3/28/2015 11:44:08 PM] [DEBUG] [Camera Thread] SGM_CAMERA_CAPTURE message received... [3/28/2015 11:44:08 PM] [DEBUG] [Camera Thread] Canon: Setting ISO to: 800 [3/28/2015 11:44:08 PM] [DEBUG] [Camera Thread] Canon: ISO look val: 96 [3/28/2015 11:44:08 PM] [DEBUG] [Camera Thread] Canon: Exposing for 300 seconds...

Your SG log file seems to be truncated after 11:44:10 PM, right after the exposure started. Do you happen to have the full log?

Here is your guiding graph during that exposure:

And the statistics for that time period:

The statistics and graph look ok and do not seem to show any kind of tracking error that would cause the star trails.

Since we cannot blame SGP, and your guiding was ok, that leaves us with some kind of flex or shift in the imaging train as the most likely explanation for the star trails.


There was a recent change to SGP that introduced settling at the start of every sub-exposure. We also know that PHD damps its settling distance value to SGP. We always think of low pass filters acting on the guiding recovery but it can also occur before the too. Putting the two together, could it be that the PHD settling distance filter has not yet reacted to the dither and then SGP thinks it has settled, causing SGP to kick off the next exposure prematurely?

That would be bad if that were the case, but PHD2 resets the distance filter at the time of the dither, so I don’t think that is it.

Besides, the logs have already shown us that SGP did not kick off the next exposure prematurely despite the assertion in the OP. This has been verified by looking at the PHD2 and SGP logs for the exposure that started around 23:44, the bad sub screenshot that was posted above.


Fair enough - the weather has been awful recently and I have not had a chance to check the latest version out for myself.


Thank you for looking into this. PHD2 says settling was reached at 23:44:10
when SGP has it being done at 23:44:08 and taking into account the 4
seconds settling time by SGP that implies that it settled back at 23:44:06
at least. The only explanation would be that PHD uses a different settling

More data collection tonight.



P.S.: what is the response time of manual dithering? When I try that it
takes at least 10 seconds for dithering to show on screen. I will do a
video capture and share.

I am currently imaging with PHD2 2.5.0pre1 after rolling back earlier this evening from 2.5.0. I am using the new SGP beta. I have been experiencing a sharp movement in RA sometime after the dither command. I am experiencing this with both PHD2 versions. My total RMS error is typically 0.7 or 0.8"/px once settled. The RA ‘jump’ has about a 3" or 4" magnitude and is causing a minor distortion on the subs. The ‘jump’ in RA does not appear to have the same time-lag after the dither command in each of my 10 number 300s subs taken so far. I have dither set to small in SGP. The Avalon Linear FR mount normally has such a predictable guide trace.

My previous experience (with other SGP and PHD2 versions) was that the RA nudge would occur at the same time as the dither, as you would expect.

I have checked cabling as best I can whilst imaging but will have a thorough check tomorrow in daylight.

I will post logs of SGP and PHD2 tomorrow when I have finished imaging.


I started the evening by updating PHD2 to 2.5.0 (having watched a great tutorial on the Astro Imaging Channel which I recently discovered). I planned to start the imaging session trying a new guiding algorithm, Low Pass as recommended for mounts with no backlash, rather than my usual hysterisis.

  1. I connected my equipment by using the new Tools/Connect all, about 10:00pm ish.
  2. I slewed near the meridian, calibrated PHD2 with the new settings and let it guide for a while.
  3. After this short experiment with algorithms, I then stopped guiding, reverted to my usual hysterisis and slewed/centre now to my target.
  4. I started the sequence and re-calibrated PHD2.
  5. For the first 4 subs I experienced this strange lurch in RA (as seen from my guide trace) part-way through a sub and not coincident with the dither command.
  6. About 11:02pm I paused the sequence, stopped guiding, disconected my guide cam/mount, rolled back PHD2, restarted PHD2, re-connected, re-calibrated and continued the sequence.
  7. I experienced a further RA lurch on the next sub and then the guiding settled without a further incidence of the RA lurch.
  8. In each of the excessive RA lurches (from a RMS of 0.7"/px up to 4"/px) the RA would be very quickly corrected, so was a momentary - but uncharacteristic - spike. I imaged a further 30+ RGB subs of 300s each without issue.

Having witnessed this phenomena at the beginning and then to see it disappear after 5 subs or so is puzzling and does point to something other than software, so I will have a thorough check today. Examining the subs, there are a couple of minor distortions from good circular star shapes (quite minor) on the subs affected. I’ll post some screen shots when I get a chance later today. I had experienced this strange RA lurch before when I used PHD2 2.5.0pre3 but reverted quickly and didn’t report it (not very helpful I know and apologise). I use Ascom pulse guiding through Eqmod with my Avalon Linear FR.

Thanks for taking a look.



sg_logfile_20150418214709.txt (900.2 KB)
PHD2_GuideLog_2015-04-18_230245.txt (311.7 KB) the PHD2 log from 11:02pm
PHD2_GuideLog_2015-04-18_215339.txt (93.6 KB) the PHD2 log from 10:00pm to 11:02pm

Oh, just recalled, my AVG anti-virus software updated sometime at the beginning of the sesssion (as the banner informing of this popped up). I postponed the PC restart for 8 hours and carried on.

Don’t know if this has a bearing at all.


Hi Barry,

I was able to get the first guide log (230245) but I’m getting an error when I try to access the second one (215339). Anyway, I do see the lurches you are talking about.

Your star mass and SNR were steady, so it was nothing atmospheric. It seems like it would have to be something mechanical, perhaps something shifting or a cable dragging somewhere? Or perhaps something to do with the mount RA drive somewhere?

I wonder if it is a clue that the lurches are all in the same direction?


Thanks Andy.

I didn’t get time yesterday to check for any cable snags (family etc) and will do so as soon as I can. I’ll update to the new SGP beta and also revert back to PHD2’s 2.5.0.

I had chance last night to image and study my cable movement. When imaging relatively low to the east (as I was when starting the Needle Galaxy NGC4565 the other night, Needle Galaxy NGC4565 LLRGB ( Barry Wilson ) - AstroBin), the cable from my motor focuser was just resting on top of one of my latitude knobs, enough to cause a small drag no doubt. This would also explain why the RA lurtch disappeared after a few subs. Hopefully issue cured!

Clear skies!


1 Like

That sounds like a promising theory, sure hope that was it.

Great image BTW :thumbsup: