QHY42 STD image mode

[Frank Zoltowski]

When connecting to a QHY42 PRO through the direct driver (latest 21.8.13.1), there is no way to change the image mode from HDR mode (4096x2048 which seems like the default) to STD (2048x2048). The HDR mode is not compatible with astro imaging as far as plate solving and other applications without preprocessing to split the two images. It works correctly when the ASCOM driver is used.

[Dale Ghent]

Please update to 1.10 HF3 and report back if your issue exists

[Frank Zoltowski]

Yes, Using !.10 HF3, it still defaults to the HDR 4096x2048 format. There is no option to switch to the STD 2048x2048 format.

[Dale Ghent]

Ok the version field in the issue was marked with 1.10 HF1 and there are substantial differences in the QHY driver between HF1 and HF3.

In this case, please change to logging level to Debug (Options > General) then connect to the camera. Please attach the resulting log file to this issue so that I can inspect it.

[Frank Zoltowski]

  <div class="preview-container wiki-content"><!-- loaded via ajax --></div>
  <div class="mask"></div>
</div>

</div> </form>

[Frank Zoltowski]

log attached

[Frank Zoltowski]

Another issue, that maybe I should open as an separate issue, is that under ASCOM, NINA thinks the QHY42 is a color camera with a RGGB bayer matrix. Displays as such, although the files are OK.

[Dale Ghent]

The ASCOM driver issue is a separate issue that is in the QHY ASCOM driver and SDK. NINA uses the SensorType property that is advertised by the ASCOM driver it is connected to. In this case, the QHY ASCOM driver advertises the sensor type to be RGGB. While this is clearly wrong, this issue is on QHY’s side to fix.

As for the reasdout modes of this camera, I will have to ask QHY for details. The QHY SDK advertises that it has a CONTROL_SPEED camera property, which is a property that is normally for CCD cameras regarding their readout speed. If this exists, it supersedes and readout modes as there can usually be only one or the other. This is why you are seeing “Normal” and “Fast” listed in the readout modes instead of “STD” and “HDR”. I will ask QHY if the advertisement of the CONTROL_SPEED property is intended. It likely isn’t, and the same mistake is also likely why the camera advertises itself as RGGB instead of Monochrome.

[Frank Zoltowski]

Thanks Dale,

I already notified QHY about the color camera issue since it look’s like the ASCOM driver problem.

I tried changing the readout modes property to no avail. Hope this can get corrected.

[Dale Ghent]

Yeah in this case I expect that changing the readout mode would not yield any results because the SDK is leading us down a false path regarding readout speeds instead of readout modes. I’ll contact QHY and see what they say about it. I will also mention the sensor type issue as well.

[Dale Ghent]

Dr. Q got back to me on this issue and described what I think is the root of the problem.

The QHY42PRO is unique in that it does have both readout speed AND readout modes, however the CMOS readout speeds are relevant only when the camera is used in streaming frame mode, not single exposure mode which is how we interact with the QHY SDK in NINA. So, while the speed setting is advertised by the SDK as being available (and is thus overriding the readout mode detection logic in NINA’s native driver) it actually has no effect on the operation of the camera when it’s driven in single exposure mode.

I will adjust the driver to have an exception for this specific model when it comes to the CONTROL_SPEED parameter in the SDK. It will be ignored and then allow the readout modes to be used instead. Would you be willing to test this out for me seeing as how you’re the only person I’m aware of who has a 42 Pro?

[Dale Ghent]

Here’s an installer based on 1.11 build 135 that includes the proposed fix for this. Give it a try and let me know how it goes

https://daleghent.com/misc/nina/testing/qhy42pro/NINASetupBundle.exe

[Frank Zoltowski]

Dale,

Tried the your build and still the same behavior. For info the driver for my camera are stated as

USB driver version 21.8.13.1

SDK 21-8-14-15

Firmware 21-7-14

FPGA version 1:19-1-16-128

‌

I did notice that Sharpcap version 4 fixed the problem. In earlier versions it was showing the same problem as NINA now shows. Maybe Robin can tell you how he managed to get it to work.

[Dale Ghent]

Hmm. Could you provide a log file from this attempt?

[Frank Zoltowski]

  <div class="preview-container wiki-content"><!-- loaded via ajax --></div>
  <div class="mask"></div>
</div>

</div> </form>

[Frank Zoltowski]

latest log attached

[Dale Ghent]

Ok, the work-around seems to be doing its thing:

