? Target Altitude Lock Not Working in

Hello! It does not appear that the altitude lock is working for my sequences since upgrading the last couple of times. (This is target altitude lock rather the the Horizon setting in the User Profile).
The sequence seems to lock on the time even when the lock icon is closed in the Target Settings information frame.
I’ve tried updating the altitude under the Target Planning Tools section in the Target Settings frame (right click for western horizon) while the lock icon was closed, but it continued to lock on the time. Then, I unlocked the lock icon, updated the altitude in the Planning Tools section, and locked it again. The target continued to lock on the time rather than the altitude.
Is there an additional setting I need to choose? Thank you and best regards.

Hi there,

We will need more information to be able to help. Please send us logs, SGPro and OS versions and we’ll take a look.

More information here About the SGPro Support category

Support requests go in this category #sequence-generator:sgpro-support

Also… I am not really clear on what you are describing. It seems like you are describing actually clicking on the planning assistant chart to adjust end time (somewhere along a target’s ephemeris). Is that right? If so, altitude lock has no applicability in this case as the time and target will reset to whatever you click on. Altitude lock behavior can only be observed over period of days.

Hello! My apologies. I have been traveling.
I am using under Windows 10.
In previous versions of SGPro, I thought that I could set a target’s altitude lock by going to the ephemeris in planning tools and clicking on the time/altitude I wanted (right click typically for end time). Back in the target settings, I would click on the padlock icon. This would lock the altitude setting end parameter rather than the time setting as the end parameter. SGPro would then stop imaging the target at the set altitude rather than a set time.
For example, in the attached log, RR CET has an altitude lock of 32 degrees that I had set a couple of weeks previously. For the night’s run on 5-January-2020 SGPro calculated the time for that altitude on 5-January-2020 as 11:28 PM.
In actual fact, at 11:28 PM, RR CET was at an altitude of 11.4 degrees at that time. 11:28 PM was the time that occurred when I had set the altitude lock several weeks before so it appears that SGPro locked the time rather than the altitude even though it noted that an altitude lock was in place. Best regards.

The way in which SGPro handles altitude lock has changed in the recent past. Any altitude locks set before this release will not work properly. I didn’t consider this issue during release, but there is nothing that can be done about it now. That said, going forward (meaning, if you go and re-select the altitude again, the lock will be functional once more).

Hello! Thank you for the note.
I’ve tried that with the recent releases and it was still occurring - most recently last week with a sequence in *.435.
Would this be different in *.446?
Perhaps if I completely re-created the target rather than trying to re-select the altitude and then locking it in the established target? Best regards.

Im not sure. I would have to look at more recent logs showing what you describe. The logs you posted actually show correct behavior… the only problem was that it inherited bad time data from the old target. I don’t think that recreating the target will have the desired effect, but I am wrong a lot.

Hello! I’ll run the sequence in a week under *.446. I’ve reset the altitude lock for one target and recreated another target from scratch in the sequence so I’ll be able to compare both target’s end altitude and end times after I’ve target locked both. I’ll let you know how it is. Best regards. Mike

1 Like