Planning tools not updating time based on altitude for Start time

Planning tools is not updating the time of the target. I have three screenshots, 8th December, 11th DEcember and 14th December for the same target and the time has not changed

OS: Windows 10 x64

I have been carefully monitoring the altitude lock since the problems seen in the BETA, and it appears that the altitude is not updating

As you can see from the following screenshot from the 8th December, I had set a time of 5 minutes after Transit of 19:46 which resulted in an Altitude of 79.8 Degrees

On the 11th December, I checked the target again, the time was still reporting 19:46 and an altitude of 79.8 degrees however the tarnsit time was now 19:35 so in theory it should have adjusted the start time to 19:40, here is the screenshot from the 11th December

I have checked again today, leaving it a few more days, and again it still reports a start time of 19:46 and an altitude of 79.8 degrees, however I have noticed that the end time has changed to 00:22 from 00:46

If I change the start time to 19:45 and then back to 19:46 the altitude changes, as you can see here:

So 19:46 should have an altitude of 79.6 degrees, if I set the time to 5 minutes after transit, you will see it gets the 79.8 again

So why is End Time updating, but Start time is not?

Please let me know what information you need

Thanks for all the details. I think the only other thing I need to know is what happened between each of those screenshots. For instance… was SGPro left open the entire time, did you close it and open it between days, etc.

Also, logs would be good here… I am logging a lot of info on this feature and I’m curious if the end time calculation is failing silently.


SGPro was closed, and opened up on the days, and even a reboot due to Windows Updates between the 11th and today

I’ll upload the logs from today


Here you go buddy

Ok, I have made a couple changes, but none that I suspect will alter this behavior. The primary purpose of changes for planning tools in is to emit some better logging in an area of calculations that I think are to blame, but I am unsure. At any rate, they will allow me to perform the calculation exactly as they are being performed on your machine. Up in a few minutes…

1 Like


Left it for a few days before firing it up again, as you can see again, Transit is now 19:13 but what is really interesting is that when I set 19:32 the other day, it is now saying 19:38 for 79.8, so rather than it decrease the start time to what should be 5 minutes past transit, it actually increased the start time

Again if I change the minutes to either +/- 1 min, 19:38 should be an altitude of 79.3 as per below:

What is interesting is the end time has moved from being 00:22 the other day to 00:02 which is not far off the 00:06 which is where it should be at.

Link to logs:

Hope you get the information you need

ok, thx. I’ll take a look this evening… logs from this version should allow me recreate calculations here in the US as you see them at GMT.

ok… well I see the problem now at least. I am unsure how to fix it at the moment without having the computer take a year to do it… the problem is that the current algorithms are imprecise when a start or end time exists where the slope is near non-existent. Will need to think a little on this… the math is pretty easy here, but I’m afraid that a lot of machines that people relegate to outside astro-computer might not be able to handle it all that well…

I have a change for this issue, but it is still under testing.


I’ve noticed something else tonight…Whilst a target is running, when you click on the settings for that target, it adjusts the end time to the time when you clicked on settings look:



I manually change the end time to say 20:20, then click OK, click back on settings and it changes it back to the current time 20:16 after changing it to 20:20

Thx. It is of no matter now as literally none of that code is used any longer.