2021-08-31T19:14:30.5450|DEBUG|QHYCamera.cs|ConnectSync|762|QHYCCD: Camera has 2 readout mode(s)
2021-08-31T19:14:30.5488|DEBUG|QHYCamera.cs|ConnectSync|770|QHYCCD: Found readout mode "HDR MODE"
2021-08-31T19:14:30.5488|DEBUG|QHYCamera.cs|ConnectSync|770|QHYCCD: Found readout mode "STD MODE"
2021-08-31T19:14:30.5488|DEBUG|QHYCamera.cs|ConnectSync|780|QHYCCD: Readout mode names: HDR MODE, STD MODE

Are you saying that the Readout Mode drop-down boxes (or, combo boxes if you will) on the Equipment > Camera screen do not have “HDR MODE” and “STD MODE” in them?

I did notice this in your log:

2021-08-31T19:15:23.9945|ERROR|BaseImageData.cs|PrepareSave|91
System.IO.DirectoryNotFoundException: Could not find a part of the path 'W:\QHY42'.

It seems that W:\QHY42 is set to be the base image save path but it doesn’t exist. Refer to the setting under Options → Imaging → Image file path

‌

[Frank Zoltowski]

Dale,

The camera screen has the readout modes and the drop-down shows HDR MODE and STD MODE. Tried both and still get HDR mode.

For some reason the NAS drive did not connect to the scope’s pc. Fixed it.

[Dale Ghent]

Ok, I took another stab at this. I put a new installer up at the same URL:

https://daleghent.com/misc/nina/testing/qhy42pro/NINASetupBundle.exe

Since this has the same version of what you installed earlier, you might need to first uninstall NINA before installing this new one. Your profiles and settings won’t be touched. If it doesn’t work out, please provide the log file and I’ll talk to QHY and Robin to see if I can get some clarity. These cameras seem to take a different programmatic path when it comes to setting the different resolution found in the two modes.

[Frank Zoltowski]

Dale,

Good and bad news. The good news is that I can get a 2048x2048 frame when STD is selected. The bad new is that it is the top half of the low gain channel. Every other line on the frame is black. When I select HDR for the output, I get a normal two image HDR frame as before.

[Dale Ghent]

Ok, a log file would help there. I’m unaware of any special considerations for downloading the frame from this camera model, but I’ll check to be sure. It’s good to see that the mode selection appears to be working despite the result, though. Just to confirm, STD mode downloads from the ASCOM driver are fine?

[Frank Zoltowski]

Dale,

‌

Looking at a saved frame in PI, every other line seems to be set at the sensor offset value, not zero and noise seems to be carried over into the other line at a lesser value. So it looks like I’m getting some of the low gain and some of the high gain frame in the output. So it reads the entire low gain/high gain line, but only 1024 of them. As the fits file says it is a 2048x2048, I get this pattern when displayed.

‌

One option, a bit messy just for this camera is if STD is selected, download the HDR frame and strip out the STD section (left half). Only use this section for processing (AF, Plate solving, HDR, etc.) and saving/display.

[Dale Ghent]

I just took a stroll through the SDK’s header file and found this function:

EXPORTC uint32_t STDCALL SetQHYCCDTwoChannelCombineParameter(qhyccd_handle *handle, double x,double ah,double bh,double al,double bl);
/**
  @fn uint32_t SetQHYCCDTwoChannelCombineParameter(qhyccd_handle *handle, double x,double ah,double bh,double al,double bl);
  @brief For the camera with high gain low gain two channel combine to 16bit function, this API can set the combination parameters
  @param handle camera control handle
  @param x:  High gain low gain channel data switch point. (based on the high gain channel data)
  @param ah: High gain channel ratio   (y=ax+b)
  @param bh: High gain channel offset  (y=ax+b)
  @param al: Low gain channel ratio    (y=ax+b)
  @param bl: Low gain channel offset   (y=ax+b)
  @return QHYCCD_SUCCESS or QHYCCD_ERROR. If it is QHYCCD_ERROR, it means (1) this model may have not support this function or (2) the API failur to run.
*/

While it doesn’t mention anything about the QHY42 Pro specifically, it does seem related to how its output is configured and could be a clue here. I’ve sent a message to Dr. Q asking about this issue you are seeing in STD mode and if there is any special handling that is required, perhaps in conjunction with this function.

This certainly is a unique sensor and this is my first exposure to it, so thank you for bearing with me in seeing how best to handle it.

[Frank Zoltowski]

  <div class="preview-container wiki-content"><!-- loaded via ajax --></div>
  <div class="mask"></div>
</div>

</div> </form>

[Frank Zoltowski]

Dale,

‌

attached is the latest log file. With the ASCOM driver, I can switch back and forth between the HDR and STD modes and get a proper STD image, although I don’t know whether it is the high or low gain side that is used for the STD image as with Sharpcap, I have to up the gain and offset a bit to get an image looking like an STD frame through ASCOM.

‌

The earlier QHY42 cameras only had one output option (I think HDR), but mine is a lter release that allow switching between the two.

[Dale Ghent]

