I’ve never heard that statistic (but it could certainly be true). What I’ve heard is that the settling time should be longer than your guide exposure so that the guider has to complete at least one guide move, but I also think that’s bologna. 
I have my mach1 set to settle at less than 1px for 2sec (guide exposures are 3sec).
You are going to be outside the RMS error about 30% of the time and outside two times the error for 5%. With multiple samples the probability of one of those samples being outside just by random chance is pretty high. I’d open up the requirement to at lest twice the RMS error.
Hi Chris,
I don’t understand. Are you saying, as an example, that if your total RMS error is 1.5px then you should put 3.0px in your settling parameter or .75px?
Twice. For 1.5 RMS try 3.0
Hi GeneralT001,
Did you every get this resolved? I usually dither every frame with a settle for 8 secs <2.0px, but recently when shooting some v short (10s) exposures for M42 core, I opted to dither only a few frames, but noticed that the 8s settle happened EVERY frame, which kinda defeated why I didn’t dither every frame, i.e. with ~30s download time and 8s settle, each 10s capture was taking nearly 1m…!! It seems logical to me that if I don’t want to dither every frame, then I also don’t need to settle EVERY frame, but I can’t see how/where/if I can turn settle off, but still leave it on for those frames when dithering happens.
It would be great to know if and how you resolved it please.
Cheers, Geof
This is a bug that has been brought up several times. Even when not dithering, SGP sends a settle command to PHD2 between frames. It shouldn’t do that. It is a completely unnecessary waste of precious imaging time and is a legitimate bug that the developers should fix.
Edit: Just found this thread from a couple of years ago:
It appears that this is expected behavior. I encourage the developers to reconsider, or at least allow the option for the user to select settling when there is no dithering. I can only think of one reason that guiding would be disturbed (DSLR mirror movement) between frames, and that doesn’t seem likely. On the other hand, the unwanted settling overhead when not dithering is a large, tangible disadvantage.
Tim
In SGPs defense - if your mount has not actually been moved between frames, then the time taken to “settle” should be very short, assuming you have it properly configured. (i.e. within a reasonable number of pixels for some reasonable amount of time).
I guess the choice the SGP devs have to make is whether it is safer to double check the mount is ready to start imaging (i.e. guiding has “settled”) or to just start imaging regardless.
I guess having an option to disable settling when there was no specific command that would move the mount (dither, slew etc) would make everyone happy 
1 Like
It depends. While the mount is certainly “settled” since it hasn’t moved, PHD2 still has to prove that it is settled when asked by SGP. That means it has to take at least one guide exposure, often more if the settling criteria are fairly tight. Even when it has met the settling criteria, there is often a fairly substantial delay before PHD2 reports that it is done settling. My mount settles pretty quickly, but often this delay by PHD2 in reporting that the mount is done settling can take as much as 10 seconds.
I frequently take hundreds of short exposures - 10 seconds or so - and dither every 5 frames. I need the settling criteria to be fairly tight because I want the mount to be well-settled after a genuine dither. But when not dithering, I don’t want to waste any time settling a mount that does not need it. With 10-second exposures and a 10-second settling time, fully half of my imaging time is often completely wasted waiting for PHD2 to report that an undisturbed mount is settled.
With today’s very low read noise CMOS cameras, people are doing more and more short-exposure imaging. The SGP developers were gracious enough to accommodate a request to dither every “x” frames to help us CMOS imagers reduce the wasted time. But implicit in that request was that the non-dithered frames would have no delay between them. It really doesn’t help to do sparse dithering if the same amount of time is still wasted between frames.
Fair enough - if you are only doing 10s exposures then every second spent doing something else is (literally) another 10% of your imaging time wasted…
What is the download time for your camera? Is it also eating a significant % of time?
I guess I’m at the other extreme - doing 20 minute NB subs - so several seconds spent downloading and settling isn’t so big an impact on overall imaging time.
That does not meet the definition of a bug. It is entirely logical and SGP offer a mechanism to change the tolerance. The issue is that PHD2 takes a while to confirm it is tracking on target. It is not an unnecessary waste of time; for instance, if you pause guiding during image download, how would SGP know that PHD2 or any other guider software is going to smear the next frame getting the star centroid back in line?
Nobody is saying that it shouldn’t settle after guiding is paused. Of course it should. That’s not what we’re talking about. I am referring to the specific and very common case of dithering every “x” frames where PHD2 runs uninterrupted except for the dithered frames. I called it a bug for two reasons. First, it defeats the purpose of dithering every “x” frames, which is to minimize imaging overhead by eliminating time-consuming settling between frames that are not dithered. Second, it is behavior inconsistent with the expected behavior, which is the definition of a bug. The documentation says:
" * Settling will be run:
- After a dithering operation
- After guiding resumes from “pause guiding during auto focus”"
If the documentation is to be taken as a description of the expected behavior, then SGP is not expected to settle PHD2 between undithered frames, but it does. That’s the primary reason I called it a bug.
So, for those that don’t bother with dither at all, you would expect SGP to start every frame regardless of the guider status? Really?
No, not really. I would expect SGP to continue on to the next frame without delay as long as PHD2 reports a status of “guiding”. I dont understand the hostility. It is a reasonable request to allow users tho option not to settle between undithered frames.
Well, I was responding to what I thought was your misdirected attack on SGP.
Let’s walk through the requirements:
- Nobody wants the next exposure to start with the guider off the mark, as that would clearly impact the quality of that exposure, as the guider moves the mount to bring it back during the next few guider cycles. That implies:
-
If the guider is continuously tracking during the download, there should be minimal drift to correct and the next exposure should start as quickly as possible.
-
If you are dithering, you want the guider to be back within the limits before the exposure starts.
In both of the above cases, I would argue that the acquisition system cannot assume the guider is settled but explicitly get a status from the guider system.
This then creates the problem statement:
- When the autoguider is continuously guiding, there is too much delay between exposures.
This then logically suggests the issue is not the act of SGP asking for a settled status that is a bug, but the time it takes for the settled status to be established.
SGP clearly has some form of settling criteria in its dialog - with a threshold and time. I do not know for certain but I don’t think that is the entire story. I suspect PHD2 also has some form of criteria before it reports it is settled. If that is true, the two independently are potentially prolonging the overall settled status.
I typically dither and note that, even though I have 1 pixel, 1 second settle time in SGP, it takes several PHD2 guider cycles (typically 4 seconds each) with the tracking sub pixel before the exposure starts. I would need to step through the log files but I think some of that delay comes from PHD2.
This then logically leads to several investigations to understand the settle criteria and timing in the case of continuous autoguiding and dithering. Only when we fully understand what is going on can we really suggest what might be improved.
The only misdirected attack is the one you are waging on me for making a legitimate suggestion for improvement to the software. It was in no way an attack on SGP and I can’t see how anyone can rationally interpret it that way. Part of the purpose of this forum is to allow users the ability to make improvement requests to the developers. Since you are not one of the SGP developers and don’t appear to be in any way affiliated with SGP, your attacks on me are completely unwarranted and misdirected. It is not your place to determine which feature or bug fix requests are “misdirected” or not.
That’s where you’re wrong. In the case where there is no dither, and using a completely electronic camera (the majority of cases) there is no action whatsoever that would disturb the mount during an image download. PHD2 would continue happily guiding away completely oblivious to the actions of SGP. There would be absolutely no need to settle the mount any more than there is a need to settle the mount in the middle of an exposure. The only status that SGP should care about in this case is that PHD2 is still guiding (which SGP apparently checks frequently).
There are cases, such as DLSRs with mirrors, that could jostle the system between exposures and one would want to settle between exposures and for that reason, I am suggesting that users be given the option to not settle between images.
It is not an outrageous request and it has been requested multiple times by multiple users over the years since “dither x frames” was introduced. After all, the purpose of “dither x frames” was to reduce the amount of wasted time when using large numbers of short exposures - a technique becoming more and more common. A mandatory settling routine between frames that often involved a lengthy wait for PHD2 to report it is done settling defeats the whole purpose.
I don’t care whether this is a called a bug fix request or a feature request. I only called it a bug because it is behavior inconsistent with what the manual says SGP should be doing. I’m only asking that the SGP developers (not you) give it due consideration.
Unfortunately there are always exceptions: it would cause issues for those choosing the option of pausing the guider during image downloads and for those doing temperature controlled focus adjustments between exposures (which can cause an image shift)
You are over-reacting. You have a legitimate issue but my suggested improvement in the system is to reduce the latency between exposures but not by assuming the tracking is good to go. If the system is tracking perfectly already, it should be milliseconds for SGP to request and receive that notification.
You’re wrong. It seems that our disagreement stems from your lack of understanding of how settling works. There is no way that it will ever be milliseconds for PHD2 to settle when asked to, if settling is enabled. First, when using “dither every x frames” one needs to have the settling options set to properly settle the dither. So, even between the non-dithered frames, PHD2 must satisfy those same settling requirements since SGP asks it to. Those settings consist of two parameters. First is the “Settle at:” criterion which specifies the number of pixels of deviation that is tolerable. Second is the “For:” requirement that specifies the amount of time that the guiding must remain below the “Settle at:” criterion. Those are the parameters that must be met for PHD2 to report that it is done settling when it is asked to settle. So at a minimum, the delay will be the number of seconds set in the “For:” parameter. Added to that is the often many seconds that PHD2 takes to report that it is done settling even after all of the criteria have been met. Because SGP asks for a settle between undithered frames, these criteria must always be met regardless of whether a dither occurred. So, unless the “For:” criteria is set for milliseconds, settling can never occur in milliseconds. It just isn’t possible, and even if it were, there would still be the frequently long delay for PHD2 to report that it is done settling. Furthermore, if one did set the “For:” criterion to be a very small amount of time, the dithered frames will not settle properly.
I’m done with this. My intention was to make a suggestion to the developers that would help the “dither every x frames” meet its intended goal by allowing the option to not settle between undithered frames. Since it would be an option, I fail to see how there could be any objection from anyone who would prefer to settle between undithered frames.
I won’t argue with you any further because for one, you don’t speak for SGP, and for two, you don’t seem to understand the issue.
Spokeshave, nobody has attacked you. They may have disagreed with you but that’s not an attack. Please don’t take technical disagreements personally.
That might be true today but if PHD2 maintains a guiding status, just like an ASCOM roof has a open, closed and moving status, PHD2 could instantly respond that it was already settled. I suspect neither of us have a detailed knowledge of the inner workings but it is always best to make any application as robust and as simple as possible to a range of personal circumstances, rather than introduce more user options. I will fire off a note to Andy to see if that is something that is already or planned for PHD2.
I’ve had a look at the PHD2 code and the message requesting the guide error returns instantly so SGP should get a reply within a few milliseconds.
This is supported by a log that was posted earlier in this thread where SGP is requesting the error and getting a reply within a millisecond or so.
In that case the delay was the 4 seconds that the guide error had to be below before imaging resumed, SGP spent 4 seconds checking the guide error before resuming.
The settle requirements are part of starting an image acquisition, not dithering so can be expected to be done before the start of every frame. That doesn’t seem unreasonable, at least each frame starts well guided.
Maybe the solution is to set the settling requirement to 0 seconds, then as soon as the guider reports that the error is below the requirement it continues. With good guiding and no dithering that will be instant.