Automatic scheduling

SatNOGS
1

What, if any, are the plans to allow and implement automatic scheduling of satellite passes?

For my ground stations I’d like to be able to define a list of favourite satellite/transmitter combinations, and have these scheduled automatically, depending on maximum altitude and conflicts with other satellites in this list. The remaining free time can be used for passes scheduled by others. This feature could be implemented as part of the SatNOGS network, but will likely be a significant task, or as a client program, in which case authentication with the network will be required.

How would automatic scheduling fit in with the overall SatNOGS plans?

6 Likes
2

there’s a proposal in the works for this, @pierros is doing to document and put it out there someday soon :slight_smile:

1 Like
3

It would be great to have an API for this to implement own scripts - maybe only as an intermediate solution until there is an implementation inside the network code.

2 Likes
4

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 :wink: :

  • 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.

6 Likes
5

Another thing to realize if that some data have multiple transponders within the bandwidth of an rTLSDR dongle. This means you could technically have a GNURadio Script handling both of them for a single pass.

6

We would have to change the way the scripts are designed.
There is e.g. the possibility to have a generic IQ receiver that feeds samples into a UDP sink and connect as much, as there is CPU power and RAM available, demodulators and decoders (maybe split both up in another UDP connection) using this as source.

P.S.: If you would like to see an example of what I mean: the DSLWP lunar orbiter OOT package is designed like this.

1 Like
7

Thanks for the detailed plan @pierros! This looks like a good and challenging plan to work on.

The creating a new observation on the network by the client after a pass seems quite a different way of running the network and client, and possibly not compatible with the current way of doing things. Would it be an option to use an intermediate approach where the client schedules a set of observations based on the priority list and reserves these on the network (set them to a pending state)?

1 Like
8

@pierros will it be possible to support a truly mobile station in future ie with a gps module within the scheme of auto scheduling which will calculate the observations based on current location instead of settings in network page.

The new proposal makes me think it might be possible as the scheduling will client initiated.

9

“Prioritization factors”

Without going into details of a proof of concept I’m toying around with, let’s think of automatic scheduling via network.satnogs.org as a small part of the entire SatNOGS ecosystem, and imagine the scenario where the following are true:

  • overriding of priorities and manual observation scheduling is always available, as @pierros already proposed
  • decoded frames from network.satnogs.org are making it to db.satnogs.org
  • frames from db.satnogs.org are decoded into a time-series database warehouse for consumption and visualization
  • said time-series database should be assumed to have irregular time series data because of all of the factors involved in collecting this data (in other words, we can’t assume today that we expect a frame of data from satellite X to arrive once an hour… and this bullet point is the problem I propose we solve given the previous bullet points are already implemented)

Now, let me propose that our end goal be the regular collection of data, as frequently as possible based on our capabilities, telemetry forwarder contributions, and network. Regular, and frequent. Consistency & regularity trumps frequency (1 data point every 4 hours is better than 1 data point at 1 hour, then one at 8, then one at 9, then one at 20). We would take what would today be an irregular time series data and try to make it regular through automation.

In my scenario above we would have the data we need to calculate what transmitters to collect from next - but it would be calculated based on the results that end up in the data warehouse, trying to create a consistent stream of data (based on our capabilities and the satellites up there). This way, the results are what matter.

And, since we focus on the results at the end, our automation would account for the data we are collecting through other means outside of network.satnogs.org. (we have over 18.6 million frames in db.satnogs.org today and over 193,000 observations in network.satnogs.org) Today, we have no control over the satellites that are focused on for users contributing to db.satnogs.org with telemetry forwarders… we may be able to influence them socially but let’s assume they are a fixed value. There are roughly 150 contributors providing decoded data for some 100 satellites. Some of the satellites we would never touch with the network automation because we already get enough data elsewhere (let’s say STRAND-1). Or, maybe it becomes the case that we have seen good data for STRAND-1 consistently every 4 hours and suddenly it has been 5 hours without data, if it is possible for the network to fit that in to fill in the gap then we should do it, and this would be an automated process.

(take “4 hours” and “5 hours” as a very rough example - I haven’t put any real calculations into this and it very well may be that our expectations would be “once a day” per satellite… and this also depends on the network growth meeting or exceeding the growth of transmitters out there)

Anyway - I still think the “prioritized list” method is a good approach to take, and maybe this bigger picture method becomes a v3, I just want us to take a step back, look at the end result (data), and work backward from there to see what works.

