Ok, well, the functionality is present in SGPro and you can ask QHY if they are willing to implement those features in the ASCOM driver. I suspect it would be pretty simple to do.
Ken I just reached out to cha@qhyccd.com. I will relay any communications to this thread.
Thanks
Steve
Just for reference. These are the properties to implement:
- The readout mode: ICameraV3.ReadoutMode Property
- The descriptive names for readout mode: ICameraV3.ReadoutModes Property
Bump …
Just wondering if there has been any update/improvement on this situation?
In the FITs files from my QHY600M, the “READOUTM” value is always “fast” regardless of whether the camera was in “Photographic DSO” mode or “High Gain” mode. So I guess this value is different than the QHY ASCOM driver “ReadMode”.
As was mentioned by someone in a different thread, it sure would be nice if the QHY “ReadMode” could be changed by SGP through the ASCOM driver. Or at the very least, capture the value for storing in the FITS header/filename as discussed earlier in this thread.
If I understand things correctly, ASCOM has a way to handle this, but QHY has not implemented in their ASCOM driver yet?
DaveNL
I do not know the if QHY has implemented this or not. That value in the FITS header is indeed what the camera is reporting though so the outlook seems bleak here. In any case, after Chain Solver is released (should be a much shorter beta), I have a list od smaller items to get through before we move to Polar Alignment
Hi @Ken,
I just got this response from QHY:
QHY600 - Read Mode (Photographic, High Gain etc) and ASCOM
Hi,
Just wondering if the Read Mode (PhotoGraphic, Extended Full Well etc) for the QHY600 is a variable available to the ASCOM driver?In other words, is it possible for this value to get written to a FITS file header? Or better yet, could be set by an image capture program through the ASCOM driver?
Thanks,
=============
Hello，Unfortunately, the read mode of QHY600 cannot be written into the FITS header file. And it can only be set before connecting the camera, and cannot be set in the software after connecting the camera.
So, a bummer. I can possibly understand not being able to change the ReadMode after the camera is connected. But I am surprised that QHY cannot provide the ReadMode value through to the ASCOM driver ?!
Dave
Yes, it seems like this should certainly be possible in that, upon connect, the driver records the current mode and just provides that value to any clients who may ask for it in the future. That said, I try to avoid making assumptions about things like this… there may be details I don’t understand.
Ken I determined what the ASCOM.QHYCCD driver property is that contains this parameter. It is… CurrentReadMode
I cycled thru all the four possible READMODE(s) and captured the values as they changed and captured the properties with the ASCOM Diagnostics Tool. The values directly correspond with the dropdown listbox indexes. If you can Update SGP to reflect this parameter (just the number) you will make a lot of people happy. This camera is being used by many professional AAVSO observatories also. I am working with Dennis Conti to test this camera and we have no way of knowing what connection method was used after the fact. I am retired and can be available to Beta test a change. I am available for session ZOOM or other connection sharing if you want.
QHY600M-ce9b85469ade18e9aCurrentReadMode 0
QHY600M-ce9b85469ade18e9aCurrentReadMode 1
QHY600M-ce9b85469ade18e9aCurrentReadMode 2
QHY600M-ce9b85469ade18e9aCurrentReadMode 3
Steven Hoffman
stevenhoffman53 (at) hotmail.com
Dennis Conti the chair of the AAVSO Exoplanet section reaffirmed his desire that READMODE be in the FITS header. These are his words…
"One key reason it should be in the FITS header is that as part of the ExoFOP upload, we upload a FITS file of a sample (plate solved) image. That way, a researcher can look in the FITS header to see what other conditions were used to do the observation. So, yes, having READMODE in the FITS header would be good for that reason.
The designers of Sequence Generator Pro are usually at NEAIC/NEAF, so if you are going there that would be another opportunity to ping them."
SGPro has written readout mode to FITS headers for quite some time now. It is currently writing to READOUTM. If you are not seeing it in your images, it would be helpful to locate, in logs, the area around a statement reading:
ASCOM Camera Readout mode query...
I have absolutely no issue also adding this value to READMODE
This is a dump of the properties of the ASCOM driver named ASCOM.QHYCCD.
I “bolded” the field “CurrentReadMode” this is the value we need, I have confirmed it.
I do not know what you see on your end and I have never done any ASCOM development, so I’m in the dark.
Steve Hoffman
<Default> QHYCCD-Cameras2-Capture
LastCamId QHY600M-ce9b85469ade18e9a
max_position 29
QHY600M-
QHY600M- CameraID QHY600M-
QHY600M- CameraXSize 9576
QHY600M- CameraYSize 6388
QHY600M- CanAbortExposure True
QHY600M- CanAsymmetricBin False
QHY600M- CanDDRBufferCapacity False
QHY600M- CanGetCoolerPower True
QHY600M- CanPulseGuide False
QHY600M- CanRemoveRowNoise False
QHY600M- CanSetBin11 True
QHY600M- CanSetBin22 True
QHY600M- CanSetBin33 True
QHY600M- CanSetBin44 True
QHY600M- CanSetCCDTemperature True
QHY600M- CanSetCFW True
QHY600M- CanSetGain True
QHY600M- CanSetOffset True
QHY600M- CanSetQHY5IIGuidePortOnOff False
QHY600M- CanSetSpeed False
QHY600M- CanSetTransferBits True
QHY600M- CanSetUSBTraffic True
QHY600M- CanStopExposure True
QHY600M- CurrentReadMode 1
QHY600M- ElectronsPerADU 1
QHY600M- FullWellCapacity 65535
QHY600M- Gain 60
QHY600M- HasCooler True
QHY600M- HasShutter False
QHY600M- MaxADU 255
QHY600M- MaxBinX 4
QHY600M- MaxBinY 4
QHY600M- MaxExposure 3600
QHY600M- MaxGain 200
QHY600M- MaxOffset 255
QHY600M- MaxUSBTraffic 60
QHY600M- MinExposure 1E-06
QHY600M- MinGain 0
QHY600M- MinOffset 0
QHY600M- MinUSBTraffic 0
QHY600M- Offset 76
QHY600M- PixelSizeX 3.76
QHY600M- PixelSizeY 3.76
QHY600M- PresetGains 60,60,0,0,0,0,0,0,0,0
QHY600M- PresetIndex 0
QHY600M- PresetKeywords DSO,Planetary,-Undefined-,-Undefined-,-Undefined-,-Undefined-,-Undefined-,-Undefined-,-Undefined-,-Undefined-
QHY600M- PresetOffsets 76,0,0,0,0,0,0,0,0,0
QHY600M- RemoveOverscan True
QHY600M- SetCCDTemperature -5.20002457593333
QHY600M- StepExposure 1E-06
QHY600M- StepGain 1
QHY600M- StepOffset 1
QHY600M- StepUSBTraffic 1
QHY600M- TransferBits 16
QHY600M- USBTraffic 50
QHY600M-ce9b85469ade18e9a
QHY600M-ce9b85469ade18e9aCameraID QHY600M-ce9b85469ade18e9a
QHY600M-ce9b85469ade18e9aCameraXSize 9576
QHY600M-ce9b85469ade18e9aCameraYSize 6388
QHY600M-ce9b85469ade18e9aCanAbortExposure True
QHY600M-ce9b85469ade18e9aCanAsymmetricBin False
QHY600M-ce9b85469ade18e9aCanDDRBufferCapacity False
QHY600M-ce9b85469ade18e9aCanGetCoolerPower True
QHY600M-ce9b85469ade18e9aCanPulseGuide False
QHY600M-ce9b85469ade18e9aCanRemoveRowNoise False
QHY600M-ce9b85469ade18e9aCanSetBin11 True
QHY600M-ce9b85469ade18e9aCanSetBin22 True
QHY600M-ce9b85469ade18e9aCanSetBin33 True
QHY600M-ce9b85469ade18e9aCanSetBin44 True
QHY600M-ce9b85469ade18e9aCanSetCCDTemperature True
QHY600M-ce9b85469ade18e9aCanSetCFW True
QHY600M-ce9b85469ade18e9aCanSetGain True
QHY600M-ce9b85469ade18e9aCanSetOffset True
QHY600M-ce9b85469ade18e9aCanSetQHY5IIGuidePortOnOff False
QHY600M-ce9b85469ade18e9aCanSetSpeed False
QHY600M-ce9b85469ade18e9aCanSetTransferBits True
QHY600M-ce9b85469ade18e9aCanSetUSBTraffic True
QHY600M-ce9b85469ade18e9aCanStopExposure True
QHY600M-ce9b85469ade18e9aCurrentReadMode 3
QHY600M-ce9b85469ade18e9aElectronsPerADU 1
QHY600M-ce9b85469ade18e9aFullWellCapacity 65535
QHY600M-ce9b85469ade18e9aGain 0
QHY600M-ce9b85469ade18e9aHasCooler True
QHY600M-ce9b85469ade18e9aHasShutter False
QHY600M-ce9b85469ade18e9aMaxADU 255
QHY600M-ce9b85469ade18e9aMaxBinX 4
QHY600M-ce9b85469ade18e9aMaxBinY 4
QHY600M-ce9b85469ade18e9aMaxExposure 3600
QHY600M-ce9b85469ade18e9aMaxGain 200
QHY600M-ce9b85469ade18e9aMaxOffset 255
QHY600M-ce9b85469ade18e9aMaxUSBTraffic 60
QHY600M-ce9b85469ade18e9aMinExposure 1E-06
QHY600M-ce9b85469ade18e9aMinGain 0
QHY600M-ce9b85469ade18e9aMinOffset 0
QHY600M-ce9b85469ade18e9aMinUSBTraffic 0
QHY600M-ce9b85469ade18e9aOffset 5
QHY600M-ce9b85469ade18e9aPixelSizeX 3.76
QHY600M-ce9b85469ade18e9aPixelSizeY 3.76
QHY600M-ce9b85469ade18e9aPresetGains 0,60,0,0,0,0,0,0,0,0
QHY600M-ce9b85469ade18e9aPresetIndex 0
QHY600M-ce9b85469ade18e9aPresetKeywords DSO,Planetary,-Undefined-,-Undefined-,-Undefined-,-Undefined-,-Undefined-,-Undefined-,-Undefined-,-Undefined-
QHY600M-ce9b85469ade18e9aPresetOffsets 5,0,0,0,0,0,0,0,0,0
QHY600M-ce9b85469ade18e9aRemoveOverscan True
QHY600M-ce9b85469ade18e9aSetCCDTemperature -10
QHY600M-ce9b85469ade18e9aStepExposure 1E-06
QHY600M-ce9b85469ade18e9aStepGain 1
QHY600M-ce9b85469ade18e9aStepOffset 1
QHY600M-ce9b85469ade18e9aStepUSBTraffic 1
QHY600M-ce9b85469ade18e9aTransferBits 16
QHY600M-ce9b85469ade18e9aUSBTraffic 50
strong text
Were you able to find the requested segment of the SGPro logs (or just send the whole thing over)?
I have never requested SGPro Logs. I will send them over just as soon as possible.
I just meant in my last post, I said:
Looking at the logs will tell us what info SGPro has access to (as provided by the driver).
Futher guidance for sending us logs is here: SGPro - Help
I would suggest to put the INTEGER into the FITS field READOUTM.
Do Not interpret it as FAST or NORMAL.
Logs to follow in next post.
Steve
Log text follows…
[RECEIVED… read and removed for readability]
I’m not sure what option we have here. SGPro simply does not know about those choices you point to in your screenshot. To the best of my knowledge, SGPro is doing this by the book and QHY is not populating the “modes” list correctly (which if I remember correctly is the subject of this thread).
ICameraV3.ReadoutModes Property (ascom-standards.org)
Here are the modes that your camera reports to SGPro
[DEBUG][Main Thread][NONE] ASCOM Camera: Readout Mode 0=> "Fast"
[DEBUG][Main Thread][NONE] ASCOM Camera: Readout Mode 1=> "Normal"
These are not default interpretations… they are pulled directly from the driver.
You are saying that the words FAST and Normal are return values of your query?
I find this hard to believe. Here’s a screenshot from the QHY website.
Maybe? Unless you can tell me exactly where in the ASCOM driver these readout modes you refer to are stored, I’m afraid I can’t help. QHY, however, can absolutely help here by populating the modes you refer to above in the driver’s interface. The logs I posted are 100% accurate for your camera’s ReadModes property.
I think the confusion here is this:
QHY cameras do indeed offer the modes you say, but they ONLY provide access to said modes via the driver’s settings dialog (which you posted above). They do NOT provide access to readout modes to apps like SGPro via ASCOM. It is one of the reasons we have considered restoring access to QHY’s native drivers.