Hello all,
During Hamvention 2018 a bunch of SatNOGS contributors met together to brainstorm about the best way forward towards a completely automated scheduling system. Although many directions have been proposed in the past, @Acinonyx spearheaded a new radical direction based on some assumptions and observing the scheduling work done by our regular observers, mainly: @BOCTOK-1, @Saliyath, @gpanag95, @SV1RVP, and others.
Disclaimer
This is a draft proposal and by no means a done-deal direction for SatNOGS Network and Client components. We are inviting as much input and criticism to this proposal as possible to help figure out which is the best way forward for the scheduling Architecture.
Assumptions - Specs
- The scheduling process needs to be fully automated without a manual intervention
- Manual observations need to be accommodated it too (observers would still want specific results)
- The number of stations in the Network will only keep growing
- Not all observations are equally important
- Ground stations should be kept busy 100% of the time (unless the owner does not want that)
- Network and Client resources should be used optimally
Existing model
Today the scheduling is happening as a manual process with the Network constantly predicting “passes” of transmitters for available ground stations. Note how I am not saying “passes of satellites”. It is critical to understand that the basic node of statistics/predictions/passes/observations is the “Transmitter” (or transceiver if the uplink is enabled) as a stored combination of frequency(-ies)/modulation/encoding and information.
Proposed concept
The core concept of the proposed scheduling and observations architecture is the following:
- Based on a number of prioritization factors (see below) the network maintains a prioritized list of transmitters (thus satellites too) tailored for each station at all times (regular updates are expected in that list).
- The client constantly queries the Network for an updated version of that list (even during an observation!), and goes through it to calculate if a transmitter (thus satellite) is having a pass. Going through the list in a sequential manner ensures we meet the prioritization criteria.
- The appropriate Gnuradio flowgraphs are spawned for the duration of this favorable (for the transmitter/satellite) period and results are captured/produced (WF, Audio, Decoded data)
- All results are posted back to Network, creating a new observation in the process of doing so. (Note how there is no “pending” observation scheduled like we are doing now on the Network, waiting for results)
In practice, the client will be going through the tailored for it list fetched from the Network and one by one checking if the pass is feasible (above the horizon), if not move to the next priority till it is feasible and will spawn an observation.
Prioritization factors
Many different factors have to be taken into account to compile the per-station transmitter list. I will try to list them here not necessarily as a prioritized list 
:
- Frequency capabilities of the station (obviously we will not be serving to a station a list with transmitters it cannot monitor)
- Preferences of the station owner (self-declared by the owner through Network, or Client?), like a “must monitor” satellite list
- Statistics of transmitter quality/success rates based on previous observations (but we would also want to monitor some “dead” ones every once in a while)
- Distribution of observational load, and deduplication among stations (let’s show why GS Networks are really unparalleled as an infrastructure!)
- Post-launch TLE and Freq determination priorities (when new satellites are deployed or something changes in existing ones)
- Manual opt-in scheduling by observers, will be dealt as essential a change in priorities for a station
Note: the Network is not agnostic when it comes to what it is expecting from Stations/Clients to do. As we will be compiling the prioritized lists on the Network, it will be able to calculate exactly what it will expect from Clients on Stations. The key difference is that it does not have to calculate it, unless observers want to monitor upcoming passes or schedule manual ones (by essentially changing priorities ). This might seem like a small difference but for the scale of things SatNOGS Network is going for this will be critical.
Transitional way forward
Obviously, there will be a lot of fundamental work and testing that needs to happen in order for us to transition towards any auto-scheduling approach (let alone this radical one!). We are committed though, to a smooth transition without any major hiccups on the Network and overall operations of SatNOGS. We will be starting with some key changes that need to happen around statistics (moving towards transmitters which are rated and not satellites, based on passes) that will need to happen regardless the decided end-model for automated scheduling. Keep an eye for those in the DB and Network in the coming weeks.
Open Questions
Please post here any questions, criticism, suggestions etc you have regarding this proposed approach so we can collectivelly form it to be the best way forward for SatNOGS.