This document serves to list and describe the ongoing status of native QHY camera and filter wheel support in NINA's shipping versions. This document will be updated as issues and conditions change.
- NINA 1.9 ships with QHY SDK 5.1.0 (20190627_01)
- NINA 1.10 ships with QHY 6.0.5 (20191115_01)
NINA 1.9 currently contains only the native camera driver. It is intended to backport updated camera driver code from
1.10 to 1.9 in order to better service QHY CCD cameras (specifically A-series cameras). It is also desireable to backport
the native filter wheel driver to 1.9, but this requires SDK 6.0.1 or later due to an issue with CONTROL_CFWSLOTSNUM
returning a value of 0 for the integrated filter wheels in A-series cameras. However, SDK 6.0.1 (or 6.0.2) cannot be implemented currently
because they suffer from several memory leaks, which QHY staff are in the process of addressing.
Want: Backport of 1.10 camera driver logic to 1.9
Why: To support A-series cameras as well as readout modes on QHY600 series cameras.
Disposition: Requires SDK 6.1.0 which implements support for QHY600 readout modes; but 6.0.1 (and 6.0.2) suffer from memory leaks. Work can proceed once SDK 6.0.3 is released.
Want: Backport of new native filter wheel driver from 1.10 to 1.9
Why: Enables full native use of A-series cameras and CFWs that have 4-pin cable connection
Disposition: Requires SDK 6.0.1 which fixes CONTROL_CFWSLOTSNUM for A-series cameras; but 6.0.1 (and 6.0.2) suffer from memory leaks. Work can proceed once SDK 6.0.3 is released.
[2020/01/24] The 1.10 release train is far enough along that people who require the fixes in 1.10 should just update to 1.10 instead of continuing to use 1.9. There are no more any plans to backport the QHY driver changes to 1.9.
Nightly builds will generally always have the latest (or close to it) version of the QHY SDK. Current issues being tracked:
Cooling and sensor temperature on A-series cameras eventually falls off a cliff after a period of nominal operation, giving highly erroneous readings. Currently being addressed by QHY.
Full readout mode support in the native camera driver entails supporting readout modes that can also change the dimensions of the image being read off the sensor. The QHY42 PRO model of camera sports such readout modes, where the sensor has dual ADCs which read out the sensor concurrently, but in different bitnesses and dimensions.
Currently, only a subset of readout mode capabilities is implemented in NINA in order to support the QHY600, whose readout modes are all consistent in the image dimensions they produce. Once their QHY600 rollout has quieted down, QHY will be loaning a QHY42 PRO to @daleghent to use in enabling and testing full readout mode support.
A-Series cameras (QHY's "All-in-one" models which have integrated filter wheels and whose model names end with "A") can have filter wheel carousels which have different slot counts. With SDK 6.0.1, QHY fixed a bug where CONTROL_CFWSLOTSNUM retuned 0 for the slot count on these cameras. Now, it returns the maximum possible number of slots that an A-Series camera can have. For most users of these cameras, that is ok, but the ones who have cameras that are equipped with the lower slot count carousel will always see one slot more than their filter wheel has in NINA's filter manager. This is because the USB driver for the A-Series cameras currently has no way of interrogating an A-Series camera for its actual slot count and reflecting that value in the output of CONTROL_CFWSLOTSNUM.
Obviously, it would be best if QHY could implement the necessary logic in their USB driver to get this information from the camera, and this is something they will work on in the future when time avails. In absence of that, we can test the camera ourselves by asking it to rotate the filter wheel to the maximum slot number. If the camera does not do this, we can assume that the camera is equipped with the lower-count slot carousel.
Originally, the native camera driver used GetQHYCCDChipInfo() for learning the dimensions of the image produced by the connected camera. This is fine in most cases, except when a camera model also sports what is known as an Overscan Area (OA). The OA is a line of unexposed pixels, typically ca. 30-50 pixels wide, along one edge of the image produced by the camera. Its useful for embedding calibration data in the image itself. However, most people do not wish to use the OA in which case it encumbers proper image processing. The QHY ASCOM driver offers an option to turn the Overscan Area "on" or "off". The SDK offers two additional calls:
GetQHYCCDEffectiveArea()which returns the illuminated dimension of the sensor - ie, the portion of the sensor which actually takes photons.GetQHYCCDOverscanArea()which returns the dimensions of the Overscan Area.
One might think that the sum of the dimensions returned by both of the above calls would equal the dimension that is returned by GetQHYCCDChipInfo(), but this was found to not be the case in practice. Attempts at proper OA support were abandoned due to @daleghent not having a camera which has this feature on hand, and instead the native driver now just uses the dimensions that are returned by GetQHYCCDEffectiveArea() to learn the sensor dimensions. If access to a QHY168C or other camera model that has an OA can be secured, proper support can be worked out and implemented.
CRITICAL: A very large memory leak was introduced in SDK 6.0.1, on the order of 1-2MB every second. This leak occurs only if the SDK is initialized when there is no camera connected to the system. This leak was found and fixed in SDK 6.0.2, however a smaller leak (ca. 500KB/second) is also being observed in 6.0.2. QHY has been made aware of this smaller leak. These leaks are blocking further progress and the aforementioned backporting of native driver code to 1.9.
Because SDK 6.0.1 is required for proper operation of the QHY600 camera and it contains a lot of bug fixes over the previous version (5.1.0), we can't just revert the SDK we ship with NINA 1.10 to 5.1.0. So for the time-being, QHY users will need to manually switch on the QHY SDK in NINA's options as of 1.10 Nightly 16. The need to do this will be removed when QHY releases an SDK with the memory leak issues resolved.
Resolved with SDK 6.0.3
@daleghent has a new QHY294C which produces an image that contains unexposed areas of the sensor along the top and left edges of the image. Not 100% sure if this is an issue with the camera, the SDK, or the native driver code. Question is out to QHY to investigate and hopefully elucidate a cause. This issue may happen with other cameras.
The image dimension issue was resolved with SDK 6.0.5. Image dimension issues for the QHY600 were addressed by an update to the QHY USB device driver package, which also the way that new firmware is delivered to a camera, indicating that the issue was addressed with a firmware update rather than in the SDK.
Native camera driver currently lacks support for Stream Mode, which can be used to implement Live View in NINA. @khyperia has taken this on as a project. Work is being tracked in PR 339
Finished and merged into 1.10
@daleghent has a new QHY294C which produces an image that contains unexposed areas of the sensor along the top and left edges of the image. Not 100% sure if this is an issue with the camera, the SDK, or the native driver code. Question is out to QHY to investigate and hopefully elucidate a cause. This issue may happen with other cameras.
I'm a new owner of a QHY294C and I confirm that I get some of these pixels top-left and bottom, a thin border of 2px while testing flats. This was observed while capturing with sharpcap too, using the native driver which does not apply overscan. Same thing using the ascom driver with overscan explicitly disabled (in ascom config). Please let me know if I can help testing or resolving issues.
QHY294C
Using DLLs from 2019-11-15 SDK