At the moment, the tracking config supports a start and end condition (epoch or "visible"), inclusion and exclusion epochs, and a sampling time. Not only is this confusingly complicated, but it's also buggy.
The purpose of this issue is to simply this greatly, and mimic something closer to how it could be used in operations
Requirements
Tracking configurations should be renamed "tracking schedules"
Tracking schedules shall require only a sampling frequency
Tracking schedules may be built by specifying an on/off cadence
Tracking schedules may be built from the visibility of a spacecraft
Tracking schedule builders may have a Handoff configuration, specifying whether they allow for overlapping measurements or not, and if not, whether to stick to this station as long as possible, or whether to hand off as soon as possible.
Build tracking schedules may be exported and reused as is
Test plans
A tracking schedule shall be built from an on/off cadence and exported. The export shall confirm the on/off schedule. The measurement plots shall also be added to the PR for confirmation.
A tracking schedule without an on/off cadence shall be exported and ingested as exported, and confirmed that it produces the same measurement set
Design
To simplify the use of these ground station configurations, we should allow to mix and match a configured tracking schedule to one that needs to be built.
As such, the following configuration should be valid:
Canberra:
schedule:
cadence: !Intermittent
on: 4 h
off: 8 h
hand-off: Eager # Or Greedy, or Overlap
sampling: 1 min
Madrid: # This is a pre-configured because it has strands
strands:
- end: 2023-02-22T22:53:50.928000000 UTC
start: 2023-02-22T20:53:50.928000000 UTC
- end: 2023-02-23T02:53:50.928000000 UTC
start: 2023-02-23T00:53:50.928000000 UTC
sampling: 1 min
In this case, the tracking schedule will be built for Canberra because no strands are defined. If both strands and a schedule are defined, an error is raised.
Algorithm demonstration
For building of strands, a slower but more correct approach will be built. Building requires a trajectory.
For each station, find when the spacecraft elevation is high enough for the station to see it.
Once it does, follow the on/off cadence if specified. Else, follow the sampling info.
Repeat for all stations.
Remove measurements using the handoff configuration: Eager means that the given ground station will hand off as soon as another one is in visibility. Greedy means the opposite. Overlap means that several stations may track at the same time.
High level description
At the moment, the tracking config supports a start and end condition (epoch or "visible"), inclusion and exclusion epochs, and a sampling time. Not only is this confusingly complicated, but it's also buggy.
The purpose of this issue is to simply this greatly, and mimic something closer to how it could be used in operations
Requirements
Handoffconfiguration, specifying whether they allow for overlapping measurements or not, and if not, whether to stick to this station as long as possible, or whether to hand off as soon as possible.Test plans
A tracking schedule shall be built from an on/off cadence and exported. The export shall confirm the on/off schedule. The measurement plots shall also be added to the PR for confirmation.
A tracking schedule without an on/off cadence shall be exported and ingested as exported, and confirmed that it produces the same measurement set
Design
To simplify the use of these ground station configurations, we should allow to mix and match a configured tracking schedule to one that needs to be built.
As such, the following configuration should be valid:
In this case, the tracking schedule will be built for Canberra because no strands are defined. If both strands and a schedule are defined, an error is raised.
Algorithm demonstration
For building of strands, a slower but more correct approach will be built. Building requires a trajectory.
samplinginfo.