I know. My statement was mostly tongue-in-cheek after I was accused of “attacking” SGP.
Take a closer look at the log posted above. Following a non-dithered image, SGP tells PHD2 to resume guiding (settling):
“[08/30/17 21:48:37.759][DEBUG] [Sequence Thread] Resuming auto guiding (settling)…”
That was at 21:48:37.759. Then PHD2 goes into the settling routine:
“[08/30/17 21:48:37.964][DEBUG] [Sequence Thread] Waiting for Auto Guider distance to fall below 2”
4 seconds later, PHD2 reports that it is done settling:
“[08/30/17 21:48:42.042][DEBUG] [Sequence Thread] Distance stayed below 2 for 4 seconds, done settling…”
Then SGP has to wait for PHD2 to say that it is ready to resume:
“[08/30/17 21:48:42.042][DEBUG] [Sequence Thread] SGPro settle criteria have been met, but the guider reports it is not ready to resume, waiting…”
Finally, 7 seconds later, PHD2 reports that it is ready to resume:
“[08/30/17 21:48:49.076][DEBUG] [PHD2 Listener Thread] PHD2: Settle done received: GOOD”
Now the next image can begin capture. As you can see, a lot more than 4 seconds elapsed. The whole process took a total of 11 seconds. This is 11 seconds of lost time that is completely unnecessary. PHD2 could just as happily be guiding uninterrupted through the whole process.
I disagree. The settle requirements are part of starting guiding. In fact, they are parameters sent to PHD2 with the “guide” method. PHD2 is already guiding during undithered images and there is no reason to tell it to start guiding again when never telling it to stop guiding is a better option.
If there is no dithering at all, settling can be turned off completely, though I am unsure whether SGP still settles guiding between frames. Still, as you can see in the log posted, the big time hit isn’t the settling time, it is the time that PHD2 takes to be ready to resume after settling - 4 seconds versus 7 seconds respectively. If settling parameters are passed to PHD2, settling will never be instant. It will always take several seconds.
But the case I am discussing is one where we are dithering every “x” frames. This option is intended for the case where large numbers of short exposures are taken. The option is supposed to eliminate the time penalty for dithering for the majority of frames while still having enough dithering to be useful for sigma rejection. So the settling parameters need to be specified so that when the dithering does occur, it settles properly. However, there is absolutely no need to send a settle command to PHD2 between the non-dithered frames, which SGP does. As you can see in the log, that is an unnecessary 11-second penalty for every non-dithered frame. If you are taking a lot of 10-second exposures, you are spending more time settling unnecessarily than you are collecting photons.
Andy responded to my questions about PHD, which have already been subsequently partially answered by Chris.
“PHD2 has two methods – a method that reports the current error (a smoothed average over the last few guide frames), and the method “guide” to ensure that settling is complete to the specified tolerance (error under X pixels for Y seconds). If SGP uses “guide” but the settle time is zero, then phd2 would only requires the guide distance to fall below X pixels for a single guide frame.
To your point about whether SGP should call “guide” at the start of each frame when there was no dither… in most cases I don’t think there is value to that. SGP will be checking the distance continually for the “restart exposure if guider distance exceeds X pixels” option, and as far as guiding is concerned there’s nothing significant about the start of the exposure.
The case where it would benefit to settle at the start for each exposure is for setups that need to pause guiding for image download. In that case there could be a significant delay while guiding is paused, so it would make sense to settle after un-pausing guiding.”
With that in mind, if dither and pausing is disabled, maybe SGP could just use the current error to decide whether to immediately proceed to the next exposure? It would not require a further user option but just make use of available data to avoid unnecessary delays?
After all this, that’s all I have been trying to say…
yes, but Andy goes on to propose that SGP could use the current guide error to determine if it is OK to immediately proceed to the next exposure - which supports my earlier point that rather than to proceed at risk to the next exposure without knowing the tracking error status, the guide error could be used as an immediate substitute. That logically does not need any further options just some coding that uses either the guide or error status depending, on the other guiding options.
That already exists, as Andy pointed out. SGP has always had the option to “restart exposure if guider distance exceeds X pixels”.
We have had a spirited discussion on intra exposure delays which are especially noticeable when one is taking rapid short exposures. The initial suggestion was to not make SGP settle PHD2 between undithered frames. Working through the problem, we can see the benefit of explicitly confirming the PHD2 status before starting the next frame but the issue is the increasing overhead with short exposures. It seems there is a viable alternative when continuous guiding is in play, which would allow an immediate confirmation. This uses the guider error value which SGP already uses for frame restart. SGP would use the settle status when it tells PHD to Pause/Resume and the guider error when PHD2 was continously running. Is that something you could look at?
BTW, I believe that applies to exposures that are in progress, not between exposures.
I have yet to look through this entire thread. But it seems reasonable that the guider should really only settle when a dither is requested and just assume that things are good if one is not. I’ll go through and see if that’s actually what is being requested here but I believe that’s at least how it started
Thanks Jared - the other potential idea is to continually monitor the tracking error in this case (the one you use for frame restart) and use that, rather than just assume that nothing has caused the guider to go off target between exposures.
mostly, I use long exposure time, but as an experiment i used 10sec and notice the same issue with guider settling.
Exposure is 10 sec, ~1sec download, ~1-2sec image analysis and ~7 sec guider settle.
Dither is set after 10 frames. Guider is settling after each frame.
I was looking at guiding graph and nothing changed after download - guider was working within normal parameters but there was guider settle message.
Is there any working solution for this? Or will be?