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.
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.
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.
There are lot of things to do on SkyFlats taken by AutoFlats.
Bugs/feature requests:
Autoflats scheduler when showing before and after previews (via right-down corner), it not correctly updates the screen (time of start and end when it should run) or updates it only after a few seconds
Autoflats scheduler should not run in times when it was not scheduled to run. It should behave like it is not enabled and not ask every time during the night if it should run. This of course only in case if the light source is Sky.
Autoflats sequence should behave like regular sequence target. In case if light source is Sky, it should open the dome->sync the mount with dome, connect equipment and begin to take flats
In case of SkyFlats, in case of minimum exposure time detected in the evening or maximum eposure time detected in the morning it should not abort the flats sequence, but it should wait for 60 sec. and try again, because the sky will be dimmer/brighter in a while.
The autoflats sort order “Narrowband toward light” is great, but it would be better if default order will be “Ha, SII, OIII, R, G, B, L” in the evening and reverse order at morning. Today it is not reversed and is changed to this “R, G, B, L, Ha, SII, OIII”. This is wrong order, because the exposure times are not in “right” order to be ± equal to each filter in the changing sky light conditions.
When using Autoflats with a flat panel, could there be an option to have it update the default exposure and brightness settings for each filter as it determines them? Primarily of interest the first time setting up a new imaging train (or updating some component, like a new set of filters).
If the USB connection to the imaging camera is lost, it can take SGP quite a while (several minutes) to “understand” that this has happened. It is obvious to me though when the download is stuck and seems to take forever. At that moment the TEC panel in SGP also already indicates the sensor temperature as N/A (another sign that the connection with the camera has been lost).
I then need to wait all those minutes until SGP gives me back control to stop the sequence, disconnect the camera in SGP, cycle the USB and/or power connection to the camera, reconnect the camera in SGP and restart the sequence.
Perhaps SGP could use a parameter that defines the maximum amount of time allowed until it concludes a camera is non-responsive. Presumably this timeout period is already hardcoded in SGP somewhere. PHD2 has a similar user definable option for the guide camera.
Unsafe alert from Safety Monitor will trigger SGP to run End of Sequence options. This is not always OK, or at least not for all End of Sequence options. Close Shutter/Roof and Park Mount is OK, but Warm Camera not necessarily. Clouds can pass and when the sky is clear again the sequence can continue, but then needs to cool the camera again. On the other hand, when the overall sequence end time is set and that time is reached, then Warm Camera is obviously OK.
Would it be possible to have SGP distinguish between “Safe”, “Unsafe (waiting for sky to clear)” and “Unsafe (end of session)”? Then assign different equipment actions to both Unsafe states.
This is true and is a thing that has long been on our backlog to provide additional control over. It’s not a small task though and it won’t be present in the 4.5 maintenance release (a collection of smaller things), but we can definitely look at refactoring end of sequence actions afterward.
I think I’d be willing to add a “variable” to control this if that’s what you mean. Man aging the complexity of the UI is a constant struggle, but for specialized or ultra-detail-oriented things, it seems like an SGPro variable is the right place for it and this can be part of the SGPro 4.5 maintenance release
Yes, I can understand this would not be a small change and therefore may take some time to implement, but it would certainly be a welcome one. Currently an Unsafe alert will even trigger End of Sequence actions when a sequence is not running at all. This has taken me by surprise me a couple of times already when I can see the clouds coming and already abort the sequence, park the mount and close the roof (but do no warm the camera) while waiting for clouds to pass. Some time later when I am not paying attention the cloud detector then triggers an unsafe alert and SGP will still warm the camera. This can be annoying as I was just trying to prevent that from happening.
That could indeed be a solution, but we already have the download times for the camera in the equipment profile and control panel. Those are currently probably only used to estimate the remaining time for each event in the sequence, but might as well be used to trigger a warning or error (e.g. prompting to abort the sequence) in case a download does not complete within the specified download time (with perhaps a certain safety margin).
Please add me to the list of those who would appreciate the ability to cycle through targets to better and more evenly capture a mosaic. As an astrophotographer with a mobile observatory, I generally prefer to rotate through events per target and would favor the ability to also be able to rotate through targets as I dip my toe into mosaics.
Better sequencing options is definitely on the list. I am unsure right now if it is a 4.5.X option at this point. Maybe it could be a partial 4.5 option like just adding a “balanced” option and not adding other scheduling stuff just yet.