Status of ASI6200 Fix to SGPro

Over a month ago, Jared posted that SGP was working with ZWO on a fix to the ASI6200 USB3 download problem. What is the status of this fix?

JaredFounder & Developer

Jun 27

Working on a fix with ZWO at the moment.


1 Like

I have a ASI6200 sitting on my desk but haven’t had time to look into it. No change at the moment. Hopefully soon.



Here are a few pieces of information which perhaps will be helpful to you.

I had been having success downloading ASI6200 images in SGP when I used a short 6’ cable running USB3, or a longer cable running USB2. But lately both of those options have become unreliable.

However, the last few nights I have had a 100% download reliability rate using USB3. I made a few changes in the hopes of keeping the USB path as clean as possible and the amount of activity during downloads as low as possible. The changes I made were:

  • I checked the box which reads “Pause guiding during image download” in the AutoFocus tab of the Control Panel.
  • I unchecked the “Enable image history” box in the Image History module.
  • I avoided any file transfers to/from my computer during the imaging time, and I had no other computer activity going on.

All of this was done with my normal long (12 ft) USB3 cable and USB3 connection.

Please let me know if you have any questions.


An update:

The above changes worked for a few sessions but now I am back to dropping subs again in SGP. I have since read in the SGP manual that the “Pause guiding during image download” feature only works for SBIG cameras. That is too bad, since it might have helped for this camera. I recommend that the option in the program be changed to read “Pause guiding during image download (for SBIG cameras only)”

I now have to go back to using NINA instead of SGP. NINA has worked flawlessly downloading over USB3 with this camera.

My experience with the 6200 has been: the reliability of downloads probably has little to do with the length or quality of USB3 cables, nor the amount of RAM in your PC. Whether a download succeeds or fails appears to be a completely random event. When I initially set up my new imaging train with new mini-PC + Win10 I had SGP frame and focus downloading and saving 5-sec exposures (total of 13 second cycle including download time) with PhD downloading ASI120MM guidecam images at 1s intervals, and me randomly changing filters in the EFW. EFW and guide cam were using the 6200’s internal hub, so all comms through the 6200 via USB3. That worked for hours on end. Rebooted and that then failed within 30 minutes.

Changed USB cables several times (long and short). Failed after random lengths of time.

Ran separate cables from 6200 (USB3), guide cam (USB2), and EFW (USB2) back to the mini-PC. Same deal.

Trying bin 2 and bin 4 in frame-and-focus made no apparent difference to how quickly or slowly a download error would occur. If the problem really is related to a 32-bit software limit then I would have expected binning to cause proportionally less errors, but so far that doesn’t seem to be the case. I have yet to see an “out of memory” error either. I’m not a professional programmer but I have developed a lot in in-house software over 3 decades, and given the previous two points I can’t help but wonder whether there is a coding bug somewhere in the system (SGP, or the ZWO Ascom driver).

After 3 x 6-hour imaging sessions I appear to have not yet had a single image download failure when running a sequence, but that may simply be because I’m using 6 minute exposures, resulting in a low number of total image downloads from the camera.

In any case I will certainly appreciate any effort you can put towards making downloads from the 6200 more reliable Jared, understanding you’ll no doubt have your plate full with other matters.



Thanks, Ross, for sharing your detailed and well written reply.

It is an odd and difficult to diagnose problem for sure. I have been carefully trying different setups to see if anything makes a difference. Everything can work fine for hours on end, but as soon as the first failure occurs, subsequent failures are much more likely to occur until the computer is rebooted. I have had better luck with a USB2 connection than USB3. My experience has been similar to yours with one exception - I haven’t noticed any difference with exposure time. I usually image at either 2 minutes or 5 minutes, and both are similar in the problem frequency.

Since the camera works flawlessly in NINA under ASCOM, I don’t believe it is solely an issue with the ASCOM driver.

Numerous people with similar setups have contacted me about this problem with SGP and this camera, so I know it is not an isolated event.

I have the same issue here. If I used the original usb3 cable from zwo, it never worked with my mini-pc but the first time. If I used it with my slower usb2 interface on the laptop, it never failed.
If I use bin2 mode, it seems it always works.
When the failure starts to occur, it will continue until SGP is restarted, then the first download after that always works.

If I use the special usb3 cable Gary mentioned in another post, it works 95%+ with my mini-pc, no matter what bin mode it is. I take 5 min subs most of the time and the success chance could be even higher.
If I do sub second flats, it might fail 1 in 10.

This is a tricky situation. Just try to provide some feedback.


Thanks, Chen, that is useful to know.

If this is a Windows 10 machine, is there any chance this could be related to one of the latest Windows updates that has turned power saving on by default on the USB ports?


Jim, I am using Windows 10 on a gaming desktop. I will check the USB settings. Thanks!


I had this problem with my Pegasus Powerbox. One of the Windows updates had defaulted my USB ports to sleep during periods when they weren’t being used. Here is an article about turning that feature off.

Not sure if it’s a fix, but worth a try.

Good luck,



Well, to be honest, I had no hope of your suggestion being successful after all of the many hours I have spent addressing this issue. Especially since I am using a desktop. I am plugged in constantly -why in the world would Windows 10 default to a setting which saves power on my USB devices by suspending them?

So last night I checked, and sure enough this feature was ENABLED for some reason. So I disabled it and began imaging, using the normally troublesome USB3 connection.

The result? It ran flawlessly all night, and so quickly compared to my normal USB2 runs!

Before I claim victory, note that I have previously in this thread had a “solution” which ran well for a night and then failed. So time will tell whether this actually fixes the problem. But if it does, you are a hero to me and numerous other imagers worldwide.

Thank you!

I just did some testing. Disabling “USB selective suspend setting” did not work. I looped 1 second exposures with frame and focus. For a while downloads worked. Once my hopes were high it reared its ugly head. I closed/reopened SGP and was able to repeat the error several times.

Oh well. Very disappointing. It is an odd and difficult problem.

UPDATE - I have now run 30 hours of ASI6200+SGPro without a single dropped frame. I am running the same setup that I previously used successfully for my ASI1600:

  • 12 ft USB3 cable directly from camera to computer
  • Also running OAG over same cable (through camera port)

The only difference to make this work was that I disabled the “USB Selective Suspend” setting.

Hi Gary,

That’s great. There’s also another setting that’s buried. Go to settings, Power&Sleep, Additional Power Settings, Change Plan settings, Change Advanced Power Settings, USB Settings, USB Selective suspend settings, Set to Disabled.

Not sure if it’s needed in addition to the USB settings in Device Manager, but who knows? :slight_smile:



Ah, so frustrating. After a number of flawless nights, last night was terrible again despite the exact same conditions. I am back to waiting on SGP and ZWO to come up with a solution to make this camera work with this program.

Sorry that didn’t work out. Bit of a mystery, and not fun. Good luck.