I hate to show my ignorance here, but will SkyGuide only work with an ONAG? Why wouldn’t it work with an OAG?
It will work with an OAG if you use a Lacerta in a Lodestar. This is how I’m running mine. I don’t think I have the backfocus to use the ONAG and even if I did it would be a little unwieldy with my rotator and 7 position filter wheel swinging all around. Definitely would cause some clearance issues with my pier.
SkyGuide can guide using any guide camera that’s ASCOM compatible or supported by Maxim. SkyGuard can not only guide full frame but also does continuous full frame focusing & requires either an ONAG or a Lacerta in a Lodestar as Jared said. Continuous focusing is really an excellent way to go…
@Jared and @Gaston I need your help with what seems to be a Dithering Settling Issue. At first, auto-guiding with SkyGuide is awesome. I did not have any issues except for this one. As soon as Dithering comes into action during a session my images have elongated stars every 2 images I take. Looks like a Dithering issue.
In the auto-guiding tab of SGP Dithering is automatically set to ‘‘Auto’’ when selecting SkyGuide (which looks ok at first glance), but when I start the sequence, I get a perfect result on the first image, elongated stars on the second, a perfect result on the third image, elongated stars on the fourth image, etc. This seems to be related to dithering…and the problem is consistent.
@Gaston I read your ‘‘Help file’’ and I configured Skyguide for ‘‘Fast Dithering’’ but I do not know in SGP how to set an ‘‘Exposure Delay’’ as mentioned in the help file to avoid elongated stars due to dithering time (dithering settling). My Dither Time with the ‘‘Fast Dithering’’ option is about 15,000 ms (15 seconds) according to SkyGuide.
@Jared and @Gaston SGP does not seem to have the ability to set an “Exposure Delay” has specified in the SkyGuide help file. The example presented in the Skyguide help file is only for MaximDL. See image below.
How can I manage this in SGP? Should I set the ‘‘Mount Settling’’ parameter and/or the Auto-guider settling to 16 seconds to solve this problem? Or is there simply no way to set up an ‘‘Exposure Delay’’ to solve this problem when using SGP with Skyguide at this time?
This makes the use of Skyguide with SGP impossible for me at this time and I would love so much to use it. Full Frame Guiding is simply Awesome
My two cents - Would be great if SGP could directly read the Skyguide ‘‘Fast Dethering’’ Settling Time and automatically set an Exposure Delay between each exposure sufficient to avoid elongated stars. This would solve the issue automatically for all users.
Thank you in advance for your help and support guys!
I’m unfamiliar with “Fast Dithering” in SkyGuard. However the Auto Guider Settling will add a delay after the guider reports that it is done settling. I’m not sure if that’s what you need or not. But SkyGuard should be telling us when it has completed the dither. I’m not sure why you’d need an additional delay after SkyGuard says it’s done. But again, I’m not familiar with “Fast Dithering”. I’ll see about playing around with it and what results I get.
Ok thanks. But in fact it’s when the Dithering is set to Auto which is the case by default in SGP when selecting SkyGuide. Here is what their documentation is saying:
When using auto dithering option, it becomes very important to set a delay that is equal or greater than the dithering settling time calculated by SKG after each exposure from the image sequencer software. If there is no delay or if the delay between exposure is too short, the resulting image will have elongated stars.
In MaxIm DL, the delay can be defined by clicking the options button and select Exposure Delay menu item.
Hm, I’m not seeing any references to Fast Dither in the 3.3 manual. Can you PM me what you have?
You just have to open their help file within the app (?) and search for Dithering
Here is what they say:
Dithering means shifting the telescope slightly of target randomly between imager exposures. This allows bad pixels, image artifacts, fixed pattern noise, and even satellite or airplane trails to be removed during the imager stacking process. SkyGuide uses the imaging camera status to detect the end of a given imager exposure (shutter closed). When [dithering is enabled] SkyGuide will automatically dither between imager frames, however, the imager must be connected to SkyGuide using either its ASCOM driver our Maxim-DL for this feature to work. When using a third-party software, such as SGP, controlling SkyGuide through its REST API dithering can be automatically imitate remotely. The detection of the end of the dithering move can also be automatically detected using the current auto-guiding error. If implemented this way by a third party software there should not be any need to add any delay for dithering settling time anymore, as discussed below.** See the third-party software documentation for further information about how this has been implemented. To start dithering you must click on the button.
Above the separation line, you will find all settings that must be configured prior start dithering. Dithering range defines the range, in guider binned pixel, that will be used to calculate the random offsets for both axes X and Y. Maximum allows value for the range is one third of the tracking window. Dithering uses the guiding aggressiveness to shift the telescope like normal auto-guiding. If the guiding aggressiveness is low, which is often recommended for normal auto-guiding, the time required to shift the telescope can be long. To reduce the shift settling time the fast dithering option uses an aggressiveness of 80%, or the user setting, what ever is the largest, on both axes during the dithering process. We strongly recommend to use fast dithering option.Below the separation line, you will find all settings that are calculated by the dithering. Settling time is the number of guider frame that are required to settle telescope to the new location. Dithering time is the time in milliseconds that is required to shift the telescope to the new location (settling time).
Calculating the estimated dithering settling time requires some guider frames, if the field is empty when you open the dithering settings dialog box one must wait until the estimated value appear in the field. When using auto dithering option, it becomes very important to set a delay that is equal or greater than the dithering settling time calculated by SKG after each exposure from the image sequencer software. If there is no delay or if the delay between exposure is too short, the resulting image will have elongated stars. In MaxIm DL, the delay can be defined by clicking the options button and select Exposure Delay menu item.
@Gaston Can you jump in to help on this one?
I’ll shoot an email to them and see what’s up.
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.
Ok thank you Jared I will try it again as soon as I have clear skies this week.
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:
Any Idea why the SkyGuardDto and skyguardcallback are now returning a NullReferenceException / Object reference not set to an instance of an object…
The message yesterday was successful…
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.
Have a great day!
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: