I am having issues using the Altitude lock, if I use the planner and specify an end time of 04:45 for a particular target, it correctly sets the altitude and then I proceed to lock the altitude, however after clicking OK, I then go back into the target, it shows the target end time being adjusted to before the start time, not sure why.
Will post screenshots as soon as the report is created
Link to Logs
Useful Info
OS: Microsoft Windows 10 Enterprise LTSC Ver: 4.1.0.832 (64-bit) .NET: 4.8 ASCOM: 6.5.1.3234
Weirdly in the logs I see the following when I set the correct value:
[07/15/22 09:08:56.201][DEBUG][Main Thread][NONE] Crescent and North America Nebula-3 - Start time has altitude lock, calculating start time for 70
[07/15/22 09:08:56.201][DEBUG][Main Thread][NONE] Transit data -> nt: 01:44:55; ot: 01:44:55
[07/15/22 09:08:56.201][DEBUG][Main Thread][NONE] Transit delta -> 0 seconds (nt: 1.01:44:55; ot: 1.01:44:55)
[07/15/22 09:08:56.201][DEBUG][Main Thread][NONE] Adjusting start time by 0 seconds...
[07/15/22 09:08:56.201][DEBUG][Main Thread][NONE] Current start time 15/07/2022 00:19:00)
[07/15/22 09:08:56.202][DEBUG][Main Thread][NONE] New start time 15/07/2022 00:19:00)
[07/15/22 09:08:56.202][DEBUG][Main Thread][NONE] Crescent and North America Nebula-3 - End time has altitude lock, calculating end time for 56
[07/15/22 09:08:56.202][DEBUG][Main Thread][NONE] Transit data -> nt: 01:44:55; ot: 01:44:55
[07/15/22 09:08:56.202][DEBUG][Main Thread][NONE] Transit delta -> 0 seconds (nt: 1.01:44:55; ot: 1.01:44:55)
[07/15/22 09:08:56.202][DEBUG][Main Thread][NONE] Adjusting end time by 0 seconds...
[07/15/22 09:08:56.202][DEBUG][Main Thread][NONE] Current end time 15/07/2022 04:45:00)
[07/15/22 09:08:56.202][DEBUG][Main Thread][NONE] New end time 15/07/2022 04:45:00)
So it seems that it is accepting the correct time, but when I load up the target again, it seems it is getting something wrong:
Calculating a time for an altitude can be a little tricky and will usually require at least one assumption. You’ll notice that time values of 04:45 (the desired time) and 22:49 are actually both “correct”. When an altitude lock is enabled by itself, the logic for time selection is: pick the one closest to or in the dark. If both are in the dark, then, for start altitude, choose the earliest and for end altitude choose the latest. That looks like what happened here. BUT…
I think this is the issue… when both start and end times exist, there is an assumption that the end time selected be after the start time and vice-e-versa for the other. The start time selection will always use the “earliest time in the dark”. I’ll have a look and see why this assumption.
It’s also worth noting that there is no bulletproof implementation that will yield the desired results every time… we’re aiming for “most of the time” right now.
I “think” that the issue here is that, when SGPro has multiple choices for time, it will always favor the time that is between dusk and dawn first. The end time you have selected seems decently after dawn. This is “crystal ball” type stuff as the “proper” selection likely cant be perfect because there is no way to know your intent… only to implement the intent of “most”.
Thinking of possibly reversing the orders of the decision tree such that it will choose the value closest to the last value (the hint) before applying the “night time” filter.
@STAstro
Actually… before I change anything, can you try something? The new changes in 856 require that you open the target at least one time (it will switch to the wrong end time), fix it, then save the sequence and re-open target settings. The second time, it should select the right end time. Normally you won’t need to do this… it is just the corrective action in this case.
If that still does not yield expected results, those logs will also be helpful.
If I set the start time on Crescent C2R2 to say 22:14, the altitude lock changes and it accepts the value no problem, but when I go back into it, it changes the start time to a time way past the transit time
Link to Logs
Useful Info
OS: Microsoft Windows 10 Enterprise LTSC Ver: 4.1.0.882 (64-bit) .NET: 4.8 ASCOM: 6.5.1.3234
Can you provide a screenshot showing what you mean? For instance, are 22:14 and the other time “way past the transit time” both actual representations of the desired altitude?
Actually, disregard. It’s always difficult to reproduce exactly what you observed, but I’m fairly certain I found a case in which the start time “hint” was not properly used to inform the search and, as a result, was never added to the list of candidates. I’ll try to release a bit later today.
Unrelated, but I’ve also modified the criteria for starting a background load (you might have noticed that your “dots” never disappear… this is because large sequences do not background load and always just wait for a click instead. This has been modified to be a little more permissive)
Just so you have it, here’s an example, you can see the start time of 21:44 and an altitude lock of 67.2
After I click on OK, you can see it correctly in the sequencer:
But then when I click on target settings, it changes the time to 00:51 which ios also way past transit time which is 23:13
I suspect it is loading up the time of when the target gets to 67.2 after transit, and not before transit, so in other words, after the meridian flip., as 21:44 is 1h and 29m before meridian flip, and 00:51 is 1h 38m after meridian flip. As the target will have the same altitude twice, so the program is choosing one over the other
Might be a good idea to have a “Pre or Post” transit option in the “Altitude lock” as I am actually having it do the opposite on some targets, set an altitude lock past the transit “Meridian” time, and it accepts it, but then when I click on settings, it changes it to the pre-transit altitude time
