sat_t->orbit was of type unsigned long as were other orbit counts in gtk-sat-map-groundtrack.c.
These were made merely longs. A signed long (32-bit) gives us space for several thousand years in low earth orbit. (2^31/365/18).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think we should give this some more thoughts. Clearly, the issue is in the ground track calculation algorithm and as far as I can see nothing has been fixed there. Changing the orbit counts to signed integer is a bad idea since negative counts have no physical meaning. I'm afraid this fix has only swept the real issue under the carpet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
SVN Revision 933 should be more resilient to problems with orbit number computation.
The original bug was correct in that zero was a problematic value for well behaved TLE's. A zero orbit number would underflow to a large unsigned long value. The watchdog time would catch it. Then it would try to create a track and the first point had an orbit number greater than the max_orbit and the loop would edit with no values.
The validation of the fix raised a second bug that for some TLE's the orbit_number was not monotonic. To handle these anomalous cases, the starting time now looks for when the orbit number is not start_orbit rather than less. Also the termination looks for a time that is not between the start and stop rather than after the stop.
As for the interpretation of the orbit number, it would be good to get a firm reference for interpreting the orbit number. For instance does radioskaf-b get it's orbit number from the launch of ISS, the launch of the progress module that carried it, the launch from ISS, or some other time. Satellite debris fields might also yield some insight. If radioscaf-b has a smaller orbit number than the progress capsule that launched it at some time or ISS then a negative value might e interpreted as being the original satellite from the international designation.
As for the signed versus unsigned question, either provides more range than the space allocated in the TLE format. The older code used signed and unsigned in different places. Either is fine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This would appear to be an artifact of the orbit field being an unsigned long and looking at a single orbit of ground track.
Can you please confirm that you only want to look at the ground track of one orbit? If not I need to find another issue.
Falcon R/B 39116 seems to be showing the same symptoms with tle dated 13069.90479075.
Never mind the one ground track. This appears to be an issue no matter how many ground tracks.
It appears that this is an issue from having sat_t->orbit being an unsigned long.
SVN commit 914 fixes this issue.
sat_t->orbit was of type unsigned long as were other orbit counts in gtk-sat-map-groundtrack.c.
These were made merely longs. A signed long (32-bit) gives us space for several thousand years in low earth orbit. (2^31/365/18).
I think we should give this some more thoughts. Clearly, the issue is in the ground track calculation algorithm and as far as I can see nothing has been fixed there. Changing the orbit counts to signed integer is a bad idea since negative counts have no physical meaning. I'm afraid this fix has only swept the real issue under the carpet.
SVN Revision 933 should be more resilient to problems with orbit number computation.
The original bug was correct in that zero was a problematic value for well behaved TLE's. A zero orbit number would underflow to a large unsigned long value. The watchdog time would catch it. Then it would try to create a track and the first point had an orbit number greater than the max_orbit and the loop would edit with no values.
The validation of the fix raised a second bug that for some TLE's the orbit_number was not monotonic. To handle these anomalous cases, the starting time now looks for when the orbit number is not start_orbit rather than less. Also the termination looks for a time that is not between the start and stop rather than after the stop.
As for the interpretation of the orbit number, it would be good to get a firm reference for interpreting the orbit number. For instance does radioskaf-b get it's orbit number from the launch of ISS, the launch of the progress module that carried it, the launch from ISS, or some other time. Satellite debris fields might also yield some insight. If radioscaf-b has a smaller orbit number than the progress capsule that launched it at some time or ISS then a negative value might e interpreted as being the original satellite from the international designation.
As for the signed versus unsigned question, either provides more range than the space allocated in the TLE format. The older code used signed and unsigned in different places. Either is fine.