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.
Mike
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 How to Submit Logs in SGPro - SGPro Support - Main Sequence Software
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 3.1.0.435 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.
Mike
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.
Mike
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
Hello! Here is the update using *.446 and Windows 10 with altitude lock over the last week.
I am probably doing something incorrectly or the target altitude lock may be working.
My work flow - I go into the ephemeris and right click on the altitude/time for the observing run (or left click for the eastern horizon), then go back to the target panel and click the padlock in order to lock the altitude
I’ve attached two log files. The first, starting 22-January-2020, follows the short period variable RR CET till it set in the west. I had set the altitude to about 32 degrees a week ago. I had set it several times before that as well. If I am reading the log correcty, it appears that SGPro read the altitude as 32 degrees and the time as 9:36 PM. The actual time for RR CET at 32 degrees was closer to 9:01 PM for the run. 9:36 PM was the time set originally a week ago, so it does not appear that SGPro updated the altitude lock based on the current date.
The second log follows long period variables V AND and Y AND from 23-January-2020. I had reset Y AND as above for RR CET. I recreated V AND completely and then set the lock as in my work flow comment above a week ago. Y AND appears to show a horizon with a time of 10:55 PM when the actual time for that horizon was 10:35 PM. V AND shows at time of 9:50 PM for the altitude when the actual time for that altitude was 9:26 PM - both were the times for the altitude when I first set the locks a week ago.
It appears that I am not using the horizon lock correctly or that SGPro is not updating the horizon lock for the actual run date/time.
Thank you for your help. Best regards.
Mike