View Issue Details

IDProjectCategoryView StatusLast Update
00031695 - Closed w/o ActionBugpublic2019-06-16 23:15
ReporterK7ZCZAssigned ToWA9PIE 
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionunable to reproduce 
Summary0003169: HRD SatTrack seems to be several seconds behind the actual and accurate tracking.
DescriptionNo description is available, other than "seems to be several seconds behind".
Steps To ReproduceNo specific information has been offered with this report. It is not actionable, and the information given below is speculative and inductive.
Additional InformationComputed AOS and LOS times are a function of a few inputs:

1) The user's entered location
2) The user's current, local time
3) The data in the description of the body's orbit, provided by some Kepler files we distribute.

Error can be introduced here by any input. Maybe the user's time is slightly off (it always is, nobody knows what time it is). The user might not have entered a completely accurate location. And the Kepler data might be old or out-of-date.

Before examining the function itself, it seems prudent to verify that the inputs are precisely the same.

The implementation computation itself comes from a third-party library baked into the application. We have a very old snapshot of this library:

I don't know if we have a license for this library, so I don't know which edition (Public, Standard, or Professional) we have. It looks to me like our snapshot of that code came from 2003 or so. The Public edition was last updated in June of 2017, according to the website.

Seems like I'm yet again being asked to explain the results of a test that I know nothing, at all, about; that's a very awkward position indeed.

Since I've been obliged to guess: Maybe the library has some computation errors. Seems well-tested, so this guess isn't too likely but certainly isn't inconceivable. Maybe our Kepler files are bad -- don't orbits decay and change as time passes? I haven't any information about when they were last updated. Maybe customers doing this comparison aren't using precisely the same time or location throughout the comparison.

Superficially, the plotting code works by:

1) evaluating the parameters of the Kepler data to develop the body's orbit path
2) using the time to estimate the satellite's current position with formula based on that orbit path and the Kepler parameters and the current time
3) Calculating the observer's location on earth
4) Normalizing the calculated position of the body (#2) against the observer's position

I haven't a clue of how #1 or #2 work. I know the result, though, is the position of the satellite described as a certain altitude over a certain point on the earth.

#3 and #4 then are pretty straight-forward polar trigonometry to figure out where the #2 calculated position appears in the observers sky.

It's also possible there are errors in our build or application of the library. One thing that's readily observable about the application is that it's slow.

The application is slow because it iteratively computes the position of each satellite on each pass to find the position. It'll test a particular time, 15:29:30, for example, and see if the satellite is visible. If it is not visible, it will advance the time a few seconds and try again. 15:29:36, say. Visible? If so, we have our answer. If not visible, we keep looping.

This works, and it's simple in that it doesn't require rearranging any of the math the library is doing for us. We just repeatedly ask: visible yet? visible in six seconds? Visible in 12 secondS? visible ... ? until the object is visible.

The disadvantage is that it's slow when compared to a closed-form solution that directly yields the resulting times.

Another disadvantage is error. We only test every few seconds, since testing more often would be more tests, and slower. The steps between guesses isn't refined like an incremental approximation might be ... so the estimate can be off by as much as our guess. If we test 15:29:30 and see the object isn't visible, we'll try 15:29:36. The object might appear at 15:29:31, but we'll report 15:29:36 and quit doing calculations. Or result might be off, and the maximum error is the width of our estimate.

If we're concerned with the program's accuracy, then I'd probably proceed with these steps:

1) Identify multiple sources for correct data.
2) Define a few tests -- locations, satellites, and so on -- to compared
3) Compare the reference sources with our results.
4) Investigate why they're different.

Ideally, we'd write code to automate this.

It seems prudent to investigate the licensing status of the tracking software we're using. Upgrading it would be a good idea. It appears that the professional edition offers closed-form solutions, so we'd just calculate the AOS and LOS times directly, instead of iterating to them. If that's true, then it's a win for performance and helps accuracy.

TagsNo tags attached.
ModuleSatellite Tracking
TestingNot Started


related to 0003152 closedK7ZCZ Ham Radio Deluxe Add seconds to the hh:mm display above the "Next Pass" time graphs 
related to 0003363 new 1 - Backlog Satellite tracker does iterative math 
related to 0003364 new 1 - Backlog consider upgrading and/or licensing satellite tracking library 



2019-06-16 17:32

administrator   ~0008109

At this point, I consider the initial report to be speculative. There's been no solid evidence that this is the case. I've had AMSAT members take a look at it.

Issue History

Date Modified Username Field Change
2019-02-08 13:20 K7ZCZ New Issue
2019-02-08 13:21 K7ZCZ Relationship added related to 0003152
2019-02-08 13:22 K7ZCZ Assigned To => WA9PIE
2019-02-08 13:22 K7ZCZ Status new => assigned
2019-06-16 17:32 WA9PIE Status assigned => closed
2019-06-16 17:32 WA9PIE Resolution open => unable to reproduce
2019-06-16 17:32 WA9PIE Note Added: 0008109
2019-06-16 17:33 WA9PIE Project 3 - Current Dev List => 5 - Closed w/o Action
2019-06-16 23:12 K7ZCZ Relationship added related to 0003363
2019-06-16 23:15 K7ZCZ Relationship added related to 0003364