Allow switching to 47M on QHY294M without having to use a Konami Code approach

[Kevin Jackson]

The QHY294M Pro allows switching between “2x2 Locked Mode” (11.7M @ 4.63um) and “Expanded 1x1 Unlocked Mode” (46.8M @ 2.315um).

Steps to Reproduce
Currently you can get to 47M if you do the astro equivalent of the Konami Code:

1. Ensure you have the latest drivers installed (All In One Beta 20.11.29.17) and tested on 1.10 HF2 Beta 006
2. Connect Camera using the native driver, not ASCOM
3. Ensure 11M mode is selected (changing between 47M and 11M has no effect on the information displayed), but ensure that Height is 4164px and Width is 2795px
4. Switch to the Image tab and take a snapshot - any length exposure.
5. Switch back the Equipment Camera tab
6. Select 47M mode
7. Switch back to the Image tab and take another snapshot - any length exposure. The result will still be an image set to 4164px x 2795px
8. Switch back to the Equipment Camera tab and disconnect the camera, ensuring 47M was still selected prior to disconnection.
9. Connect camera again - the result will be 47M with the driver correctly now reading Width 8336 and Height 5662
10. You can now image using 47M Mode

Expected Brehavior

When switching between modes, NINA should understand that the user expects the user to image in those modes

Actual Behaviour

Selecting 47M has no effect until you go through steps 1-10 above.

‌

[Dale Ghent]

I’m aware of the issues with the QHY294M. It is different from all past cameras where pixel size and image resolution was expected to stay the same between readout modes. Obviously this is a novel use of readout modes on QHY’s part so it is known that the code must be adjusted to accommodate the camera where it changes both resolution and stated pixel size when switching between different modes. After talking with QHY, we have agreed on some improvements to the QHY SDK that they will furnish in an upcoming update. These updates will enable us to have a driver that does not require specific logic for specific camera models in order to do the right thing in this regard.

In the mean time, I’m looking at a short-term solution but testing it is hard as I do not possess this camera. Would you be willing to assist in testing?

[Kevin Jackson]

Yes, more than happy to help.

[Sebastian G]

I have just received a QHY294M and could also help out in testing, if needed.

[Dale Ghent]

Hello, sorry for the delay, but I have a candidate fix which addresses supporting the QHY294M/C-Pro cameras. It is currently available for NINA 1.11 only but I will look into backporting it to 1.10 for inclusion in the upcoming 1.10 HF2 release.

IF you are already using 1.11, you can test the new native driver by installing the following:

https://daleghent.com/misc/nina/testing/qhy294/NINASetupBundle-11.exe

[Sebastian G]

Hi Dale,

I installed the version of NINA that you linked to and it does recognize the camera through its native driver, i.e. the camera is available in the drop-down.

I took one exposure with the 11 MP setting and one with 47 MP. The latter produced an image with 8336 x 5622 px.

Thanks!

‌

[Kevin Jackson]

I’ve just gotten around to testing this too. I get erratic results and can’t quite work out where the problem is.

My original workaround (on 1.10HF2) with QHYCCD SDK 20201128_21 gives this:

Uninstalling and using the patched version does now allow me to select between 11M and 47M as already stated, however my images are corrupt - see the different shading between the top 2/3rds and bottom.

Interestingly, uninstalling 1.11 version, and reverting to 1.10HF2 (as I need Sync guiding) this problem continued until I reinstalled the Beta QHYCCD driver then updated the SDK to 20201128 as before.

Also interesting are the two stretched views - the 1.11 version is darker. So I don’t know what the source of truth is with this camera and this mode as I’m unable to test the validity of the drivers and NINA consistently. I would be interested in seeing this change/fix for the QHY294M making its way to the 1.10HF2 Betas.

‌

[Kevin Jackson]

Small update to the above. In order to revert to the state where I’m able to use my QHY294M under 1.10HF2Beta7 is that I don’t have to reinstall the QHYCCD Beta drivers (I couldn’t work out why that was a factor) - but during the reinstall of the driver I remove power to the QHY294M. So it’s actually an action to remove power to my QHY294M after downgrading from 1.11 to 1.10 that fixed my 47M captures again. Obviously something is remaining to be set in the camera that is confusing it somehow that NINA or the driver isn’t resetting.

[Dale Ghent]

Please ensure that you’re running the latest firmware on your QHY294. For QHY cameras, firmware updates are delivered through the USB Driver package, and the package versioned 20.12.17 includes a firmware update that corrects the issue of 47M mode emitting 10bit data instead of 12.

https://www.qhyccd.com/index.php?m=content&c=index&a=show&catid=141&id=62&tdsourcetag=s_pctim_aiomsg

[Kevin Jackson]

I started getting these issues after I did that driver update. Order of events:

• Updated driver as per link you shared (only unplugging USB, power not touched)
• Removed 1.10HF2Beta007
• Installed 1.11 as per this thread
• Tested 11M and 47M, and noticed this issue reported
• Reverted back to 1.10HF2Beta007
• Replaced SDK in NINA with latest SDK version (only way to get camera recognised in Beta7)
• Tested 11M and 47M, continued to get the same error
• I reinstalled the QHYCCD Beta Driver (I unplugged + powered off my 294M)
• Tested 1.10HF2Beta007 again and it worked

I then realised it was the powering off the cam that fixed/reverted my issues.

What I am to test though is powering off my cam (remove power/power back on) after driver update, and repeating.

‌

[Kevin Jackson]

I can confirm - with the latest QHYCCD driver/firmware (20201222) - it breaks 1.10HF2 Beta 007 - with upscaling to 16-Bit turned on or off. Given that 1.11 doesn’t have PHD2 Sync Guiding available, I’m not going to test 1.11 as it doesn’t fit my use-case - but the behaviour was the same with the 1.11 too as reported earlier.

I tried QHYCCD’s EZ_CAP and I didn’t get the issue seen in NINA in 47M mode.

I tried in SharpCap 3.2.6457 and I didn’t get the issue seen in NINA in 47M mode.

It can’t be a driver issue directly, appearing isolated to how NINA is processing the information from the camera?

[Dale Ghent]

Kevin, I’m focussing on the code changes in the linked 1.11 installer. There have been no changes to the 1.10 native driver, so any discussion has to be around 1.11 at this moment.

[Kevin Jackson]

There’s the System Driver and there is the SDK. Which driver are you referring to with 1.10 and 1.11? I can copy any version of the SDK over to whichever version to test. However with the system driver (the link you posted) causes this strange dual tone effect of an image and fits file with 1.10 and 1.11, whereas reverting back to an older version of the system driver and using the latest SDK (the one included in your 1.11 NINA bundle) - and things work again (for 1.10HF2 Beta, at least).

This appears to be the test cases:

NINA 1.10HF2 Beta007 + System Driver/Firmware (included in the https://www.qhyccd.com/file/repository/publish/AllInOne/201126/QHYCCD_Win_AllInOne.20.11.29.17.exe) + SDK 20201128 = 47M Works with workaround in original post.

NINA 1.10HF2 Beta007 + Latest 22nd Dec 2020 Firmware (https://www.qhyccd.com/file/repository/latestSoftAndDirver/Driver/QHYCamerasDriver20201222.zip) + SDK 20201128 = 47M can change modes using workaround, but image has split tone

NINA 1.11 30 (bundle you provided) + Latest 22nd Dec 2020 Firmware (https://www.qhyccd.com/file/repository/latestSoftAndDirver/Driver/QHYCamerasDriver20201222.zip) + SDK 20201128 = 47M does change modes, but image has split tone.

‌