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”.
@Ken
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?
1 Like
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
2 Likes
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.
Hello,
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?
Thank you
Pawel
Hi all,
I started evaluating SGP a couple of days ago and I think I see the same behaviour but much worse. I have settle threshold of 0.8px for 10 seconds. What I see is that SGP wait 100 seconds after each exposure, which is extremely long. There is no dithering at the time.
But I see in the log that SGP sends the order to PHD to settle for 100 seconds with a timeout of 600s:
{“method”: “guide”, “params”: [{“pixels”: 0.8, “time”: 100, “timeout”: 600}, false ], “id”: 1003}
I certainly have nothing in the configuration that requests 100 seconds settling.
Here is an extract of my log:
sgp settle.txt (40.9 KB)
The problem is that your settle parameters are extremely tight. What you’re asking PHD/SGP to do is keep the guide star under 0.8px for a full 10s. So if the error goes above 0.8px at any point less than 10s the process starts over. I’m not surprised that it’s taking 100s for settling to complete.
Thanks for your answer Joel. But isn’t SGP asking 100s stable time in the json request? The PHD API documentation explains time as:
-
time- minimum time to be in-range before considering guiding to be stable
In these conditions, the wait time will always be 100s at least, won’t it? My settings were 10s settle time.
Also if you check the target settings, you’ll see that the guiding remains below the target the whole 100s.
I don’t know Cedric. The log clearly shows that you have set the settle parameter at 0.8px for 100s. Are you 100% sure you set it at 10s and not 100s?
Can you send a screenshot of the control panel/auto guide tab showing your settings?
Yes, I’m sure of it. I made a video to show what’s happening: sgp phd 100s - YouTube
Sorry, it’s a bit messy and the autofocus failed, but shows the options, the log, and the status bar.
Small point - but you made that change in the Equipment Profile settings, and those don;t affect the current Sequence - you would need to make sure it is set via the Control Panel or “apply” the updated Equipment profile to the current sequence.
Yeah, you need to check the Control Panel/Auto guide tab for your settings, not the equipment profile.
You might know this already, but just in case…the equipment profile acts as a template, but once you create a sequence from an equipment profile that sequence is completely independent from the profile. Changes you make to the profile do not affect existing sequences and vice versa.
Yep, you’re both right. I didn’t know the difference (as I said, a couple days testing under my belt). It also answers my next question. My problem wasn’t related to this thread after all. Thanks. Il go back to evaluating SGP.
PS: edited due to annyoing autocorrect.
Hello, last night i’ve done some testing.
From 19:08 to 00:32 i gather 823 frames, each 10sec.
Session time: 5h 14min ( 314 min )
Frames aquisition time: ~138min (2h 18min)
Looking at time in filename, average gap between frames is 21sec
Gap time summary: ~150min
Lets split it up:
Frames ~138min
Download time (av. 3sec) : ~41min
Dither - every 10th frame (av 3 sec): ~4-5min
Pause during session, autofocusing, meridian flip: ~20min tops
Average guider settling time: 8 sec - total: ~110min
Sum: 138+41+5+20+110 = 314min (session time).
It is not look good 
i “lost” almost two hours of session for long settling time.
I use guider exposure time - 4sec
SGP is outstanding for long exposure times, but for short exposures?
Later i will post log from this session.