Camera communication speed adjustment

Some older cameras, such as the Celestron NightScape 10100, are USB 2.0 based and aren’t able to communicate with the app as quickly as more modern USB 3.0 cameras can. Other applications such as SGP realize this and have a “Download time(s) / Options” location where the user can select a default timeout value as well as a “high speed” mode … this allows the slower cameras to be able to communicate with the app without the app interpreting a slow response as a dropped connection and issuing a retry while the camera is still working on the command, sometimes locking up the camera.

I would suggest the ability for the user to be able to adjust the command response time (on a scale of 1 to 10, 1 is “fastest” and 10 is “slowest”, say a few seconds) interval to a camera ASCOM command; this is different than the download save timeout (which controls how long the app waits for the camera to respond to the download attempt) and the “ASCOM ImageReady Slow Polling” (which controls how the app queries if the camera is ready to send the information), rather this would be a drop combo with those ten values in that same group box and would control the interval waited between ASCOM commands issued to the camera …

Download in ASCOM is done with methods and properties in interface. I can do only in this way. Download time is only for statistics and for calculating sequence duration more accurated. Voyager have a AI to do this.

High Speed usually is a readout definition … is ASCOM driver that allow or not high speed download. You can get it in Readout Mode configuration in Voyager -> setup -> Camera. If is allowed you see in the combobox.

You mean your camera doesn’t retrieve Readout modes (empty list) and must be go in Camera.FastReadout property set to false in ASCOM interface ? Or when i Download i send command in slow polling to the camera according an interval you can adjust ?

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

Sorry but Voyager doesn’t manage V1 Camera Ascom driver version. If you have Maxim or TheSkyX Addon camera you can use instead to use ASCOM. USB3 parameters is out of Voyager management. And ASI and similar CMOS is a very big problem to manage. Some user work with it fine someone no. I cannot run to follow their problems.

Totally understandable … CMOS camera’s have added a whole new universe of pain to the mix …

As to v1 versus v2, the NightScape implements some v2 commands; so, it responds to “hasShutter”, but not to “HasFastReadout” (which is why the checkbox doesn’t show in the config dialog, you properly detect that it doesn’t have that property and don’t display it for the user) … so it does some v2 commands, not all … that’s why “SupportedActions” is the thing to read … and Voyager works very nicely with the ASCOM Nightscape driver today (that’s what I’m experimenting with now, seeing what the fail rate is with that versus Maxim’s native drivers) and you’re using v2 camera commands now … so no issue with that!

And, the ASCOM ASI drivers work with Voyager as well (that’s what I use with my ASI 183MM testing with Voyager) so no worries there …

But someday, in the future, if folks report a problem with camera’s locking up or PC’s locking up after doing a series of commands to the camera then one possible solution might be to introduce an ASCOM “throttle” timeout like I mentioned, just to compensate for firmware that’s a touch too slow …

Thx again!

Mhhhh … i think you are right ! i’m thinking on ASCOM throttle. Now ASCOM Slow Polling doesn’t use imageready before time shot is done and download IA time calculated is done … this work so fine with a lot of poor drived camera … in anycase i can throttle on imageready after this slow poll is finished.

2 Likes