Can I schedule passes for my station further in advance?

Our SatNOGS station (#223) is one of the few stations in the mid-Atlantic US region with directional antennas (8X8 on 70 cm, 10X10 on 2 meters). It’s primarily dedicated to SatNOGS but we would also like to use those antennas for our Fox in a Box and NOAA WeFax radios. But antenna control is managed by SatNOGS so it would be helpful to be able to schedule passes for those satellites far in advance so that SatNOGS would point the antennas in the right direction for those receivers to process. Other than the dashboard that only allows scheduling a few days in advance is there another way to schedule passes further out, or maybe permanently?


Jon, WB2MNF sysop for W2MMD

Scheduling passes for more than a few days in advance is a bad idea as the orbital models are not able to reliably predict passes for more than a few days.

1 Like

Thanks. Is there any other way to schedule observations other than thru the GUI? It would be helpful to be able to automate scheduling in some way.

Yes there is. Have a look at the satnogs-auto-scheduler tool:

Thanks - looks very helpful. I have it installed but get a “Failed to schedule the pass at 2020-12-07 02:58:21. Reason: {‘detail’: ‘Invalid token header. No credentials provided.’}” error when trying to schedule. I think I haven’t properly followed the instruction for “Configuration” properly - I edited that file, pasted in the token and saved it in
~/satnogs-auto-scheduler/.env that I created. But the instructions may also mean that I should rename env-dist file to env-dist.env which I also tried and get the same error. Can you help? Thanks.

.env is the right name for the file. Please check again the Netowrk API key/Token that you used. Make sure that there aren’t any blank characters like spaces and that the string is all there. If the API key is right, then probably for some reason .env file is not loaded correctly.

Got it working - thanks


Another question - the scheduler is generally working in that it’s scheduling passes but two parameters don’t seem to be working - using the priorities file and the minimum elevation. I’m getting passes scheduled that aren’t on the priorities list and are below the minimum elevation. Can you see what’s wrong with this command? ./ -s 223 -f -P /home/pi/satnogs-auto-scheduler/priorities_223.txt -d 24 -w 600 -n -r 5 -l INFO


You probably want to add the -f argument
-f, --only-priority Schedule only priority satellites (from -P file)

Without it the scheduler will fill available gaps with other satellites.

Thanks, but the -f argument is in that command (before the -P). I’ve also added a -r 20 parameter that I believe should limit passes starting below 20 degrees elevation, yet passes starting below that limit are being scheduled. Does the order of parameters matter?

Also - the additional satellites not in the priorities_223.txt that are being scheduled are showing with a priority of 1. I’d think that passes from satellites not in the priorities file would have a priority of zero. Might that be a key to what’s not working?

Here’s my current command: ./ -s 223 -d 1.5 -r 20 -m 20 -M 0.5 -P /home/pi/satnogs-auto-scheduler/priorities_223.txt -f -w 600 -n -l INFO

Here’s the output. Only satellite 43137 is in the priorities file.

Thanks for your help.

I see what you mean.

The lines that are being shown there are the passes that are already scheduled (those that have Sch == y and that lack a transmitter mode or satellite name.

Here’s a scheduling run on my system. The satellites that were scheduled here are 42017, 43780 and 43137. The others were already scheduled.

2020-12-09 10:52:05,654 - root - INFO - GS  | Sch | NORAD | Start time          | End time            |  El | Priority | Transmitter UUID       | Mode       | Satellite name 
2020-12-09 10:52:05,654 - root - INFO -  39 |   Y | 42778 | 2020-12-09T10:00:31 | 2020-12-09T10:11:24 |  24 | 1.000000 | 52jVE9w8EnSpF8YFssD5KD |            | 
2020-12-09 10:52:05,654 - root - INFO -  39 |   N | 42017 | 2020-12-09T10:23:01 | 2020-12-09T10:27:46 |  71 | 0.717889 | msnC2ijNNoQ2ECKunbpAkm | BPSK       | NAYIF-1 (EO-88)
2020-12-09 10:52:05,654 - root - INFO -  39 |   Y | 40069 | 2020-12-09T10:29:14 | 2020-12-09T10:40:44 |  10 | 1.000000 | CojkGDaq3u42nRdLdfczng |            | 
2020-12-09 10:52:05,654 - root - INFO -  39 |   N | 43780 | 2020-12-09T10:43:37 | 2020-12-09T10:49:13 |  67 | 0.498778 | Pep4VZvfomiawYMYXwgdwk | BPSK       | MOVE-II
2020-12-09 10:52:05,654 - root - INFO -  39 |   N | 43137 | 2020-12-09T10:51:11 | 2020-12-09T10:55:51 |  58 | 0.567111 | 3rLGJWqj3XZ6Z8vADCRwiW | DUV        | FOX-1D (AO-92)
2020-12-09 10:52:05,655 - root - INFO -  39 |   Y | 40654 | 2020-12-09T11:02:24 | 2020-12-09T11:13:05 |  23 | 1.000000 | FtxHUM8pqr6Ep95RehAouX |            | 
2020-12-09 10:52:05,655 - root - INFO - Scheduling all unscheduled passes listed above.
1 Like

Ahh - I get it! I was misinterpreting the output. The Y passes are those that are already scheduled. The N passes are those that would be added by running this script if the -n parameter wasn’t specified. I got it working now. Thanks so much.

Jon, WB2MNF sysop for W2MMD


Hopefully I can still add to this thread. The auto-scheduler has been working well for the last few months letting us get about 85 observations each day. But a couple of days ago it failed with the error “ValueError: TLE elements are valid for a few weeks around their epoch, but you are asking about a date 586 days from the epoch”. It’s failing on satellite 152 of the 562 that it’s processing, which apparently is from a list that I don’t control. Can someone help?

Known issue. It’s being worked on. looks like it’s affecting everyone.


1 Like

Ah - ok, thanks. Maybe one sat on the list has wacky keps that never causes it to cross over my QTH - something like that geostationary satellite over the middle east…

delete two line element entry for NORAD# 44360 from /tmp/cache/tles_your station number.tle

1 44360U 19036X 19190.11331724 .00010411 00000-0 14372-3 0 9995
2 44360 28.5208 110.8834 0394724 251.5285 104.2023 14.98301624 1939

That worked for me last week and I was able to successfully run the auto scheduler again.

1 Like

Hey, this worked! Thank you!

[edit] What is wrong with that TLE that is corrupting the entire file?


That worked for me too - thanks. I should have been able to figure that out myself - the process was failing on the 152nd satellite and I should have realized that it was a bad entry for that numbered satellite in the keps file. I assume that satellite may be geostationary over some other part of the earth and will never cross my QTH overhead; hence the error in scheduling passes - either that or it’s not in earth orbit or the keps are just flatass wrong.