Looks like you may have already done that. I’m copying Gaston’s response here just for completeness:
When using SGP for dithering you should not need to setup any passive delay in SGP.
SGP looks at the current auto-guiding error and waits automatically until it settles.
There should be two parameters for that in SGP, a maximum auto-guiding error threshold and a minimum time.
SGP will resume the next frame of the sequence when the auto-guiding error is below this thresholds for at least this minimum time.
Since the later parameter is a time (in second) be sure that it translates to at least one guider frame with some room.
Let’s say if you use a 5 second exposure time, as an example, for the guider you may want to set this minimum time to at least, said, 8 seconds, this should account for the exposure time as well as the download and SKG calculation time.
So it seems like setting the “Settle at X for Y” time to be “your auto guide exposure plus a couple of seconds” should account for it. I’ll play around with it this evening and see how that works. I have some reservations about detecting Fast Dithering and making the wait time automatic. Maybe having the wait time being automatic is Ok but not part of the “Settle at X for Y” as that seems like it should remain separate and as it is. Essentially if it is set to “Auto” you get a mandatory delay of “Exposure Time * 1.25”. And then if you want additional settling after that it’s up to you?
Dunno, I’ll play around this evening (assuming good weather) and see what I get.
Awesome! Thank you @Jared for your help. Let me know when you will have a fix and I will be more than happy to test it. You Rock Mister And yes, I indeed sent also a side mail to @Gaston and his team on this topic. Hope they will get back to us shortly.
Playing around with Fast Dither. Seems to work well. Honestly I don’t think you need to tweak the Settle time any. As Gaston mentioned in his email, SGP will wait for SkyGuard to say it’s done before we continue. Did a bunch of 5 minute subs with 0 wait time. But my download time is also long enough to cover the 5 second guide exposure. So YMMV…but seems working just fine here. Tweaking the settle time should be all you need…if you need it.
Hello @Jared How are you? I played 2-3 nights with SGP and my free trial of SkyGuide and, unfortunately, I seem to have a problem with SGP to ‘‘Resume Guinding’’ after the launch of the sequence. The telescope is slewing in position and the ‘‘Plate Solve’’ works flawlessly, but SGP seems to have a problem with “Resuming Guiding …” even if SkyGuide has settled well below the settling value set in my case at 0.4 pixels in SGP. Skyguide has settled for example at 0.2 pixels) but SGP doesn’t seem to get the information from Skyguide, and I end up with the SGP recovery window … something like " Something terrible went wrong while trying to resume guiding "SGP is trying to recover the sequence etc … If I rock and play for a while with the settings of the “Auto Guide” tab in SGP (like toggling between Skyguide & the Simulator option), I ‘‘sometimes’’ get SGP resuming guiding with Skyguide. Very strange behaviour. In addition, when SGP finally resumes guiding with SkyGuide (if lucky), I still need to set a 30 seconds ‘‘Settle’’ time delay to avoid getting elongated stars after SkyGuide performs dithering. Curiously, this value of 30 seconds is closely equivalent to the “dithering settling time” displayed in SkyGuide. My stars are elongated if I only set the parameter ‘’ Settle to:’’ 0.4 pixels in SGP without setting the settling time in seconds (in my case, at least 30 seconds is needed). So SGP does not seem (in my case) to wait until SkyGuide’s dithering has settled under 0.4 pixels before releasing the next image capture without a delay in sec. Any Ideas? I am using ‘‘Fast Dithering’’ and the ‘‘Enable auto dithering’’ option in SkyGuide and a ‘‘Settle at’’ 0.4 pixels and 30 seconds delays in SGP. I also tried a 0 sec delay without any success (Getting elongated stars). Guider Exposure time 3 seconds. Thank you in advance for your help and support my friend! FYI my main imaging camera is an ASI294MC Pro and my guiding camera is an ASI290mm Mini. EQ Mount is an iOptron CEM60EC.
Sometimes SGP loses connectivity to SkyGuard and I haven’t determined why yet. It sounds like that is what’s happening here. SGP attempts to reconnect…sometimes it’s successful, other times not.
If you happen to have a log of these events it may be helpful trying to track down what is happening.
Ok @Jared. I will send you the logs of my next session. Thanks again. Until then I’ve just reinstalled SkyGuard (paid version) and SGP (latest beta version / fresh & clean Install) to see if that will make any difference.
Hello @Jared. Yesterday after reinstalling both SGP (latest Beta version & SkyGuard) everything was magically working. Also the http://localhost:59590/skyguardcallback was returning a valid message when I was opening this link in my Browser. Bizarrely now when I run it today in my browser with both SGP and SkyGuide Open I am getting an invalid message. See image below:
I’m more surprised it was returning any data. But the only thing that would throw a null exception from that endpoint would be if the SkyGuard API was null. That endpoint is used for SkyGuard to send us data, so it’s a push from SkyGuard. I wouldn’t expect SGP to output any data from there.
I would expect it to be somewhat successful (not a null reference) if SkyGuard was connected and working…but by posting bad data here you may also be causing issues…so I wouldn’t recommend it
Not sure what you mean by Posting Bad Data… Ok well sorry @Jared if that was confusing and that you consider my last post has “bad data potential causing other issue” Just trying to figure out what is going on between SkyGuard and SGP when they stop communicating.
I will just send you the log file next time I am encountering the previously describe issue.
Essentially that endpoint isn’t meant to be called except for by SkyGuard and we expect certain data to be sent at that endpoint as well (it is not a “get”, we’re expecting data to be posted to us)…I probably need to add some additional protection around it for when people start snooping
All I was really trying to say is that hitting that endpoint isn’t really a great indicator as to the state of the SkyGuard/SkyGuide status.
Hoping for a few clear nights later in the week to test. Sadly this is what we’ve had for the last few nights:
@Jared or @Gaston I posted this in a different thread that was compounded with a different issue. The main issue in that thread has been resolved, so I’m joining the SkyGuide issue to this thread for consistency.
I’m having an issue with SkyGuide reporting the distance on the guider. This was my first attempt to integrate SkyGuide, so I haven’t had a successful run with it yet. SkyGuide fired up nominally and all was well and seemed good to go. It was dark calibrated, had undergone calibration successfully, and was guiding and configured for dithering. I started the sequence and all worked as it should until after my first AF run, at which point SGP reported it was waiting for the guider to settle and the current distance was 707.1. This value never changed, both with dithering enabled and disabled in SkyGuide. I watched SkyGuide run the guider for some time with success, but SGP never received information that the guider was settled. My auto-guide settings had it waiting for setting under 1.0 pixel for 8 seconds (guide exposure of 6 seconds). I also tried it with settling settings off, and got the same result. Despite SkyGuide continuing to guide as it should, SGP never continued with the sequence.
Is there something I have configured incorrectly? I’ve attached the relevant log file…it seems like it is just unable to communicate. While waiting, I got the same message over and over:
“[08/25/19 22:29:43.494][DEBUG] [Sequence Thread] Waiting for Auto Guider distance to fall below 1
[08/25/19 22:30:13.131][DEBUG] [Unknown] SkyGuideApi Sending - SKSS_UnregisterCallbackURI?uri=http://localhost:59590/skyguardcallback
[08/25/19 22:30:13.133][DEBUG] [Unknown] SkyGuideApi Sending - SKSS_GetGuidingStatus
[08/25/19 22:30:13.145][DEBUG] [Unknown] SkyGuideApi Sending - SKSS_RegisterCallbackURI?uri=http://localhost:59590/skyguardcallback”
Any help you might have on this would be greatly appreciated!
The multiple register callbacks seem like we’re not hearing back from SkyGuide and SGP is trying to re-register the endpoint with SkyGuide. I have not done any testing against actual SkyGuide (it has all been SkyGuard) but my understanding is that they should be identical. I’ll test with SkyGuide and see what results I get.
@AllAboutRefractors and @Jared
I got this exact same issue while using “SkyGuide” Free Trial. I was also getting the “707.1 guider settle distance message”. I have purchased SkyGuard and installed the latest SGP Beta version (3.1.0.213) and everything is working fine since then.
I’ll check out SkyGuide. Sadly I just learned today that my obs machine is likely dead. so I guess there’s a 14 hour round trip drive in my future to address that at some point. This is my primary setup that I do the SkyGuard testing on but I can likely simulate well enough to troubleshoot this.
Thanks for the confirmation that it seems related to something specifically with the SkyGuide piece.
@acarrier Thanks for the info! I’ll try upgrading to SkyGuard to confirm.
@Jared sorry to hear about your obs machine! That’s not fun at all. Thanks for working on it. I’ll report back here after switching to SkyGuard and see if I can confirm acarrier’s experience
Just wondering why all this work is being done with SkyGuard? Is there any evidence that it is doing a better job than PHD2 Guiding? I routinely see PHD2 Guiding performing sub arc second guiding. It’s hard to imagine needing (or getting) better.
Good question. I’m interested in SkyGuard even though I generally get good results with PHD. SkyGuard uses the entire image from your guide camera for both guiding & continuously focusing. It works with the ONAG to do this or alternatively with a device called a Lacerta. It uses the near infrared part of the spectrum which is less affected by seeing. The thing that attracts me is that when the seeing is marginal, PHD is less accurate in my experience. Yes, if I’m watching PHD, I can lower aggressiveness & lengthen exposures to try to compensate but I’m not always watching it & I’d prefer a more automated & accurate way to deal with varying conditions. The full screen guiding & full screen continuous focusing should improve on the accuracy of both guiding and focusing under less than ideal conditions. I currently use FocusLock & PHD but I wouldn’t mind something a little bit better to possibly maximize my odds of getting a few more useable subs per night. I trialed SkyGuard but had trouble getting it working when dithering with PHD & it also revealed a problem with my QHY174 driver that QHY has yet to fix. When these issues are resolved, I plan on moving to SkyGuard.
And yes, I indeed sent also a side mail to 
I will try it again as soon as I have clear skies this week.
to troubleshoot this.