getGroundTracks isn't generating points all the way to the antemeridian

[eric-g-97477]

The TLE I am using is:

(from https://celestrak.org/NORAD/elements/)

Yaogan 30-3-1
1 43081U 17085A   23255.08539617  .00003307  00000-0  31592-3 0  9999
2 43081  34.9957 136.4707 0003991 355.2856   4.7811 14.92839335311372

stepMS was set to 10000 startTimeMS was set to 1698152211870

The final coordinates were:

first track - ( 168.64888285189693, 23.240111501597084 ) second track - ( 166.54109672164154, 9.207423700081948 ) third track - ( 165.9980830743187, -8.892570482834437 )

I tried setting stepMS to 100, for example, but the behavior was the same.

My expectation was for the track coordinates to end somewhere close to 180.

[eric-g-97477]

The reason why it is failing is because in getOrbitTrack there is an assumption that maxTimeMS is 6000000. However, in this case, the duration of the orbit is longer. The average duration is, however, shorter than 6000000, as specified by the TLE itself.

I can think of a few fixes...

1. increase the maxTimeMS default -- perhaps to _MS_IN_A_DAY / 4, which is a value used by getGroundTracks
2. when getGroundTracks calls getOrbitTrack in groundTrackPromises, pass in a value of 0 for maxTimeMS to disable the doesExceedTime check
3. when getGroundTracks calls getOrbitTrack in groundTrackPromises, pass in a value of orbitTimeMS * 2 (or something) for maxTimeMS

Are there others?

I am not sure what the most appropriate fix would be given my limited knowledge in this space. However, if you can tell me what it should be, I should be able to find the time to submit a PR for the fix, especially if the PR can be reviewed and accepted quickly.

[thkruz]

That TLE has an orbit of ~96.4 minutes, which should be less than the 100 minute maxTimeMS. I am not sure what you mean by "average duration" vs "duration of the orbit". Edit: I get you were referencing the variable names now.

1) Quarter day will work, but if you are going to make it more robust, why limit yourself to LEO. 2) Disabling the doesExceedTime check may cause a hang if you feed in a non-LEO TLE. 3) If the orbit is twice the orbit than bail out of the loop seems to be the most robust logic of the three.

Let me pull the repo and do a little testing this morning.

[thkruz]

I think the issue might be related to the earth rotating under the satellite. In ECI coordinates, where we pretend the earth isn't spinning, then the satellite makes a complete orbit in < 100 minutes, but if the earth rotates for 90+ minutes then the ground track of the satellite does not wrap around from -180 to +180.

You can solve your problem immediately by just increasing the maxTimeMS parameter you are passing to getOrbitTrack (mainly stating that for anyone else reading). I agree that it would be more intuitive that maxTimeMS is used almost exclusively for limiting the ground track and it is not intuitive that you need to increase it sometimes - but I do not use this library regularly.

I added a PR to fix the issue, but I am not sure how active @davidcalhoun is on the library.

[eric-g-97477]

The primary issue is that I am calling getGroundTracks which does not accept a maxTimeMS parameter to pass along into getOrbitTrack. If simply increasing maxTimeMS is an appropriate solution, then perhaps getGroundTracks can add maxTimeMS to its parameter list and pass it into getOrbitTrack.

As for my term usage, please excuse it...I am not that familiar with this space and am approaching it from the angle of a simple user. But, it looks like you were able to reproduce the issue.

Thanks for the PR. I hope @davidcalhoun will accept it soon. Or, perhaps, you could simply fork and maintain this library now if @davidcalhoun has abandoned it.

[davidcalhoun]

Thank you both! I'll take a look when I'm able to.

[davidcalhoun]

Fix is now in 4.9.0 - thank you both!

[eric-g-97477]

I will test the fix on Monday. I expect it will work and this issue can be closed.

[eric-g-97477]

works perfectly now. Thanks again for getting this done quickly. It is appreciated.

[eric-g-97477]

I just came across another case where the ground track is not being computed to the antemeridian. The TLE is:

BIIRM-8 (PRN 05)
1 35752U 09043A   23344.24313010 -.00000055  00000-0  00000-0 0  9999
2 35752  55.5144  63.8499 0056088  70.2924 288.9699  2.00552469104906

generated with the start time of 1702661804008

I am guessing that this TLE differs from the first in that the curve is tighter than the previous one. My guess is the factor used to allow more points to be computed in the hope that they will cross the antemeridian is not large enough yet.

Not sure what the best fix for this is...increase the factor, have getGroundTracks to accept a custom maxTimeMS...?

[thkruz]

"Problem" is here: https://github.com/davidcalhoun/tle.js/blob/ce8f7b8967c91545120bb1d9aef9b2e56ad79a42/src/sgp4.js#L549

That TLE is for one of the GPS satellites that goes around the earth twice (2.00552469) a day. The minimum for that function is 4 passes a day. Anything with a mean motion less than 4 will not draw the ground trace. You can try raising that number further, but the original intention was for plotting LEO satellites, there might be some other unintended consequences if you just raise it.