Although SkyGuard Integration was not listed in the features of the 3.1.0.198 Beta, it is actually enabled!
SkyGuard can be chosen in the guider drop down and should work in a similar fashion to PHD integration.
I have not been able to test it yet other than enabling it but plan on doing so ASAP & will report back my experience.
Best,
Bruce
Yepā¦ It is technically open. Use it if you are comfortableā¦ working through a few issues still.
I was planning on using it but testing over the last 24 hours has shown it to be unstable and I am not going to chance wasting the nights coming up in Arizona. I already have USB traffic at 40 Iām running a fast laptop I have direct cables from the cameras to the laptop and still have any out of memory errorās that Gaston says are due to USB issues.
Falling back to focus lock and PHDā¦
The SkyGuard integration is very much deserving of the ābetaā (if not āalphaā) tag. Weāre still working out some kinks but I believe I have this issue addressed. Hopefully testing it out this evening if the weather plays nice 
Thanks,
Jared
Hi Ken & Jared,
Iām embarassed to say I thought I was responding to my buddy dts350z/Glenn! Iām leaving on Friday morning for a trip to Portal Arizona and just a little stressed. I actually was planning on testing something out that Gaston suggested that might relieve the instability but Iām tied up at work and it looks like itās not gonna happen tonight. I think the safest bet at this point is to go with what I know works and pick it up after I get back and try and get ready for the next trip down the road. Part of the trouble Iām having is related to the fact that Iām using identical ASI 1600 MM pro cameras for both guiding and imaging. It makes it a little difficult to get it going without crashing the camera driver and iām not sure if thereās anything that can be done about it other than using a different camera for either guiding or imaging. Iāve been using the OPTEC Ascom Hub to get everything connected. If there was an easy way to specify one camera for imaging and one camera for guiding it would be great but it seems that the first camera that gets connected it is assigned camera ID zero and the second connected is camera ID one. In order to get this going I have to actually physically disconnect the guide camera before physically having the imaging camera connected and connecting it via software. For now Iāll stick with my DSI pro two for guiding which unfortunately doesnāt have an ascom driver so wonāt work with SkyGuard.
I really appreciate you guys working on this!
Thanks so much,
Bruce
Iām not entirely sure when youāre seeing that issue. The problem that I have addressed is generally around dithering and is working pretty well this evening after adjusting a timeout in SGP.
As far as the dual ZWOs, if youāre using them with the ASCOM drivers in both applications then they should work fine but it may be a little bit of a dance to determine which youāre connecting to SkyGuard and which to SGP. Iām not entirely sure of a good way around this to be honest. Just that youād have to connect one, loop and see what you get. Then connect the other in the other application but Iām not entirely sure how youād know not to connect to the already connected camera. I donāt believe their driver gives you this information. Might be a good question to ask ZWO.
Jared
The error I pictured was a result of an out if memory error attributed by Gaston to USB3 Traffic. Gaston said it might be prevented by more binning (6x6) or using Block compression. Given more time I would have tested it before my trip but cāest la vie.
There is actually a way to differentiate between the 2 cameras. The first camera physically connected to usb is assigned ID0 in the Ascom driver setup. The 2nd connected is ID1. If left connected during a reboot, the assignments may change. The driver will crash if 2 apps try to access the same camera id simultaneously. If the system crashes for any other reason, you have to disconnect and reboot to start over. Itās tricky and a pain. I got a 2nd ASI1600 because I read that it would be ideal as a guider but didnāt envision the connection complications.
Iām definitely looking forward to using sky guard and SGP together sometime soon!
Thanks Again,
Bruce
This may be down to the driver developer. When I did the Atik driver I read an ID from the camera and linked that to the instance of the ASCOM driver. This would remain fixed until it was changed in the setup dialog by the user.
Hi Chris,
That sounds like that might be a great solution. Iāll get in touch with ZWO and see what they say. Maybe they can make a change to the driver without too much trouble.
Thanks,
Bruce
I guys. I can report that I have used SkyGuide with SGP last week (only one night) with relatively good results. All went well no bugs or error message. I will try it again as soon as I can get clear skies but It was working fine for me. Pretty cool stuff @Gaston and @Jared 
I got way better results with SkyGuide (guiding full-frame) than PHD2 on that night. Looking forward to try it again this week.
Still working on finishing up the focusing piece. Weāve had a rash of issues over the last 2 months at the remote observatory where I do most of my SGP testing (at least what actually requires sky). Hopefully they will be resolved soon and I can get the focusing piece implemented. Likely it will be just the ability to wait for focus since SGP shouldnāt really need to do much.
Thanks,
Jared
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.
Thanks,
Jared
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.
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!
AndrƩ
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.
Thanks,
Jared
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?
Thanks,
Jared
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.
Thanks,
Jared
