Here we have two fit files, one taken by SGP 2.5.1.14 and one taken by EZCap-QT v0.1.3.0:
Same exposure, same gain, same filter, same target. Maybe 20 min apart.
You can clearly see the target (M97) and stars in the EZCAP fit, but not in the SGP.
It feels like there is something wrong with the QHYCCD ASCOM dirver as to gain on the minicam? Something is clearly off.
This is (one reason) why I can’t use SGP with this camera. nothing will plate solve, etc. Using the either EZCap or EZplanitary, with everything else being equal, I can take images and plate solve them in AstroTortilla.
In SGP I’m using local astrometry.net with the same data files as AT, and when given a “good” image it does solve, but I can’t get good images in SGP with this camera.
You should probably post this over at the QHY forum as they control their ASCOM driver. SGP is just a consumer of the driver.
Also (if I remember correctly) you need to set the Gain and Offset in the ASCOM properties for the driver. Did you happen to use the same values in both tests?
I cut and pasted the post into the QHY forum right after I posted on SGP.
They’re not using ASCOM, but yes, in the ASCOM properties I checked to be sure that the GAIN was set to 4 (you can see in the fit header for their file that the gain was set to 4).
Is there anything in SGP that resets the gain (like you can select different binning) that would override the ASCOM properties?
I cut and pasted the post into the QHY forum right after I posted on SGP.
They’re not using ASCOM, but yes, in the ASCOM properties I checked to be
sure that the GAIN was set to 4 (you can see in the fit header for their
file that the gain was set to 4).
Is there anything in SGP that resets the gain (like you can select
different binning) that would override the ASCOM properties?
No, we don’t allow changing of gain or offset through SGP other than the ASCOM properties dialog (which we have no actual control over other than to show it). For ASCOM devices SGP should be pretty “dumb” as far as the inner workings of the camera are concerned (kind of the point of ASCOM actually). SGP requests an image for X amount of seconds and after that time the camera delivers it. We can set somethings like the binning, subframe and such but for the most part the inner workings are not exposed to us.
Hopefully I will get some traction over on the QHY forum.
One additional thing I noticed in comparing the fits headers, their’s has EXPOSURE in ms, and SGP’s in in Seconds. From my research seconds is correct.
Is it possible that you are asking for a 120 second exposure and getting back a 120ms exposure? It does take 120 seconds on the progress bar in SGP, but I don’t know if you are waiting the 120 seconds to ask for or check the download or it you get the image as soon as the camera is done?
We do wait 120 second before we ask if the camera is done. So you are correct, the camera could only be exposing for 120ms without us knowing. The ASCOM camera contract specifies seconds though, so this should be handled in their driver.
I did that experiment, and I’m not sure what to conclude because while a 120ms exposure in EZCap did return “noise” the values in the fit file are actually higher than for a “good” 120 seconds exposure?
I did another experiment, however, that I believe does eliminate SGP as the source of any error. I did a 120 seconds exposure (same filter, max gain in ASCOM properties) using Nebulosity 4 demo with ASCOM camera selected, and the values in the resulting fit file are similar to the SGP result. Specifically similar mean and stddev values.
Values are from fits liberator. All values are for max gain and via the lum filter, same target.
EZCap 120ms:
Mean 13,462 stddev 342
EZCap 120 seconds:
Mean 11,417 stddev 1482 (a usable image)
SGP 120 seconds
Mean 3,345 stddev 166
Nebulosity 4 demo 120 seconds:
Mean 3,318 stddev 302