Several posts ago I told you I was accessing this information from the ASCOM driver already.
Yes, I forgot to ask about that. I did see it, but I didn’t understand. Can you provide additional detail? If we’re wrong, I absolutely don’t mind and we’ll correct.
This is a fairly concise list of everything SGPro can know about a camera:
ICameraV3 Interface (ascom-standards.org) and CurrentReadMode does not exist in that spec so I’m not even sure how to go about accessing that data (as seen in the dump).
What did you use to dump that data in the previous post?
I suspect “CurrentReadMode” is not in the ASCOM ICameraV3 Interface because it is limited to QHYCCD cameras. I submitted the ticket (attached) hopefully we will get a reply soon.
Again I can be a Beta tester for SGP if needed.
Steve
And again here is a screenshot of the ASCOM Utility dumping properties when connecting to my QHY600M camera.
It would be good to see the “Read Mode” added to the Fits header. Hope the above dialogue bears fruit.
However, things are not looking so good for enabling change of Read Mode via ASCOM driver. Some insights from Bob Denny, Dale Ghent (author of the NINA native QHY driver) and QHYCCD here:
https://ascomtalk.groups.io/g/Help/topic/104899316#47091
(requires account/subscription to the groups.io ASCOM forum)
Basically, QHYCCD says it would be “dangerous” to change read mode via ASCOM driver. Dale says that with his native driver - “To change the readout mode after the camera has been opened and initialized, the new mode must be set and then camera be re-initialized”.
I would much rather see this handled via ASCOM instead of a native driver. But if QHY is not going to play ball, then I’ll be in the camp of wanting (and appreciating!) a native QHY driver in SGP (as @Ken alluded). Unless of course, there is actually something to the “danger” reference?
Dave
Dave we want Read-Only access to this property. For the purpose of writing the value to the Fits HEADER.
Steve
Yes, I know. As I’ve pointed out in this thread multiple times, I would like that too.
However, there are those of us who would also like the ability for SGP to change the read mode as part of a sequence. Control of imaging parameters as part of a sequence is, after all, the raison d’être of SGP.
The challenge in both cases seems to be with QHY and their ASCOM driver (unclear documentation? misunderstanding/miscommunication with ASCOM folks? lack of motivation to address? other?).
I’ve been sharing my communications with QHY (and ASCOM folks) as it might help provide insight to Ken/Jared, and possibly others. And maybe motivate other end users to pressure QHY into doing a better job with their ASCOM driver?
Dave
PS. AFAIK, QHY does not currently have a public support forum, so for anyone interested in raising this with QHY directly, you could try their Helpdesk ticket system:
https://ticket.qhyccd.com/
This is coming for sure… it’s not technically challenging to implement (for cameras that support it), the biggest problem these days is overcrowding the UI. Maybe for now we just punt and add it with per-event gain and offset… I’m not a huge fan of this arrangement though… feels like too many clicks involved to adjust these things that are often not “set it and forget it” types.
1 Like
I can demonstrate this on ZOOM for you. It works please include this. I can also Beta test if.
Steve
Ken if I am asking for something that is not normally done I apologize. If I should be nagging the hell out of QHY let me know. This is what I am seeing on my end…
Take Four images in each of the available READMODEs and display the FITS Header Value for Keyword - READOUTM
Photographic Mode READOUTM = 'Fast ’
Hign Gain Mode READOUTM = 'Fast ’
Super Fullwell Mode READOUTM = 'Fast ’
Extended Fullwell Mode-2CMS READOUTM = 'Fast ’
I understand completely, but, alas, I fear we are unable to provide assistance here. Requests like this fly in the face of ASCOMs existence. The entire purpose of ASCOM is provide standards that prevent software like SGPro from having to implement custom behaviors in order to achieve compatibility with various types of hardware. I know it seems like a little thing, but over years, it 100% pollutes all of our code base with conditional logic based on specific manufacturers.
We are 100% for altering the ASCOM contracts to meet needs and have helped to do this in the past. Beyond this, it is incumbent on driver authors to comply with the agreed upon contract, or not (and explain to you why they choose not to).
Okay Ken I understand. End of my ranting,
1 Like
FYI this was taken to the ASCOM Developer’s list (and cross-posted to the ASCOM Talk list). The question appears to have been answered here, and after a lot of talk over there see
https://ascomtalk.groups.io/g/Developer/message/7669
I took my info from here. If there are any inaccuracies, please feel free to correct me there. This is a QHY Camera/Driver limitation (at present).
Just an update but last time I looked there were some new modes for the QHY600 and it supports :
Mode Photographic
Mode High Gain
Mode Extended Full Well
Mode Extended Full Well - 2CMS
Mode Photographic - 2CMS
Mode High Gain - 2CMS