Please consider this feature in SGP 4.4
Thanks
When executing a script it would be nice if an entry would be added to the Notification Center with the return code from the script as well as any output of the script.
Right now the only way to tell if a script has been run is to look in the log file, and AFAIK that doesn’t tell you if the scripted succeeded or failed.
Not sure if this string is still being looked at…
Request 1:
I often look at Planning tools only to see when the Moon is rising and/or setting. Since this information isn’t related to a specific target, it would be nice if this information was also available without having to go to “Target Settings” on a random target, then clicking on Planning tools.
Request 2:
Planning tools gives a warning if the “Target end time” is during daylight, even if the sequence has an “End sequence at: xxxx” that is prior to daylight. I’d like to see the warning only if the actual end time is during daylight.
Yes. This is still the primary consolidation of community driven feature requests. Currently working on the chain solver release and that, coupled with standard support hasn’t left time to pull from here, but it is absolutely not dead.
I would like to kindly request adding an in-sequence readout mode change.
Use case on QHY294M is shooting LRGB in 47M Mode and SHO in 11M Mode, which provides great results IMHO.
1 Like
@flamidey
If your QHY294M is like my QHY600M, then it is not currently possible for SGP to change the read mode. It is only possible to change by “disconnecting” from the camera, changing the mode manually and then “reconnecting”.
Attached is a recent exchange I’ve had on this from QHYCCD. Doesn’t sound hopeful that things will change down the road either
QUES=> “Is it possible that this situation could changed in the future (with an upgrade to firmware/driver/ASCOM)? Or is this not possible due to hardware limitation?
It is unfortunate because current status makes it challenging for remote and autonomous operations (cannot change read mode without human intervention).”ANS=> “Unfortunately, it cannot be changed by upgrading the firmware, driver, or ASCOM. This is because this is not a common function. There is no remaining mode setting location in the software, so we can only configure it in the interface before the camera is connected.”
It still sounds to me like this is a “won’t” and not “can’t” on the part of QHY, but ¯_(ツ)_/¯
More info in this thread here:
https://forum.sequencegeneratorpro.com/t/please-add-qhy600-camera-mode-to-the-fits-header/17062/25
Dave
Thanks for the info.
Although I’m sure the environment is different, NINA does it just fine (albeit with a native driver).
@flamidey
The QHY response was somewhat ambiguous. Based on your experience with NINA, it sounds like the issue is not hardware related. And that it could in theory be done if (a) ASCOM was updated to accommodate it and (b) QHY updated their ASCOM drivers to accordingly.
I wonder if anyone has already approached the ASCOM folks about this (handling “read mode” via ASCOM)? Is this a QHY-only issue or are there other astro camera manufactures in the same boat?
Hoping the ASCOM folks would be motivated to accommodate as otherwise folks will end up drifting away from that standard (such as with the NINA native QHY driver you mention).
Dave
1 Like
ASCOM has supported readout modes for a while:
From the chat above it sounds like this must be set prior to connecting the camera. But their API documentation shows that the camera is connected and then the read mode is set. I don’t see any reason why this wouldn’t work with ASCOM. That’s from the 2.3 documentation which can be found here. Update Log
I’m not sure what their current API version is, the “DOC” link seems dead and I’m not sure if 2.3 is current or just the last one listed there 
Jared
1 Like
Yeah - that makes it even more odd. But QHYCCD is pretty insistent (per dialogue) that it must be set prior to connecting. And that is how it currently works in practice, for my camera anyway.
I do wonder if things have become lost in translation with QHY and ASCOM. For instance, the QHY ASCOM driver refers to “Read Modes” whereas ASCOM refers to “Readout Modes”.
As mentioned by @flamidey above, NINA seems to handle setting of QHY read modes (via proprietary driver, not ASCOM). Have not verified it myself but I see in NINA Camera Settings there is this:
Those camera settings can only be selected after connecting to the camera.
And in the Sequencer there is an option to set Readout Mode, but just a number, not a descriptive list:
I assume there is a number equivalence with the descriptive list, but I have not used NINA enough to confirm.
So sounds like QHYCCD is just not willing to modify their ASCOM driver to accommodate? Frustrating from an end user perspective.
Dave
In NINA when you connect the camera you have a drop down ton choose the mode for both sequence subs and snapshots. The order in which the modes appear in the drop-down match the mode is, starting at 0.
1 Like
+1 for in sequence change of camera mode.
Here are a couple of potentially related matters:
I am just trying to get my head around autoflats so maybe missing something but does this take Camera Mode into account, I can’t see it anywhere, it only seems to allow gain and offset?
Can we have Camera Mode added to the fits header please. I sometimes use the same Gain and offset with different modes and with it not being recorded in the header it can be a PITA. I went back to process some old data and wanted to run some new calibration frames but couldn’t work out what mode I had used at the time. it would have been useful to just look it up.
Currently, it does not, but this is indeed the best place to ask for it.
This has been around for quite a while now. If your camera reports it, it is inserted into the headers as both READMODE (in the 4.4 beta) and READOUTM (in current 4.3 release). Maybe it’s not present for non-light? I’ll verify.
Just to check my understanding.
A recent light using 4.3 shows READOUT = “Fast” is that referring to the “Use High Speed Readout” ?
So 4.4 will have something like READMODE=“Mode 3 Extended Full Well - 2CMS” for QHY600 ?
Its the latter that I am interested in, including for flats.
No. Unfortunately, that particular issue is not something SGPro can handle. Lots of detail here:
The summary is this: The QHY drivers do not report the camera’s readout mode correctly and, because of this, SGPro reports incorrect info in the headers.
Thanks Ken. My head exploded before I got to the bottom of that but I hope QHY/ASCOM can work it out. I understand why you want to stick with the ASCOM driver, I worked in systems development for 40 years, but the native driver seems so much better in this case and my testing of NINA (native) vs SGP(ASCOM) showed it to be much faster on downloads.
We actually had native drivers to start, but retired them in favor of ASCOM. An outfit our size simply cannot afford to commit to native driver support for all the gear we support. That said, we may be willing to (begrudgingly) support QHY and ASI natively because of their popularity. Certainly not committing to that here at this point, just noting that it’s not off the table.
Well, it’s highly appreciated Ken.
If ever you decided to go down that road, that would definitely bring me back to SG, as my QHY294M as a real advantage in using different modes, at least when doing different target types as is typical in this season.
I completely understand. I hesitate to say this on an open forum but I am considering moving to NINA because of this issue, and I really don’t want to because I really like SGP and it will be a painful process. However, the benefit of having the Mode is important to me and perhaps even more important is the native driver does downloads on my setup in around 2s compared to 7s-8s using ASCOM. That’s quite a few extra subs over a year, quicker focusing, and it also allows me to take shorter subs.
A little background:
I take 40 - 50 fifteen-minute exposure with each of LRGBHa and sometimes SII and OIII, so it takes quite a while to get all the pictures for a given target. I usually have 4 or more targets in any sequence, and almost never finish a target before it’s no longer up at night. I currently have 5 active targets and 5 more I will work on when they are back up.
When a target is no longer in the sky, I do a “Save Sequence As” and give the new file the name of the no-longer-in-the-sky-target. In that sequence I delete all the other targets, then open the original sequence and delete the no-longer-in-the-sky-target.
When that target is back in the sky, I open its sequence file, do a screenshot of its RA, Dec, angle, and event info. I then open the sequence file I’m currently using and import the other sequence file. Because importing a sequence doesn’t import the event info I manually enter it from the screenshot.
Request 1:
Have the “import a sequence” action import everything including whether or not the “Slew to and center” check box is checked. I want those targets to be IDENTICAL to what’s in the imported sequence.
Request 2:
Not sure exactly what to ask for, but I’d like something to make the process of “archiving” and “un-archiving” targets easier. Having to do a “Save Sequence As” then delete some targets then delete the saved target then import 6 months later is a hassle.
One possibility would be to allow each target’s info to be in a separate file, and a sequence would logically be a list of target files. “Archiving” a target would simply be removing its file name from a sequence, and importing it back in would simply be adding the file name to the sequence.
2 Likes