Thanks for the quick look, and the new release!
The NightScape camera, being “old and crusty”, has several problems with ASCOM that cause issues with it … first, it doesn’t report back Name, DriverInfo, DriverVersion and most importantly InterfaceVersion properties … so the app (shouldn’t) assume that it’s a v2 interface and query for v2 things like CanFastReadout and even ImageReady. That’s not (usually) an issue though, as most apps are smart enough to not send v2 commands to something before checking if the camera can support it and the NightScape will ignore most (but not all!) unknown commands sent to it …
The second problem is more due to the architecture of the NightScape firmware … they are using a little 4Mhz 16bit chip with likely a small little 32byte FIFO to queue commands to the processor from the USB chip; data comes in, lands in the FIFO, processor reads it from the FIFO, clears the USB chip for new traffic, rinse/ repeat. The problem is that if the processor can’t empty the FIFO before a new USB command comes in, or if the new command overflows the FIFO and the FIFO needs to be flushed then the USB chip won’t be ready to accept the next new endpoint data and will stall. If the sending app isn’t aware of this it may interpret the stall as a loss of connection (which is reasonable, as it can’t tell the difference between a stalled endpoint and no connection at all) and attempt to reopen the connection and retry the send. You can see this happening on SGP with a USB protocol analyzer; SGP sends a rapid series of commands, NightScape stalls for whatever reason, SGP resets/ resends the command and the USB driver locks up as it tries to reconnect to a device that’s now unresponsive. Not Good … usually results in my having to reboot the PC since the hang is in kernel space …
The ASI ZWO folks have a similar problem, which is why they introduced a vendor-specific “USBTraffic” property to their ASCOM driver [https://astronomy-imaging-camera.com/manuals/ASICameras-software-Manual-Windows-EN.pdf], page 15 …it instructs SGP (or whoever) to introduce a throttle value between sending the ASCOM commands so that the processor on the camera can drain the FIFO and not stall the chip …
It’s that “USBTraffic” delay that I’d be interested in adding to the dialog; it instructs the application to delay a certain amount of time between sending the ASCOM commands to the camera like checking the “ImageReady” property (which is a v2 property so you shouldn’t even be calling that on the NightScape since without giving back an InterfaceVersion response it’s a v1 device) to ensure that the camera has drained its FIFO and is able to handle the next command.
If you’d like you could even look for that “USBTraffic” property to populate the value from initially, that would make Voyager compatible with the ASI’s as well …
Hope this helps! And yes, another option is to just upgrade the camera but the 10100 is still a good chipset, it lets me do “real” CCD binning rather than “fake” CMOS binning and it can bin without messing up my Bayer Matrix which modern cameras have apparently lost the ability to do … and the camera’s are $500 used which is a lot cheaper than an equivalent “modern” one! 