Can we get an option for DST in the sequence, when the clocks went back, all the timings had to be manually adjusted, which whilst not a big problem, it’s a bit of a chore 
Re-freshing this topic, no one replied and it is that time of year again, is this something that can be added to a global sequence, so a tick box for say Daylight Saving where it will add an hour onto the targets, and unchecked will remove an hour?
Well probably not for this year :-/ I think the real way to handle this would be to use UTC internally. And use altitudes rather than start times for targets. We’ll be revamping a good deal in this area for the 4.0 release so I think that’s a good time to get this work in.
Jared
When you say use Altitudes rather than start times, how will that work, what are your thoughts? For me I live in a place where I Have obstacles in the southern area of the sky, so when imaging objects south, I cannot start until the objects have hit meridian, hence why I use start times this way, so how will altitude help with that?
Simon
It seems like maybe, for your active and new sequences, you can “altitude lock” your target start time. This allows time to vary freely from day to day.
Does this mean if say I want it to start at 21:00 tonight, but then in two days time it will start say 5-6 minutes earlier due to it progressing across the sky each night?
That is correct. I was just looking at the help file for Altitude lock and it seems as though we have neglected to add it. It came out in 3.0
Ooooh I will take a look
OK I have never looked at the user profile section below, so I have a question, if I can see down to a declination of -12, how does this translate to the “Site Horizon” question?
Don’t worry too much about that value. It just sets the default position of the planning assistant’s horizon line. That line can be changed at any time to support any value you want. It does not influence the sequence, it is just a visual guideline.
Does the altitude lock take into account DST etc? So here’s a thing…
If say the last sunday of October which is when DST changes to GMT in the UK, so the clocks go back at 2AM, if I have a target that starts at say 00:30 and set to finish at 03:00 and the PC time changes at 2AM back to 1AM, does this mean that the target will stop at 03:00 or 02:00 ???
I can’t recall offhand what events in a sequence trigger end time calculation (when altitude is locked). I’ll look here in a bit.
After playing with the planning tools and getting it operational, it seems that it does not dynamically adjust the time from one day to the next. Last night I set Crescent to start at 20:30 and finish at 22:37, this resulted in a start altitude of 77 degrees and a finish altitude of 63.8 degrees. I loaded up the sequence today, and it still has the correct altitudes, but the times have not changed. When I go into the planning tool, it tells me that transit is now 20:26 at 77 degrees which is what I would have expected the sequencer to change the time to. You can see here:
Click on the little lock icons to lock the altitude. The screenshot you have above is “time locked”… meaning that altitude will vary from day to day
Thanks @Ken
How accurate is the altitude lock? I mean for example 62.9 degrees can cover quite a few minutes of time, so could it not end up sending the scope to a pre-meridian flip for example if I specify I want my targets to start at the “Transit” time?
It’s not that accurate right now, but should be within ± 2.5 minutes of the edge of the period of time covered by that altitude. Currently the lack of precision here is a trade-off for performance, but if you keep the error in mind plus another minute or so, you should be safe.
I’ve noticed that enabling the lock takes a while when you click on OK after
So here’s my next question…lol
If say Crescent Nebula has a transit time of 20:28 and I specify 20:29 but then click on the Altitude lock, which will it adhere to first, the altitude or the time?
Time is the only thing SGPro will ever consider. The altitude metric is just extended to the user as a different way to express time.
1 Like