In this scenario, a “prioritized list” becomes less of a list for the individual ground stations to pick from, and more of a scheduling change between “1 frame every 24 hours” for one satellite vs “1 frame every 4 hours” for another… Now, this puts the onus of scheduling back on the network, but if we are to think at scale 5-10 years from now the results would be more consistent.

Cheers!

5 Likes
10

One part of the proposed concept for automatic scheduling involves the local scheduling of observations.

A first step for this is imho to allow local scheduling in the client.
If satnogs-client provides a local interface which offers the already scheduled observations (in form of start and end time) and allows the creation of new scheduled observations, a local service could perform the long-wanted auto-scheduling (e.g. based on cgbsat/auto-scheduler, and implementing priorization ideas from above).
Observations created via network would be added to the local list of scheduled observations as currently by fetching the list of network-scheduled observations.

What changes/implementation steps would be required to allow local scheduling by a local service with the current client architecture?

11

FWIW that link is a 404 now, or it’s a private repo.

12

You’re right, with the switch over of the repository to the LSF projects the subsequent fork became private. I’ve fixed that. However, use https://gitlab.com/librespacefoundation/satnogs/satnogs-auto-scheduler instead.

3 Likes
13

Hi,

I did find useful to filter automatic pass schedule by satisfying an Az window (during rise or set) on a given pass in order to avoid either known obstacles or antenna pattern known factors leading to a bad or null pass.

i.e.
specifying 345-015 would only schedule passes rising or setting at Az between 345 and 015
specifying 015-360 will skip all passes rising or setting between 000 and 015
specifying 180-045 will avoid all passes rising or setting between 045 and 180
… and so on

In order to accomplish that I did a minor modification to both utils.py and schedule_single_station.py so all eligible passes by all the other criterias established by the program receives a final filtering based on the window definition (if not defined defaults to let all passes in the range 000-360 to pass).

I don’t think I have permission to update the git of the project and I doubt if this modification is general enough to be applied to the main branch, but anyone is welcomed to grab it from my git

73 de Pedro, LU7DID

2 Likes
14

Hi Pedro,

This is indeed functionality that we would need in the future, though currently we’ve not thought much about how to implement this. It certainly is something that we can test out with the auto-scheduler.

Feel free to submit merge requests on the auto-scheduler. You’ll have to fork the gitlab repository at https://gitlab.com/librespacefoundation/satnogs/satnogs-auto-scheduler, and make your changes in a local branch which you can push towards a branch in your gitlab repository. From there you can submit a merge request towards the master branch at librespacefoundation.

1 Like
15

Thanks for your merge request @lu7did!

Specifying a custom horizon is a good idea, but it needs some further thinking. Specifically how we deal with azimuth, as well as altitude.

This plot tries to capture my thinking of specifying azimuth/altitude wedges of the polar plot that need to be avoided for scheduling. The orange wedges an example of parts of the sky that would need to be avoided.

A few questions that arise from this:

  • What granularity in azimuth and altitude is sufficient? Here I’m using 30 degrees. Is that sufficient?
  • How do we specify these for each user? An additional file that lists blocked ranges? (e.g. one per line like 135-180, 0-30 for blocking azimuth 130 to 180, altitude 0 to 30)
  • How do we implement the azimuth/elevation checking? Right now the pass is computed for above a certain elevation. With a custom horizon we need to actually compute more points along the pass to check when the satellite is inside or outside blocked wedges.

I’d be interested to hear ideas about this.

polar

16

Hi,

Regarding your questions @cgbsat.

The intervention I did works for my specific configuration. I do have the HF directional on the same rotor than the two VHF/UHF directionals, it’s an azimuth rotor. For other activities at my shack regarding WSPR/FT8 monitoring and reporting the HF antenna must point North, I can turn it manually for some experiment but I don’t have enabled an auto control of the rotor.

I don’t have, and I never had in some 40 years of satellite work, an elevation rotor. With the kind of directivity achieved with a Yagui antenna it’s an overkill; however I always tilt my antennas 30-35 degrees from the horizontal; which in most cases covers elevations between 3-5 and 65-70 degrees. Passes above 70 degrees are rare and the flyover is brief. Never bothered me much nor prevented any QSO or satellite acquisition. With this criteria in mind you don’t need to segment much your receiving areas, all of them are located in the outer circle of your graph.

Now, for the fixed azimuth part, due North for me means I can get at least two very good half passages per day per satellite; as the SatNOGS purpose is to detect if the satellite is alive or not and eventually get some telemetry out of it, half a good pass is larger than a full marginal pass most of the time. At the same time half the passes from the day, at my location are Northbound and half Southbound, so pointing fixed to the North (or whatever azimuth) it means half the time I will be catching the satellite right after AOS and half the time right before LOS.

