GUI integration of SkyGuard (Full Frame Guiding & Focusing) on SGP

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 :crossed_fingers:

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

1 Like

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 :slight_smile: :crazy_face::+1: I got way better results with SkyGuide (guiding full-frame) than PHD2 on that night. Looking forward to try it again this week.


SGP%20Profile

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

1 Like

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.

https://optecinc.com/astronomy/catalog/focuslock/19860.htm

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.


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 :slight_smile:

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é :slight_smile:

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.
image
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

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.

Thanks,
Jared

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 :+1::metal: 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.

Thanks,
Jared

www.mainsequencesoftware.com