This post is supposed to be a proposal for a way forward towards more auto-scheduling functionality in our Network. This is building on top of the existing general discussion.
- @cgbsat and @kerel have been developing a nice tool that can be used to schedule observations automatically on a station. The repository can be found here: auto-scheduler and should be considered in active development
- Various minor updates have been pushed to our Network API in order to facilitate the needs of the auto-scheduler
- Over the past week we pushed some updates on SatNOGS DB to include support for drifted frequencies (so we can eliminate the need for additional “drifted” transmitters and consolidate our information).
- @fredy and @kerel have been working on refactoring the prediction_pass code on Network for consistency and implementing an optimization (WIP) for scheduling only for the duration above station minimum horizon (this is expected to greatly impact our stations availability and enhance utilization)
- A new field will be added in station model of Network stations named “Target Utilization”. Essentially it will be a value (from 0 to 100) that a station owner can edit to signal other users and auto-scheduling algorithms the desired utilization of the station over a period of time (initially that should be calculated against 24h?). More discussion on this in this issue.
- A scheduling endpoint for the API should be created to ease the work of autoscheduling tools but gated with API keys. See issue for more discussion.
- We need to have a way to consistently distribute TLEs from Network to be used for auto-scheduling purposes. Again an API-key gated solution should enable us to do so in a way that we respect the license of those TLEs.
- Lot’s of testing for the prioritization factors and implementation of them should be done. This work is already underway but more testing and feedback is always welcome.
Other related work
- We are moving ahead with changes to Transmitter model in DB to enable one-to-many relations for Transmitter<->Modes and Transmitter<->Demodulators. This will further our DB data consistency and de-duplicate a lot of Transmitters. Obviously this will require changes to Network and Client too.
- We are investigating the implementation aspects of introducing a Satellite Unique IDentifier (SUID) for usage as a primary key for satellites vs the current usage of NORAD IDs.
I believe that regardless of the decision around the auto-scheduling actor (client? network? stand-alone service?) the above mentioned steps can be reused and are impactful. This is supposed to be a gradual work-in-progress vs sudden system-wide change. Please provide feedback and let’s keep the work going!