SGPro 4.4 Backlog - Our Thoughts and Request for Community Input

I use SkyTools too. It would be fine to have any import of targets from skyTools to SGP. If needed, I can cooperate on this to send you exports and to test it.

Autoflats read number of taken flats from disk. I would like to have a button somewhere (for all targets, or sigle target), to load the number of taken images to the sequence. I use quite large set of objects in the sequence file and some times (probably my fault, but every few weeks happens) when I set active target or need to reset something the sequence progress is reset (zeroed) and I need to reconstruct it manually (let say 20 targets times 3-4 filtes :man_facepalming:). But there are sure more important things to do like:

  1. better focusing routine (focusers are not perfect and bad focus = bad image) where the final computed focus position will be confirmed by defined number of points near the focus. I know that seeing is then important, but if not better focus point can be find, then go to computed focus. This could be an option to some one in the focus settings. Or have more focus routines from which to select.
  2. some times I need to change guiding during sequence. Let say, the moon is up til 2:00, so I take 10-15 min subs. After moonset, I want to make RGBL images from 30-90 sek. For this I do not need guiding (have precise mount). When using PHD2, there is too much time wasted (even when doing dithering every 2-3 pictures) - dithering, waiting mount to set + take into account that camera reads the image 10+ seconds. If I switch to direct mount guiding, I save much time and get more RGBL images during night.

Just a quick note here (violating my own request not to be too distracting in this thread), but I have something here that I think will mostly satisfy this… it’s really actually complete, but has some issues that I need to address. Essentially a “sync to disk” function that will automatically inspect the image data and set sequence progress. It’s currently pretty smart and is capable of detecting event changes that would invalidate an image as counting toward progress (e.g. changing an event’s exposure time). There was another request for this too. I guess I’ll make time to button this up next.

2 Likes

Thanks for the note Ken.
Of all the feature requests I’ve submitted, this is near the bottom of my list. It’s not too often that I have to abort a sequence after one or more images have already been saved; last night that happened which is why I entered this request. Doesn’t happen often but it’s a pain when it does.

As a fellow software developer, I know we sometimes like to do features that aren’t the most important but nonetheless we enjoy or just want to get off our plate. I look forward to your solution.

I agree with EricC but will be happy user of “sync to disk” function/button :wink:. 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.

1 Like

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.

Even better: a way to fill dusks/dawns calculated times as start/end.

1 Like

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.

1 Like

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…

Thanks!
Mike

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 :person_shrugging:

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:
Capture_NINA_QHY600_Connect_Settings_Readout_Mode_Sequences_DropDown2
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:
Capture_NINA_Adv_Sequencer_Instruction_Set_Readout_Mode_2_CROP

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