Weird problem with Force Still mode and QHY168C

[Fishie]

Hi, first time posting stuff here.

For every first frame after I change the exposure time, it took 2x the time to capture the frame. It sometimes even shows nothing with more than 3x the time, and I had to restart SharpCap to make it work again.

I was told that the Force Still Mode would solve the problem, but once I swapped the mode, the settings are messed up and the resulting image appeared red and weird.

Autosave003.jpg (817.66 KiB) Viewed 2078 times

The Camera Settings file shows the RGB gains are 510, 30 and 40 respectively, but originally they were set to be 7.

Capture_00001.CameraSettings.txt

(761 Bytes) Downloaded 42 times

There seem to be no use sliding the gains down, the image still appears red.

Any idea how I could solve this? Many thanks!

[admin]

Hi,

well, the very high red gain would explain the colour of the picture, but I don't know why it jumps to such a high value. Ok, I do have a suspicion, which is that SharpCap re-reads the gain values from the QHY SDK after switching to 'force still mode' and that the SDK is giving the weird value. Can't be sure though...

Next question is why does reducing it not work - I presume that you waited for a new exposure to finish (300s by the look of things), as I would not expec the change of these values to make any difference until at least the first exposure to finish after the change (possibly not even until the first exposure started after the change). It may be worth trying some experiments with a bit of white paper over the telescope during daylight - you can then test with very much shorter exposures to see what happens when switching to 'force still mode' and whether the changes you make to the red gain do actually take effect.

cheers,

Robin

[Fishie]

I tried again, the red doesn't go away after lowering the red gain in Force Still Mode.

This is right after I swapped to Force Still Mode and the red gain shows 510, the other two are 30:

SharpCap Red 510.png (913.7 KiB) Viewed 2064 times

This is many frames after I lowered the gains:

SharpCap Red.png (821.93 KiB) Viewed 2064 times

Many thanks!

Best,
Fishie

[admin]

Hi,

I can see from your screenshots that you are using a slightly out-of-date version of SharpCap. In particular, there has been an update to the QHY SDK since the version that you are using that may just be relevant to this issue (worth a try, anyway).

Please download and install the latest SharpCap from https://downloads.sharpcap.co.uk and see if that helps.

thanks,

Robin

[Fishie]

Hi,

I installed the latest updates both from the QHY drivers and SharpCap - it didn't solve the problem:

SC red.png (788.38 KiB) Viewed 2040 times

Many thanks!

Best,
Fishie

[admin]

Hi,

that's a shame - can you just check if it makes any difference if you put the camera into RAW16 mode instead of RAW8 - still mode is really aimed at longer exposures and hence 16 bit.

I have checked the code and the handling for the red channel is identical to the green and blue channels, so I think this may come down to an SDK bug, although I would need to see an extended log to be sure (https://docs.sharpcap.co.uk/4.0/#Logging%20Tab, turn on logging for camera hardware communication before opening the camera, adjust the settings to be equal and then close camera and grab log).

cheers,

Robin

[Fishie]

16-bit mode didn't solve the problem...

SharpCap 16bit Force Still.png (998.34 KiB) Viewed 2015 times

And here's the log file:

Log_2022-07-22T16_38_26-11176.log

(953.26 KiB) Downloaded 39 times

Many thanks!

Best,
Fishie

[admin]

Hi,

thanks for the log and for testing again. I can see from the log that all the commands to set the gain that SharpCap sends to the camera seem to be fine, as are most of the commands to read it back, but then suddenly reading back the value gives an answer of 255 (not 0..15). This is obviously being doubled and turned into the 510 you are seeing on the display (I can't spot where in the code the doubling is coming from though - that is annoying)...

Anyway, it seems very much likely to be a bug in the QHY SDK causing the gain value to become invalid at some point and then not responding to requests to set it back to a sensible value.

There is an experimental version of the QHY SDK available at this location : https://www.qhyccd.com/file/repository/ ... .07.06.zip - this is newer than the version in SharpCap. If you want you could try to download this and copy the qhyccd.dll file over the one that SharpCap installs to see if that helps - just make sure to use the qhyccd.dll from the x64 folder if you have 64 bit SharpCap (and the one from the x86 folder if you have 32 bit SharpCap). Also, if you haven't already, make sure that your QHY drivers are right up-to-date.

cheers,

Robin