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?

Thanks

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: https://gitlab.com/librespacefoundation/satnogs/satnogs-auto-scheduler/tree/master

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

2 Likes

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? ./schedule_single_station.py -s 223 -f -P /home/pi/satnogs-auto-scheduler/priorities_223.txt -d 24 -w 600 -n -r 5 -l INFO

Thanks

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: ./schedule_single_station.py -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

2 Likes