You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the parameters for the Orbit class is the time period of the orbit. This is used to help filter the determined orbit breaks such that only the real breaks are kept. However, over a long data run, the satellite orbit period changes and can change enough that the orbit determination no longer works. One fix is to only have satellite data runs limited to a couple years, but that is avoiding the issue.
Plan:
Modify the orbits class to store a running series of time differences between orbits. e.g. the difference between the start of each orbit
Cleaning routines or other reasons can produce data sets that always produce incomplete orbit data. This requires thought.
Stored periods need to be heavily filtered themselves.
Changes in applied orbital period need to be slow
Alternative: support accepting a list of dates and periods, and the class will use the closest past value when applying the orbits
This is simpler and has less chance of doing funny things like the auto determination method
The cost of the simpler method is more work by the user
Ideal situation requires no input period whatsoever
The text was updated successfully, but these errors were encountered:
One of the parameters for the Orbit class is the time period of the orbit. This is used to help filter the determined orbit breaks such that only the real breaks are kept. However, over a long data run, the satellite orbit period changes and can change enough that the orbit determination no longer works. One fix is to only have satellite data runs limited to a couple years, but that is avoiding the issue.
Plan:
Modify the orbits class to store a running series of time differences between orbits. e.g. the difference between the start of each orbit
Cleaning routines or other reasons can produce data sets that always produce incomplete orbit data. This requires thought.
Stored periods need to be heavily filtered themselves.
Changes in applied orbital period need to be slow
Alternative: support accepting a list of dates and periods, and the class will use the closest past value when applying the orbits
This is simpler and has less chance of doing funny things like the auto determination method
The cost of the simpler method is more work by the user
Ideal situation requires no input period whatsoever
The text was updated successfully, but these errors were encountered: