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.
PHD2 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.
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.
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?
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.
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:
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.
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
criteria.
More data collection tonight.
Thanks.
Moussa
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 2.4.1.3 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.
I connected my equipment by using the new Tools/Connect all, about 10:00pm ish.
I slewed near the meridian, calibrated PHD2 with the new settings and let it guide for a while.
After this short experiment with algorithms, I then stopped guiding, reverted to my usual hysterisis and slewed/centre now to my target.
I started the sequence and re-calibrated PHD2.
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.
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.
I experienced a further RA lurch on the next sub and then the guiding settled without a further incidence of the RA lurch.
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.
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.
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?
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.
Barry
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!