The odd thing is that the ASCOM driver isn’t doing anything particularly special, from what I can discern, when it comes to this camera or the frames from it (one can decompile the driver DLL and look at what it does that way.) Three things are on my mind right now:

1. We need to do something to set up the frame (re: the SetQHYCCDTwoChannelCombineParameter() mentioned above)
2. We are running into a difference in frame download behavior between Single Exposure mode (what we run the cameras in) and Stream mode (what SharpCap runs the camera in). However the ASCOM driver runs the camera in Single Exposure mode, so this might not be the case.
3. A possible SDK issue. SharpCap, the ASCOM driver, and NINA each ship their own copies of the SDK, the versions of which can vary. In NINA’s native driver, the version of the SDK that’s in use is visible in the Equipment → Camera screen once you’ve connected. Would you mind echoing that version that your installed ASCOM driver uses here? The ASCOM driver should display the SDK version it uses in its setup window.

I’ll see what Dr. Q says in response to my query and continue to go over what documentation I can find on this. Thanks again for bearing with me on this and I hope we can resolve this soon.

‌

[Frank Zoltowski]

For the direct connect, I mentioned the drivers above.

‌

For ASCOM, it uses:

‌

Firmware 21-7-14

SDK 21.8.14.15

ASCOM 21.8.14.19

‌

the same as above

‌

ASCOM works with both STD and HDR options. I need to look at the file closer in PI, but it seems the STD version is the high gain channel of the HDR frame.

[Frank Zoltowski]

Looked at the frames from ASCOM in PI. ASCOM is pulling the high gain channel for the STD frame. In Sharpcap, it is the low gain channel.

[Dale Ghent]

Ah, more ambiguity. Thanks for this info. I’ll mention this to Dr. Q. Hopefully he can outline the proper/intended way to operate the camera.

[Frank Zoltowski]

Hi Dale,

‌

First, thank you for your effort, especially since I maybe be the only one using this camera with NINA (add to that a Meade MaxMount and that may make a quite unique setup).

‌

If you can’t get a way to get the STD mode through the driver, I have one idea, but since I don’t know how NINA works with the raw data it may be more trouble than its worth,

For the readout option, have three options available: HDR, STD-Low Gain and STD-High Gain. The STD options would split off the appropriate frame (low columns 0 to 2047 or high columns 2048 to 4095). Use that subframe as usual for plate solving, HDR, focus, display, etc. and saving and discard the other half.

‌

Just an idea.

‌

[Dale Ghent]

Good evening, Frank

Could look at doing frame surgery like that, but I’d first prefer to understand the expected operating mode of the camera before going down that route.

Dr Q asked if you could provide example frames for both modes. One good example of each mode should do. You should be able to put them in a zip file and attach it here. He mentioned that if it is even and odd rows, that is normal for the sensor and the effect can be calibrated out. He can know for sure if he sees an example frame.

I wonder if the two modes operate under different gain scales?

[Frank Zoltowski]

Dale,

I attached a set of fits files, one of the STD readout and the other of the HDR readout, both from your new build you sent me. I got an error on the upload, but I downloaded it and it looks fine.

It should be obvious that the STD readout is the top 1024 lines of the HDR image with the fit size keywords changed to 2048x2048. PI won’t let me change those to confirm, and I don’t have an available fits editor to try. You can see this by noting the position of the amp glow and the top cluster defect. in the images.

I could write a python script to monitor the image directory and slice and dice an HDR frame into two low and high gain images, but that still would not solve NINA issues with the HDR frame such as plate solving (hope to not need by creating a TPoint model) and while focus may work, don’t know it the results would be as good with just a low or high gain frame and I don’t think the focus window option allows an offset to one side or the other.

[Dale Ghent]

Thanks for providing this, Frank.

I see what you mean now, with the alternating rows. I cropped out the left side of the HDR frame and applied a stretch to just that area and, while the rows are notable, the difference isn’t as stark as it is in the pure STD mode image. I forwarded the zip file on to Dr Q so that he can take a look.

I did take a look at the ASCOM driver again and it’s not doing anything different than we are regarding this. We are currently shipping an SDK from July in NINA 1.11, whereas the ASCOM driver you’re using is leaning on the SDK release from August. This is the only meaningful difference that I can identify. While it’s unlikely that there’s a difference between the two versions when it comes to the QHY42 specifically, it can’t be ignored as a possibility.

If you’d like, you can copy the August x64 SDK DLL over the July one that is installed and used by NINA. My plans are to update 1.11 to the next SDK release once QHY finalizes their new undervoltage lockout protection logic. Here are some quick instructions for doing this:

