I agree with EricC but will be happy user of “sync to disk” function/button . For me (and for everyone who wants to take perfect images) the most important things are:
smart and robust autofocusing routines
sequence automation without user intervention
automate acquisition of calibration frames (and enable it to process in Pixinsight)
Smart and robust focusing routines. Most of focusers never get back precisely to previous position. More focus points = more precise curve, but longer path to return to the computed position = not precise focusing. I see two ways how to solve this problem. First as I wrote previously, make more checks around the computed focus to eliminate the long return and error of focusers. Second is more complicated. I can imagine to create a calibration routine to compute errors of focusers and set up all focus settings in SGP (like backlash, focus shifts between filters and so on).
Sequence automation without user intervention - SGP still needs in some situation user intervention. It would be nice to have a global settings “unattended operation” in which case SGP will have timeout on each prompt and “do safe decisions” or have default response defined on each prompt. I know this is probably very complex change, but too many times (mainly after autoflats were introduced ) I found morning SGP waiting for some “stupid” question/prompt when cloud came for 15 minutes. Maybe there is other solution of this problem.
Automate acquisition of calibration frames (and enable it to process in Pixinsight) - autoflats are a big step in this way. Calculation of exposure times of sky flats is still not perfect which cause that not all sky flats are taken in given time period (some of them are out of defined range). I would like to have the possibility insert custom field with defined text to FITS header which would be defined global and will by inserted into all defined types of light, flats, bias and/or darks (field “flat_sequence” with some text like “N200-correctorX-cameraY-seq1”). This custom filed can be used in Pixinsight to match lights and flats together in “batch pre-processing”. Always when I need to take new set of flats (on changing camera angle, …), I will change this field text. Can write more, if some one is interested.
One feature that would be nice within the Planner tools would be a checkbox or even buttons to populate start/end times with moonrise/moonset. The tool does give the data right there on the lower right, but I need to click ok and then edit the fields manually.
I believe there’s already a request for a more general start/stop sequence ability. For example, keep the current time or latitude options, but add sunrise/sunset (plus or minus) times (@flamidey’s post), moonrise/moonset (plus or minus) times (@pmumbower’s post), and others.
For mosaics I would love the ability to take all of the same channels in each panel sequentially before moving to the next color. This would help reduce sky BG variances in the panel groups.
Example: For a 4-panel RBG, take all the reds events in panels 1 then red events in panel 2, reds in panel 3, reds in panel4 then repeat for blues in panels 1-4 then greens…
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.
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.
@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.”
@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).
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
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.
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.
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.
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.
. For me (and for everyone who wants to take perfect images) the most important things are:
