ZWO Camera Conflict (1600 and 120 co-existing)

[JSeaman]

Hi all, I'm having some challenges!

I have been using an ASI 1200mm Mini for some time as a guide camera and it works well.

I have just bought an ASI 1600mm and it works well too.

Together, however, they suck! I found a lot of people having a lot of issues too but I haven't been able to find a solution. It seems that when both cameras are trying to image it will fail (either the 120mm in PHD2 does a reconnect or, worse, the download of a picture from the 1600mm in Nebulosity just hangs and doesn't recover). It is easy to reproduce the issue by running PHD2 with a 1 second duration and taking a series of 20 exposures at 1 second in Nebulosity. 

Things I have tried:

1. Latest versions of PHD/Nebulosity

2. Latest drivers (Ascom and ZWO)

3. USB 2 and USB 3 port test

4. Running Ascom(1) and Ascom(2) as well as ZWO native's driver with ASCOM

5. Various USB speeds, right down to 50 on the 1600

 

I am running a Startech powered hub which is on an Ethernet link 20 metres away and is stable and reliable so this is specific to the two ZWO cameras. Any ideas?!

 

 

Edited February 19, 2021 by JSeaman

[JSeaman]

Might have found something! If I set PHD2 to use the ZWO native driver and Nebulosity to use the ZWO driver it seems to coexist better, the ZWO ASCOM driver is the one that is troublesome (on either end)

[JSeaman]

Yup, it's definitely that - in PHD2 you can see it updating every 1 second until you start taking photos on the 1600 in Nebulosity then it is really laggy with delays of several seconds before updating. They coincide with the time the ASCOM driver was failing but the ZWO one recovers, if someone else has similar issues try native drivers everywhere!!

[Xsubmariner]

I also have the Asi120 mm (USB 2.0 variant) as guide camera on one of my rigs and it has been working fine for ages using SGP & PHD2 with either Atik383 or Qhy 268c or 1600mm on a dual rig setup. Following a recent camera shuffle I now have the 120 guiding and a QHY268M and 1600mm pro as imaging cameras on the dual rig arrangement. During the 2 nights I have finally managed to get some imaging done I have encountered problems with the PHD guide camera (120) image fluctuating and acting strange., this was while imaging with the QHY as the main imaging camera and while the 1600 was connected to the USB hub but not operating within any SGP program. 

While I encountered the problem I attempted to deselect and reconnect the 120 camera with device under PHD, making sure I chose 120 as opposed 1600, then selected 8 or 16bit then connect. This seemed to recover the guiding for a short period, then the image/guiding problem started again. In the end, the only way I recovered the imaging session after repeated guiding problems was to disconnect the 1600 from the USB hub, then everything worked fine for the remainder of the evening.

Now I know this setup used to work fine on the dual imaging rig so something has changed to cause the problem, while a Windows 10 update would be my first suspicion (as I have had so many problems with these in the past), or some other software SGP (SGP is limited to 3.2 variant as I choose not to subscribe), PHD2 or ZWO. I don’t think this will be a quick solve. Hay Ho. 

 

Edited February 20, 2021 by Xsubmariner
Correction

[JSeaman]

The 1600 definitely seems bandwidth heavy over USB. Drivers has to be a good place to start if you're not using the native ones then I would switch. It is worse at the point of taking an image so I set PHD and Nebulosity (SGP in your case) both at 1S so I could fault find better. 

[Dr_Ju_ju]

I also run the USB2 version in conjunction with the 1600, using the 1600's hub with filter wheel & never had a problem, but the all other connected devices are connected through dedicated USB hubs either 2 or 3...

If you're brave\confident enough, it may also be worth checking how much throughput you're actually getting on the USB ports, following this (How can I view USB device bandwidth allocation in Windows 10 - Microsoft Community) will at least show you what your getting & whether there are any bottlenecks...

[Xsubmariner]

Thanks Dr-ju-ju, I reviewed the data on the link and as you say, was not brave enough. What is interesting is how Win 10 has removed the ability of the PC owner to check the USB bandwidth allocation for their PC. This would be vital information to determine the best port allocation for your given system.

USB conflicts/disconnects and communication is the biggest fault generator in my observatories and has cost me so much imaging time. Ho Hum back to system fault finding.