Sensor Analyse incoherent with QHY290

soulearth
Posts: 44
Joined: Sat Jul 18, 2020 2:17 pm

Sensor Analyse incoherent with QHY290

#1

Post by soulearth »

Hi,

I just bought a cooled QHY290M and I notice that the sensor analysis is inconsistent.
Here is my sensor analysis ( last version of sharpcap and QHY drivers ):
290M_g.png
290M_g.png (88.39 KiB) Viewed 2296 times
Here is one QHY290M from a friend :
290M_n.png
290M_n.png (291.65 KiB) Viewed 2296 times
Here is one from a friend who has a QHY290 Color:
290C.jpg
290C.jpg (83.8 KiB) Viewed 2296 times
The read noise is at 20 at unity gain... In addition the number of stops is at 9 at gain 0 while it is a 12-bit camera.
If this were really the case, the camera would be unusable.

Besides, I wonder if this problem does not disturb the smart histogram.
histo.png
histo.png (641.77 KiB) Viewed 2296 times
Can you help me ?
Best regards,
User avatar
admin
Site Admin
Posts: 13330
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sensor Analyse incoherent with QHY290

#2

Post by admin »

Hi,

Something is not right in those analysis results - the read noise values should be *much* lower for all gains, but particularly for low gain values. At minimum gain, the read noise should be about 3.25e, not about 25-30e!!! (For instance see the figures for the ZWO equivalent : https://astronomy-imaging-camera.com/product/asi290mm)

So, what could be causing this?

Light leak - unlikely as it is consistent over 3 cameras
Odd camera settings disturbing the analysis - again unlikely unless they are the default
Some sort of bug in the camera SDK - possible, but hard to identify.

Can you post a capture settings file that shows all the camera settings used when you did the analysis? I can then take a look and see if any of the settings look like they might be causing a problem.

thanks,

Robin
soulearth
Posts: 44
Joined: Sat Jul 18, 2020 2:17 pm

Re: Sensor Analyse incoherent with QHY290

#3

Post by soulearth »

Hello Robin,
I agree. The gain should be much lower. But also the number of stops is not logical with a 12bits camera ( 9 stops max instead of 12 ! ).
Below is the information file of a capture:

[QHY290M]
FrameType=Light
Output Format=FITS files (*.fits)(Auto)
Binning=1x1
Capture Area=1920x1080
Colour Space=MONO16
Pan=0
Tilt=0
Force Still Mode=Off
Enable Live Broadcast=Off
Use DDR Buffer=On
USB Traffic=40
Offset=74
Amp Noise Reduction=On(Auto)
Frame Rate Limit=Maximum
Gain=198
Exposure=10,000s
Timestamp Frames=Off
Contrast=0
Brightness=0
Gamma=1
Temperature=-10
Target Temperature=-10
Cooler Power=37(Auto)
Trail Width=3
Minimum Trail Length=100
Trail Detection Sensitivity=9
Remove Satellite Trails=Off
Background Subtraction=Off
Planet/Disk Stabilization=Off
Banding Threshold=35
Banding Suppression=0
Apply Flat=None
Subtract Dark=None
Display Black Point=0,0974212034383956
Display MidTone Point=0,47134670487106
Display White Point=1
Notes=
ASCOM GS Sky Telescope=RA=12:05:36,Dec=+50:32:14 (J2000)
TimeStamp=2022-03-21T22:52:19.2162720Z
SharpCapVersion=4.0.8744.0

Thank you for your help and for the devellopement of sharpcap
Regards,
Soulearth
User avatar
admin
Site Admin
Posts: 13330
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sensor Analyse incoherent with QHY290

#4

Post by admin »

Hi,

the problem is that the excessive read noise is eating 3 or so stops of dynamic range. There is nothing unusual in your settings that I would expect to cause problems with analysis - the main possibilities would be gamma/brightness/contrast, but they are all at default.

Can you do a test for me please. Set the camera up in MONO16, minimum gain, offset=100, minimum exposure, dark and then show the histogram and note down the SD value shown on the histogram and post them here please.

I just tried this with a Player One 290 mono and get an SD value of about 16.5. If we divide that by 16 (because the histogram reads out in 16 bit, but the camera is really 12 bit) we get that the read standard deviation is about 1 ADU (12 bit ADU), which is about 3-4e, which ties in with expected values for that sensor. I am expecting you to get a higher SD if it is going to be consistent with the read noise values you have been seeing.

cheers,

Robin
soulearth
Posts: 44
Joined: Sat Jul 18, 2020 2:17 pm

Re: Sensor Analyse incoherent with QHY290

#5

Post by soulearth »

Yes.
2022-03-23_23h43_13.png
2022-03-23_23h43_13.png (146.17 KiB) Viewed 2243 times
SD=124
Dark is made with the cap in place

Regards,
Soulearth
User avatar
admin
Site Admin
Posts: 13330
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sensor Analyse incoherent with QHY290

#6

Post by admin »

Hi,

yes, that's rougly what I expected - your variation of brightness is about 8 times bigger than expected, which corresponds with the ridiculously high read noise.

Can you try experimenting with the controls we have not adjusted yet to see if they impact the SD reading? In particular you might try changing

Amp Noise Reduction
USB Traffic
Force Still Mode
Use DDR Buffer

as these controls may affect the camera itself.

thanks,

Robin
soulearth
Posts: 44
Joined: Sat Jul 18, 2020 2:17 pm

Re: Sensor Analyse incoherent with QHY290

#7

Post by soulearth »

Hello Robin,
First of all, thank you for your help.
I tried all the options one by one but nothing changed. However, while searching, I found something interesting.
2022-03-24_16h52_42.png
2022-03-24_16h52_42.png (158.28 KiB) Viewed 2213 times
Expo minimum 0.0010ms => SD 124 :(

2022-03-24_16h54_25.png
2022-03-24_16h54_25.png (159.49 KiB) Viewed 2213 times
Expo 0.0500ms => SD 124 :(

2022-03-24_16h54_43.png
2022-03-24_16h54_43.png (43.49 KiB) Viewed 2213 times
Expo 0.0600ms => SD 14.84 :D

All in Gain =0 and offset = 100.

Now with two dark ( 1 frames ) open with siril :
2022-03-24_17h23_19.png
2022-03-24_17h23_19.png (324.6 KiB) Viewed 2209 times
0.0500ms

2022-03-24_17h22_57.png
2022-03-24_17h22_57.png (270.56 KiB) Viewed 2207 times
0.0600ms

Effectively, the technical specifications indicate, minimum exposure time = 50µs.

Regards
User avatar
admin
Site Admin
Posts: 13330
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sensor Analyse incoherent with QHY290

#8

Post by admin »

Ah, right, that's good to know!

I've seen that sort of thing before, so the sensor analysis for QHY cameras does not use the minimum exposure that the camera claims to offer, instead it uses the minimum * 10, but it looks like it needs to be the minimum * 60 in this case!

Basically the QHY SDK is giving the wrong value when asked for the minimum exposure for this camera, SharpCap believes it and my previous workaround was insufficient.

I'm not sure whether the right approach is to pin the minimum exposure for all QHY cameras to 10us or above, or to pin the exposure used for read noise measurements to 0.1ms or above. The trouble is I don't know what other models have similar errors in the SDK, or even if any models genuinely go down to microsecond exposures :(

cheers,

Robin
soulearth
Posts: 44
Joined: Sat Jul 18, 2020 2:17 pm

Re: Sensor Analyse incoherent with QHY290

#9

Post by soulearth »

Yes. The minimum exposure time is too low. QHY drivers offer exposure times that are too short for this model.

To be precise, for my model, the minimum is : 0.0568ms
2022-03-24_19h38_59.png
2022-03-24_19h38_59.png (156 KiB) Viewed 2177 times
2022-03-24_19h39_23.png
2022-03-24_19h39_23.png (38.38 KiB) Viewed 2177 times

It is difficult to know the specifications of all the cameras but for exemple the minimum exposure time for QHY5III462C is 7us ( https://www.qhyccd.com/qhy5iii462c/ ). My 290 approximately 60us.

Regards,
User avatar
admin
Site Admin
Posts: 13330
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sensor Analyse incoherent with QHY290

#10

Post by admin »

Again interesting...

My PlayerOne 290 goes down to 10us without causing any issues - I suspect that the sensor is capable of that but that QHY have a bug with the sensor programming at low exposures :(

cheers,

Robin
Post Reply