Towards auto scheduling

Hello all,

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)

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:

  1. The maximum pass elevation (scaling as elevation/90 degrees, so priority 0.70 for a 63 deg pass).
  2. 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.

1 Like

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:

  1. 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.
  2. 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.

I would think along with the must monitor list there would be a priority number that says which has priority during such problems in number 2.

This is exactly what I would want. For example, I would want VHF priority of the following:

  1. ISS Voice (R2+R3)
  2. AO-92
  3. AO-91
  4. AO-85
  5. NO-84 digi
  6. All other satnogs observations (etc.)

Etc. The problem with overlapping observations is no problem

1 Like

So, maybe the priority should be set to transmitters and not in satellites.


Doesn’t selection of transmitter automatically give you the satellite?

Yes, each transmitter has a unique identifier and belongs to only one satellite.

thanks, I withdraw my first comment.

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.

1 Like

Instead of priority, I can also think of a system based on points. An example:
Input Parameters:

  • transmitter success rate Rsuccess (0.0 to 1.0)
    –> +20 * Rsuccess
  • maximum pass elevation Relevation (0.0 to 1.0, =elevation/90°)
    –> +10 * Rpass
  • user-defined transmitter points Puser (-500 to +500, default: 0)
    –> +Puser
  • network-wide transmitter points Pnetwork (-50 to +50, , default: 0)
    –> +Pnetwork

The score can be calculated with:

score = Puser + Pnetwork + 20 * Rsuccess + 10 * Rpass

The passes with the highest positive score get scheduled.

Some examples:

  • Users define must-have transmitters with Puser = +100
  • Network defines must-have transmitters with Pnetwork = +50
  • Normal transmitters have Puser = 0, Pnetwork = 0
  • Network defines blacklisted transmitters with Pnetwork = -50
  • Users define blacklisted transmitters with Puser = -100

Further examples:

  • User blacklists a transmitter for normal operation, but allows network to override this:
    Puser = -50
  • User wants sat1 and sat2 both as must-have, but with different priorities:
    Puser (sat1)= +100 ; Puser(sat2) = +200

who or what is going to vet the sats that auto schedule?

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.

1 Like

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.

Also you could just say to not use the auto scheduler on your station. (Utilization of 0)

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.

1 Like

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!

1 Like