This is not working code, but one of the reasons we keep delaying this is not because the math is hard, but rather:
What does the UI look like? (sample below)
How to modify (enable, disable, error) the altitude UI if the target location data is not present or invalid
How to present a state where the user’s terestrial location information is nor present or invalid
Starting with the first bullet, thoughts on this? You would be able to select as many starts or ends as you like and they will function logically as “OR”. If you had two end times checked (time and altitude), end the target at a specific time OR when the target reaches specified altitude (whichever is first).
just thinking out loud here - does it make sense to let the user specify both a time and an altitude? would it be better to calculate and show one based on how the user has entered the other? meaning that if you set an altitude of 30 degrees then SGP would just advise you that the target would start at, say, 2:30AM, or if you set a start time of 4AM, SGP would tell you the altitude is for instance 45 degrees?
This will be the best approach when a target location is available, when it’s not, I’m thinking maybe just disable the altitude tab and target settings will work like they do now.
To @pfile’s point, there is not a simple relationship between altitude and time as suggested because the time of a given altitude depends on the day it is calculated. The date for the calculation is only known when the sequence is running.
that is true - my assumption was that SGP would be telling you the timings for the “next pass” of the object when calculating it for you based on the altitudes.
You probably don’t want that either. What you likely want is “nearest” pass. For instance if your target has already passed the start time/altitude for the night but you got a late start you wouldn’t want SGP to wait until tomorrow to start imaging that target.
fair enough, i was envisioning setting up the target in the afternoon or early evening and wanting to know what time the target would clear my house.
however, since i would think of the time shown as only advisory, i didn’t expect that it would prevent the target from running if i were setting it up while it was in the sky. after all as @DesertSky says these times have to be computed on the fly anyway, so as long as the horizon constraint was satisfied then the target should be eligible to run. that is, currently if the time is 11PM and i create a target with a start time of 10PM and then press “start”, wouldn’t SGP still run that target? i am thinking about this the same way - if i entered an elevation of 40 degrees and it reached 40 degrees at 10PM, then it would still be eligible to run when i clicked “start” at 11PM.
anyway, once i’ve set up a target, i pretty much don’t care when it runs anymore. i will just know that it won’t start until the target is visible, and will be able to start earlier and earlier each night automagically. the initial time that would be calculated and shown in the UI is basically just advisory. i’d still have to arrange the targets in order of RA, i assume, so that as the current one goes behind the tree, the list of next possible targets are all “legal”, meaning have earlier RAs.
Isn’t the simple relationship the sidereal time? An object will reach a given altitude at the same sidereal time every day (Solar system objects excepted).
Could this be done by an additional checkbox in the time limits tab “Use sidereal time”. The user specifies the local times for today. SGP remembers the time and date, then for future runs converts the date to sidereal and uses that.
As long as we are engaging in design concepts, my preference for starting and stopping a target is to start a target when it is three hours or less east of the meridian and stop a target when it exceeds three hours west of the meridian. When SGP is making a selection as to which target to start (when there are multiple targets listed) it needs to scan all the targets in the list and always pick the target closest to its ending time because that target is closest to going out of range. Using this (or similar) logic means you never have to update any start or end times.
So what does “for today” mean? The date/time I create the sequence? I don’t think that would make a lot of sense. I’m not a wizard at astronomical calculations but sidereal time has a relationship to RA but not to altitude. Altitude is dependent on one’s location on earth. So someone at 50 degrees latitude and 20 degrees latitude could have the same sidereal time but different altitudes.
If your observatory is portable the altitude won’t be the same when you move to somewhere at a different latitude. But most people won’t be affected by this.
I suggested “Today” meaning at the date you save the sequence to avoid people having to enter the sidereal time directly but really specifying sidereal time or Charlie’s suggestion of hour angle limits may be better.
One sort of extreme example of using meridian limits is the ability to setup a sequence file with multiple targets which are automatically selected during each imaging run. Let’s pretend someone decided to plan out their imaging tasks for all of 2018. They setup a sequence containing perhaps 50 targets all using the meridian limit start and stop times. The targets are entered in random order. Every imaging night in 2018, you start your sequence at astro dark. SGP scans the list and picks the best target from the list and goes. If there is time when that target finishes, pick another and continue.
this is essentially what some “High End” control programs do. however in that case it is absolutely impossible to know what’s going to run on any particular night because the scheduling decisions are made on the fly. while the functionality you are describing is pretty much what i want, i also need the ability to know what’s going to run on any particular night so that i can change things up if need be.
AIUI at present SGP runs targets in the order they are in the list, choosing the first one that needs data collecting. If a target is available but can’t be started yet it waits until that target is available, even if there is a target in the list that could be started.
Changing to a system where the target to be run is selected from many according to various observing requirements seems like a really big change to the internal operation of SGP, it becomes more like ACP lite.
My opinion is that SGP would be better filling the simpler astro imaging data collection niche. Better to have a simpler, more easily understood, system where the user has much more control and to implement this well.
I agree that my example is probably even more “automation” than I really want. But I would like some help in determining best start / stop times without having to go to a planetarium program and it would be nice not to have to repeatedly update a target’s start / stop time when imaging a target spans several weeks or even months.
However, even an entry in the Target Settings dialog box that showed the target’s next transit time, would help greatly in picking an optimum start / stop time.
I have only recently started using multi target sequences where I have an “early” target and a “late” target. Figuring out the best start / stop times can be a bit time consuming.
The 2 things I hoped to get out of the altitude function are covered by all the discussion above, specifically:
If you’re currently working on a single object over multiple nights, set the height it becomes visible and height it “sets” behind your local horizon, without having to tweak times each night. Its not unusual to be working on a single object over weeks and even months at times, so the start and finish times can change a lot. For myself, I map my home horizon each year in Astroplanner to account for trees growing (or going) - and therefore know my horizons for each dec very well (along with having rise and set alitudes calculated and visible within Astroplanner for each object).
Also love the scenario you enter multiple objects and let the program choose what should be imaged next based on altitudes. People could even separate filters into separate events to ensure you only shoot blue up high, red lowest, green in between.
As for the UI, it would be wonderful if it calculated times off alitudes (when object location entered) or vica versa, but initially not essential.
While I’m day-dreaming (and apologies for going bit off topic), point 2 above reminds me how wonderful it would be to have a window listing the next 10 or so (or all) events SGP will execute at roughly what times. Apart from being able to see which object will be next by altitude it would be so nice to see for sure that SGP is about to position, or focus, or change to a new object. Some sort of “parsed” predictive window, with a pointer for the current event executing. At times I’m crossing my fingers hoping I selected or deselected all the correct autofocus, position, etc options for an object, and you never know for sure until the sequence gets to that point and “does its thing”. End of dreaming