Quit NINA, then copy C:\Program Files\QHYCCD\AllInOne\sdk\x64\qhyccd.dll and overwrite the one that NINA delivers in its installation area with it, which is located at C:\Program Files\N.I.N.A. - Nighttime Imaging 'N' Astronomy\External\x64\QHYCCD\qhyccd.dll

You should see the newer version shown in the SDK Version field of the Equipment → Camera screen once you’ve connected to the camera.

By the way, I noticed in the log output that the QHY42 Pro has the sensor chamber humidity sensor. Is the readout for this sensor working as expected?

‌

[Frank Zoltowski]

Thanks Dale,

If you notice on the STD image, you will get a low gain row and the row below it will be the high(er) gain row, The hot pixels match up nicely.

The humidity sensor reads 0.00% which is what you would want. But, never trust a value read at the edge of its limits, so I don’t really know if it is working as planned.

Since you have Dr Qiu’s ear, you may bug him about their ASCOM driver stating the camera as a color RGGB camera. I have not heard back from QHYCCD when I wrote to them about it.

Thank you for your effort. Hopefully it will get resolved.

Thanks,

Frank Z…

[Frank Zoltowski]

Hi Dale,

‌

Another thing I noticed with the build you sent me. Autofocus just does not work. It cannot get good HFRs. Same setting as per previous builds, but the HFRs just hang between 1 and 2 even though the image is degrading. Previously, I would get good curves. It seems to be OK with my other setup using my QHY600. Could this have something to do with the ASCOM setting showing it as a color camera? If so, is it possible to set an option to not debayer? I did not see this behavior under HF1.10.

‌

Thanks,

Frank Z…

[Frank Zoltowski]

Hi Dale,

‌

First apologies. I managed to find the setting to turn off the debayering. I was looking for it on the camera page,,,found it under options. I have never used an OSC camera with NINA, so never bothered to look. Weather is iffy for the next few nights so I can’t test it in anger for a while though. This should correct that issue until QHYCCD fixes the ASCOM driver.

‌

An interesting issue with the build you made for me. It goes back to when you noticed that my path did not exist for saving the file. For some reason your build does not recognize mapped network drives. I can connect if I specify the full network path i.e. \\TEBBUT….\, but not mapped as drive “w:” On another pc on another scope running the daily build 135, this is not a problem.

‌

I’m trying to figure out just what gain is actually used in the ASCOM STD mode. But during some testing this morning, the GPU on my workhorse pc gave out. BY the time I swapped it out with a low end spare card, it was too warm in my observatory to cool the camera to my working level. So I will test it tonight. Let you know what I find.

‌

If you can get the STD/HDR issue corrected with the direct dirver, let me know. I’ll be happy to test it.

‌

Thanks,

Frank Z…

‌

‌

[Dale Ghent]

Hi Frank, I’m back from a holiday weekend.

I talked with Dr. Q about this and it may be an initialization issue. He said that the pattern of alternating lines is normal, but the gain difference between the lines is out of the ordinary and suggested that I do some extra steps. Can you try this installer and let me know?

https://daleghent.com/misc/nina/testing/qhy42pro/NINASetupBundle.exe

[Dale Ghent]

One additional thing Dr. Q suggested is to make some exposures in EZCAP and see if the same results are had there. I believe he advised this because EZCAP runs the camera in the same mode, so results ought to be similar in theory.

[Frank Zoltowski]

Dale,

‌

That looks like it did the trick. I can switch from STD to HDR and the output shows it. I have to look at the data in more detail (later after work or the weekend), but so far it looks good. I’ll have to run a new set of cal collections. I’ll use ASCOM until I get a cloudy night for that as I can’t cool the camera enough during the day. Now bug Dr Qiu about the ASCOM OSC bug. My e-mails seem to go into a black hole. I probably won’t worry about it after I get a chance to check these frames. To fix the issue with other software I use, I wrote a python script to strip out the offending OSC keywords from all the files image files in a directory. Seems to work.

‌

I’ll let you know how this goes. Thanks for all your work.

‌

Thanks,

Frank Z…

‌

‌

[Dale Ghent]

Hi Frank, It’s great to hear that this looks promising. Let me know how it looks once you’re able to bang on it some more. I have a bunch of other QHY driver updates in the queue as well but I don’t think these are relevant the 42 Pro (related to undervoltage lockout protection).

[Frank Zoltowski]

Hi Dale,

‌

I ran a few nights with the direct driver for the QHY42Pro and all looks good. No issues, except every now and then you would get a short hangup and a garbled frame. Maybe 1 in a 100 or so. After the hiccup, it continues as if nothing happened, so really not a problem. My calibration frames I took with the same gain/offset settings that I used with ASCOM, also work, but I’ll take a new set when conditions permit. So, I quess we can call this one closed.

‌

Thanks,

Frank Z…

‌

[Stefan B]

fixed for nightly 1.11. 144