QHY Native Driver

I see that SGP now supports ZWO native drivers. Are there any plans to adopt the native drivers from QHY? There is a substantial difference between their ASCOM and native drivers regarding download speed and, of course, access to offset parameter.
Thanks.

–Jon

We are no longer supporting ZWO native drivers. It is simply too time consuming and we have had requests from ZWO to terminate support for native.

There shouldn’t be… ASCOM and “native” both use native drivers. If they are significantly different, there is a problem elsewhere (likely settings)

Officially, dynamic offset is not supported for ASCOM cameras. If the ASCOM group changes their stance on this (there is no indication this will happen), we will support it.

Thanks Ken for the response.

–Jon

I was about to post a new topic when I saw this, so I hope you don’t mind my chiming in. I have a QHY600M camera. I can take 1s exposures with another application that has a 64 bit native driver and I get a new image approximately every 4s. With SGP using ASCOM drivers, I get an image every 16s. I see you say that if they are different “…there is a problem elsewhere (likely settings)”. What settings are you referring to, if you wouldn’t mind telling me. I have checked the settings and they are all the same (read mode, etc.), I am using the same bin, I am writing images to the same folder. Honestly, I am quite confused.

Thank you in advance for your help!
Tim.

1 Like

Actually, I found that it wasn’t the native driver that was making the difference. I too was using another application and achieving extremely fast download times. The difference, it seems, is not in the drivers but apparently in how the applications differ in handling the downloads. I read this in a thread on Cloudy Nights so I have no credible way of verifying it. I can attest to the fact that using the native drivers in the other application leads to the very fast downloads vs. using the ASCOM one.

–Jon

I am confused…In your first sentence you say that “…it wasn’t the native driver that was making the difference”. But your last sentence says “…using the native drivers in the other application leads to the very fast downloads vs using the ASCOM one”. Am I misunderstanding what you have said? These two seem to contradict each other.

I very much appreciate your response.
Tim.

Sorry for the confusion. I think the part where I am losing you is the “…in the other application” part of the latter sentence. From my understanding, the other application handles the downloads differently than SGP. The other application is what makes the difference when using the native driver. i.e. if SGP did use the native driver, it probably wouldn’t make a difference. It’s the way that the other application handles the downloads that matters. However, the other application is still slower when using ASCOM. Again, sorry for the confusion…

–Jon

Also note, in another thread, ASCOM are close to fully releasing a new Camera device spec, which includes offset and gain settings. K&J have already indicated that they will be able to use that to access these settings for all cameras that support ASCOM, regardless of make.

Thank you for the clarification. In the past, Ken has stated that the download speed of SGP is mostly dependent on the speed at which the ASCOM driver delivers the image. (Ken…Please forgive me if I’ve mis-quoted you or changed the meaning by how I paraphrased the above). It seems you’re saying that the other application you are using is slower when using ASCOM, but still not as slow as the performance we are seeing with SGP. Do I understand you correctly?

Again, thank you all for your response.
Tim.

That’s great! Thank you buzz.

That is correct. I don’t know what the reason is other than it was mentioned to me that the downloads were handled differently.
Also to clarify, SGP is still the software of choice for me as the other features are simply rock solid and the download speeds are still acceptable.

–Jon

Hi Jon:

Thanks for the response. I am coming to the same conclusion…

Best and CS.
Tim.