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?
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.
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.
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, 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.
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.
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.
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?
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…
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.
