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.
Updates
@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)
Next Steps
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!
Currently, the auto-scheduler computes passes for all transmitters that fall within the frequency range of the antennas of the ground station. Each pass is then given a priority (from 0.0 to 1.0) based on two properties:
The maximum pass elevation (scaling as elevation/90 degrees, so priority 0.70 for a 63 deg pass).
The transmitter success rate
These priority factors are multiplied and all passes are then sorted on this total factor. The scheduler will pick the pass with the highest priority, and then go down the sorted list and schedule subsequent passes which do not overlap with any of the previously scheduled (or marked to be scheduled) passes.
This approach works well but has the disadvantage that for a satellite with multiple transmitters the scheduler will always use the transmitter with the highest success rate.
Another downside is that no overlap is allowed, so if the second highest priority pass has 10 seconds of overlap with the highest priority pass, it will not be scheduled.
I’d be interested in ideas how to improve on these situations.
Can priority be manually defined? For example, if I want ALL ISS voice passes observed, can I manually tell the autoscheduler that even an 11° ISS Voice pass takes precedent over an 89° AO-92 DUV pass?
I plan to implement functionality to have a user defined “must monitor” list (as @pierros mentioned in the proposed concept post), so you could add your preferred transmitters to that list.
A few points of note though:
Besides a client side “must monitor” list, the auto-scheduler will also query a server side (SatNOGS moderated) priority list. So occasional ISS voice passes could be prioritized there in case of ARISS events.
There may be clashes of passes from satellites on the “must monitor” list. If you have both ISS voice and AO-92 DUV on your list, how would you prefer to have the auto-scheduler choose between the two? Maximum pass elevation? Skip the one which was observed most recent? These are questions I’d be interested in hearing people’s opinions.
Thanks for your input. I’ve added an issue on this and will try to implement this soon. It’s probably also useful to add a black list option as satellites like Fox-1A and UKUBE have very high success rates, and hence will get high priority, but we know they’re no longer operational.
I would assume either the system fir things like NOAA and FSK ones that decode and then the station owners who API Key would be the one requesting the observation.
If the station owners are required to vet passes that are auto scheduled, don;t you think that satnogs will lose a lot of ground stations? Most gs owners have better things to do than vet passes that they are not interested.
As you can see, Most people are slow with vetting the sat passes that they manually schedule. Imagine that they will not vet passes they did not schedule.
hm well it’s easy and simple to vet passes. Plus I normally go thru my stations observations week or so and vet all the unvented ones. Not hard at all.
In the current design, the auto-scheduler is ran by the ground station users, primarily to reduce their workload in scheduling passes that they are interested in. As with manual scheduling, they’d be the ones vetting the observations. You’ll be free to set your station utilization percentage to a low value.
In the future the goal is to use machine learning to vet observations, reducing the human workload even further. Or even better, have all observations automatically decode data.
I like the proposals. I don’t mind vetting others observations, either - provided they fall into a reasonable workload (and I assuming that the utilization setting will help station owners fine-tune their workload).
The only concern about non-station owners auto scheduling observations that are expected to be vetted by the station owner is that sometimes the station owner will not be familiar with the “signature” of the transmitter. So, for example, the observation of a Fox satellite could mistakenly be vetted as good by somebody observing CAS telemetry or CW in the waterfall.
Not a huge deal, but a concern nonetheless.
This new feature is bound to be my favorite aspect of the network. Can’t wait!