Current elevation configuration I believe it’s more suitable to improve satellite efficiency by reducing relatively low SNR parts of the passes and freeing the receiver to other passes in between, it helps to get rid of low el passes that really are priceless for DX but of little or none leverage in SATNOGS, they really required a LCP/RCP antenna to be useful as well.

As per the configuration, clearly is not satellite specific.

At VHF/UHF 30 degrees is good enough as a resolution IMHO.

It’s clearly station unique as you try to deal with antenna configuration, and even not being my case, with blocking signal terrrain or man made features at the neighboor.

At some point it’s an antenna specific feature, if I have an omni in VHF and a directional in UHF that would be clearly the case, and I would like to schedule one window set for one antenna and other for the rest.

73 de Pedro, LU7DID

17

Thanks for the diagram and suggestion @cgbsat!

I think that custom horizon should be specified on the network directly as an edit for each station. We then store them in the Station Model and expose them on our APIs too.
A UI should be created to do that, and your diagram gave me some ideas around it.

We should keep that discussion about this in this relevant issue:

Regarding adding this functionality on auto-scheduler I would strongly advise against it. We should keep auto-scheduler as “naive” as possible, slave to all settings that are coming from network/clients/stations.

Ultimately auto-scheduler code will be refactored to be transmitter-first and not station-first as it is right now. (waiting for the scheduling API from @fredy soon!)

my 2 cents

2 Likes
18

Not sure I’m following you.

Regarding adding this functionality on auto-scheduler I would strongly advise against it. We should keep auto-scheduler as “naive” as possible, slave to all settings that are coming from network/clients/stations.

I’m not sure if this is comment is related to an elevation filtering or an azimuth filtering.

Today there is no way for the network stations (nor clients for that matter) to filter, this is to address local terrain and operational azimuth restrictions conditions mostly known to the station owner, so I doubt it would make much sense for anybody else to set that. It would be very nice to have this setting but it’s not available to my knowledge.

I do receive scores of observation schedules doomed to fail or yield a marginal outcome because the lack of this function, some setting would be beneficial.

In the other hand the scheduler is something I ran using a legit API, I can not see how an optional parameter which omitted defaults to the nominal behaviour might impact others in any way. I’m talking about a programatical script, not a point & click interface.

Finally, refactoring the autoscheduler to be transmitter first shift the focus from the station owner insterest to the centralized management interest; I would like to schedule observations following my interests while contributing to the overall effort I put my station, time and effort for that and I believe I deserve that. Perhaps both models needs to be preserved to a point.

73 de Pedro, LU7DID

19

The goal is for the user to set the azimuth, but also elevation, restrictions of his/her station on the network. That way other users who schedule passes on that station can use the azimuth and elevation restrictions (custom horizon) as well.

As far as I understand, the feature your are requesting blocks certain azimuths. This is a very specific implementation that may be of use to only a limited number of users. Instead, @fredy (at Custom horizon for ground stations (#630) · Issues · librespacefoundation / SatNOGS / satnogs-network · GitLab) and I (in this thread), suggest to implement a more generic way of handling a custom horizon. As I said earlier, this needs some further thinking on how to implement things.

Implementing a network based scheduler that focuses on transmitters instead of stations has always been the plan; however, the current stand alone station based auto-scheduler was easier to implement and has turned out to be a good testing platform. However, we are now shifting the focus on implementing a network based scheduler. This scheduler will tailor the needs of the SatNOGS organization as a whole, but also of the station owners, in the sense that station owners can provide a list of their priority satellites, which the network based scheduler will take into account when scheduling.

20

That would be great when available, today it’s not. It’s kind of hard to me to understand the full set of tech goals of the system, I’m not part of the development team, the documentation I read just ouline broad, generic and timeless goals.

Beg me pardon, I didn’t request a thing, I just modify the scripts by myself and I always said it’s a feature that perhaps fulfill my needs but nobody else’s; I just followed your advice to fork the scheduler, change it to myself and propose a merge as the best method; if you don’t like the concept why encouraged me to present the merge? Unless there is an equivalent feature from central management it does play the trick for me and if it’s useful to somebody else it’s on gitlab as a fork.

Good to hear, looking forward to the moment station owners has exactly the same set of tools over their stations than central management does, both to manage observations on their own and to look after a reasonable usage of the station resources being performed by others.

73 de Pedro, LU7DID