Well, obviously, I do. A 6ft cable is long enough to be routed from my camera through the mount, to my NUC computer attached to my pier. I have no worries about cable snags or planning meridian flips etc.
I’m not arguing with you or denying what you’re saying, just trying to understand why my setup works great and yours doesn’t.
Do you know what version of the native driver and ASCOM driver you are using? I’m using camera driver 3.0.0.7, ASCOM driver 1.0.3.28.
The ZWO native driver is also 3.0.0.7 and the ZWO ASCOM driver is also 1.0.3.28. I was on the verge of purchasing NUCs until I realized NINA works perfectly with all of my cables - I assume other capture software works as well. The 6 ft cables you recommended arrive tomorrow. 6 ft cables are a pain for my setups though so I’ll be using NINA for now.
Jared’s comment about 64 bit support not available yet for SGP is probably why the 6200+SGP is limited to certain 6ft cables. I hope the change is made soon. Joel, you seem like a perfectionist so I imagine you’re in favor of the upgrade.
A 6’ cable would not even make it out of our mount with sufficient slack for the scope to move in Dec. Requiring such short cables for reliable operation is untenable. Our installation uses startech powered USB hubs mounted to the telescope pier.
I don’t understand how cable length could be the culprit when other software is able to download hundreds of images without issue? Presumably hardware issues would hit all software?
Switching the plate solver to ASTAP solved the overflow issue, in fact it seems to work much faster and doesn’t have the annoying 10 second countdown after solving. So, hooray for that.
Unfortunately about half of the exposures taken last night failed to save, which is pretty atrocious. What is strange is that plate-solve and focus frames never fail to download, even at 1x1 binning. Between that and the fact that other software doesn’t have the same problem, it seems to me that the issue is not getting data from the camera to the PC (as in USB cables) but rather something SGP is doing with it once it arrives.
With how popular IMX455 chips are going to be, I hope a fix will come for this soon as its a dealbreaker.
Did anyone say that? I certainly didn’t. Somewhere in another thread I simply gave an example of a cable that worked for me, but that doesn’t have anything to do with the length of the cable (as long as it’s shorter than 15ft I think).
I’m glad that ASTAP solved one issue for you. Please understand that I do not have the necessary technical knowledge to know what is going on or how to fix it. I am simply giving an example of a combination of equipment that works for me 100% of the time with two ZWO cameras simultaneously with SGP.
In particular, I note that you are using a Startech USB hub. I also have a quality Startech USB 3 powered hub that I am using. However, no matter what I tried I could not get 100% download reliability if I connected the ASI6200 to that Startech hub. So I ran a cable directly from the camera to my NUC computer mounted on the pier and now I get 100% download reliability.
I still use the Startech hub for all my other equipment, including an ASI2600 and everything works perfectly.
I’ve tested with many different cables and length is a key factor. The shorter the cable the less download issues. That may not always be the case depending on the particular cable but there’s a strong correlation. That testing was done without a hub.
Not that this pertains to the topic at hand but I am going to be buying this same camera as soon as I can.
That being said, I like to dabble in software and was using nina ealier tonight with my QHY16200A. First I used the QHY driver (not ascom) and the image hung on download. So I switched to the ASCOM driver. Did a few test exposures and it went fine. Then I started a sequence and it hung up again on the first image in the auto focus run.
I use an Icron Ranger 2304 which has been bullet proof for years.
I then gave up with nina for the night and launched SGP. No problems at all whatsoever.
I bring this up because unlike some of you guys in this thread I have the opposite issues. SGP works nearly flawlessly for me and has for a couple years now. Whereas everything else I try I end up with issues and deal breakers that convince me yet again that SGP is where I need to be. Now hopefully if Jared, per the post right above mine, found an issue with ZWO and the 6200 and is working it out, that’s great! Hopefully that’ll be resolved before I find money laying on the ground and can buy one. 
Hi there ,
I am having the same king of problem with SGP and the asi6200mm . I am using the ascom driver (1) . Sgp crashes randomly on frame and focus and sometimes in images saving . It crashes also very often (each time) in the flat calibration process .
More over sgp takes 4 seconds to upload the image . As sgp is not stable with this camera, I had to move to prism10 and use the regular zwo driver .
The regular zwo driver is fast . Quite instantaneous upload and do not crash . It is a pity that sgp does not handle the regular zwo driver because this camera could be the next future of astroPhotography and, I love sgp . Hope that this really big concern will be fixed soon . Crashes are a big concern but upload time also .
I tried : changing usb cables, takes the latest release of sgp, takes the latest release of ascom plateform .Nothing solves the problem.
It works fine with prism and zwo software so, it is not related to hardware problem.
I am also having these download (fail to save) issues with SGP and the ASI6200MM. I am losing about one out of every 4 subs. I have tried various 6 ft cables plugged directly between the camera and my new high speed gaming computer. My drivers are all up to date. I am using ASCOM. I would love to know what Joel is doing to avoid dropped subs. I have tried everything I know. I tried saving my subs to my SSD drive but that didn’t make a difference. The cables and USB port are USB3.
I am happy to send my logs or try something new, just let me know.
SGP and ASI1600MM worked flawlessly together for 3 years.
@Garyl, I wish I could tell you some magic formula to explain why it works for me and not for others. I’m using an Intel NUC computer attached to my pier, and using the driver versions mentioned previously in this thread. I went through two USB 3 cables before finding this one that worked with 100% reliability. But at this point I’m not convinced that the issue is a cable issue.
Hey, Joel, thanks for taking the time to let me know. I had already ordered that cable - it should be here next week so perhaps it will help.
It is such an odd issue. I had run 210 flats the day before with only 2 dropped subs. The only difference is that, then, I was only running SGP (and ASCOM). Last night, when I dropped much more, I was also running PHD2, Polemaster, and APCC (Astrophysics mount software).
The strangest part is how random the drops are. Sometimes it goes a while without any drops, and other times it will drop several in a row. I am not doing anything else in parallel on the PC.
You SGP guys already know this, but here is the section in my log file where a sub is downloaded:
[07/11/20 08:56:42.821][DEBUG][Sequence Thread][SQ;CC;] EventMarker(16) - t:NGC7023-6200-C11 (0); e:2; f:11; o:
[07/11/20 08:56:47.114][DEBUG][Camera Thread][SQ;CC;] ASCOM Camera: Data type -> System.Int32[,]
[07/11/20 08:56:47.114][INFO][Camera Thread][SQ;CC;] ASCOM Camera read image data took 3.38 seconds
[07/11/20 08:56:47.114][DEBUG][Camera Thread][SQ;] SGM_CAMERA_CAPTURE complete…
[07/11/20 08:56:47.114][DEBUG][Camera Thread][SQ;] Camera thread is IDLE…
[07/11/20 08:56:47.331][DEBUG][Sequence Thread][SQ;] EventMarker(17) - t:NGC7023-6200-C11 (0); e:2; f:11; o:
And here is the same section when it fails to download:
[07/11/20 08:56:29.961][DEBUG][Sequence Thread][SQ;CC;] EventMarker(16) - t:NGC7023-6200-C11 (0); e:2; f:10; o:
[07/11/20 08:56:31.829][DEBUG][Camera Thread][SQ;CC;] ASCOM Camera Error : Unable to cast object of type ‘System.Object’ to type ‘System.Int32[,]’.
at so.ik(qw A_0, sz& A_1, sz[] A_2)
[07/11/20 08:56:31.829][DEBUG][Camera Thread][SQ;CC;] ASCOM Camera: Attempting to abort exposure…
[07/11/20 08:56:31.829][DEBUG][Camera Thread][SQ;CC;] ASCOM Camera AbortImage: Camera state is 0
[07/11/20 08:56:31.829][DEBUG][Camera Thread][SQ;CC;] ASCOM Camera: Camera state is idle, abort not needed…
[07/11/20 08:56:31.829][DEBUG][Camera Thread][SQ;CC;] ASCOM Camera: Blocking until image is aborted…
[07/11/20 08:56:31.829][DEBUG][Camera Thread][SQ;CC;] ASCOM Camera: Image is aborted…
[07/11/20 08:56:31.829][DEBUG][Camera Thread][SQ;CC;] Error while attempting to capture frame…
[07/11/20 08:56:31.830][DEBUG][Main Thread][SQ;CC;] Adding sequence level notification: Error attempting to capture image (see logs for more information).
[07/11/20 08:56:31.895][DEBUG][Camera Thread][SQ;CC;] Sending Notification: Error - Error attempting to capture image (see logs for more information).
[07/11/20 08:56:31.895][DEBUG][Camera Thread][SQ;] SGM_CAMERA_CAPTURE complete…
[07/11/20 08:56:31.895][DEBUG][Camera Thread][SQ;] Camera thread is IDLE…
[07/11/20 08:56:31.985][DEBUG][Sequence Thread][SQ;] EventMarker(17) - t:NGC7023-6200-C11 (0); e:2; f:10; o:
The key line being:
[07/11/20 08:56:31.829][DEBUG][Camera Thread][SQ;CC;] ASCOM Camera Error : Unable to cast object of type ‘System.Object’ to type ‘System.Int32[,]’.
One more observation, which I think is important.
This morning as a test I ran my setup in my garage for 100 subs. 25 of them dropped out and were not downloaded.
I then ran the same test again immediately afterward, only this time I plugged by USB3 camera cable into a USB2 port on my computer. This time, all 100 subs were downloaded. None dropped out.
So obviously the issue has something to do with USB3. The subs take longer to download in USB2, but at least it works that way and I have a temporary solution until a fix is made.
Going from USB3 to USB2 can affect the quality of video with this camera, but I think that the only impact on images is the download speed.
USB 3 stinks. I wish every electronics maker would adopt USB-C as that has seemed far more reliable and consistent.
Earlier in the thread Jared said they are working with ZWO on a fix. Hopefully that comes soon! I switched to NINA last night after going through all this (in another ASI6200 thread) and no images failed to download. I don’t like that as a fix because I much prefer SGP and have other thing things that depend on SGP for automation. However, if you want to continue using your existing USB 3 setup, switch to NINA until the SGP fix is released.
Thanks,
Charles
Thanks for that, Charles! I think I will stick with SGP and USB2 for the time being, since I love SGP and I have it set up to my liking. But it is nice to know that I have NINA as a fallback in case I have another frustrating night. If I was starting from scratch, I would definitely go with NINA until this is fixed.
Hopefully SGP and ZWO can work together to come up with a better solution here.
Joel - an update. Your cable recommendation worked like a charm. 100% reliability on USB3. So this issue is definitely related to USB3 and can be resolved with a high quality short cable. Unfortunately, 6 ft doesn’t give me enough length to do meridian flips, so I am trying other 10 ft cables to see if they work. Too bad that manufacturer doesn’t make these cables longer than 6 ft.
That’s great Garyl.
Unfortunately (and I really, really hate to say this) but after 3 months of no download issues at all, I took some flats yesterday and 1-2 out of every 30 failed to download. Absolutely nothing changed in my setup so I’m not sure why. Thankfully, I haven’t lost any lights at all during the last two nights. Unless it gets worse I’ll leave it as is for now. If it gets worse I might just use a USB2 cable and see how long the downloads are.
Joel, FYI: for me, the USB2 download times of the object image subs aren’t terrible. But the problem is all of the other downloads that need to happen - platesolving, focusing, etc. It really adds up to a lot more time when imaging with this camera in USB2 mode.
Hi all, I know this is an old thread, but has anything been solved here. I’ve recently purchased the ASI6200 and am getting dowload (failed to save) errors. I don’t get them initially, in fact I can do lots and lots of exposures with no problem, and all of a sudden last night every other frame (no deviation) was not saving. I tried pausing but it was very consistent… 50% efficiency is not good.
Terri