It hasn’t been working for about 2 days (see log below). Is anyone else having this problem?
satnogs_client_1 | Cloning into 'gr-satellites'...
auto-scheduler_1 | Update satellites, transmitters and TLEs:
auto-scheduler_1 | Download satellite information from SatNOGS DB...
auto-scheduler_1 | Download list of active transmitters between 137 and 152 MHz from SatNOGS DB...
auto-scheduler_1 | Download list of active transmitters between 400 and 470 MHz from SatNOGS DB...
auto-scheduler_1 | Download TLEs from SatNOGS DB...
auto-scheduler_1 | Download transmitter statistics from SatNOGS Network (this will take some minutes)...
auto-scheduler_1 | Filter transmitters based on ground station capability.
auto-scheduler_1 | Search passes for 0 satellites:
auto-scheduler_1 | Download list of scheduled passes from SatNOGS Network...
auto-scheduler_1 | Found 1 scheduled passes between 2026-09-01 07:15:29 and 2026-09-01 10:15:29 on ground station 3689.
auto-scheduler_1 | 1 passes selected out of 0, 440 s out of 440 s at 100.000% efficiency
auto-scheduler_1 | GS | Sch | NORAD | Start time | End time | Duration | AzR El AzS | Priority | Transmitter UUID | Mode | Freq | Satellite name
auto-scheduler_1 | | misuse |
auto-scheduler_1 | Traceback (most recent call last):
auto-scheduler_1 | File "/usr/local/bin/schedule_single_station.py", line 8, in <module>
auto-scheduler_1 | sys.exit(main())
auto-scheduler_1 | ^^^^^^
auto-scheduler_1 | File "/usr/local/lib/python3.11/site-packages/auto_scheduler/cli/schedule_single_station.py", line 338, in main
auto-scheduler_1 | schedule_single_station(
auto-scheduler_1 | File "/usr/local/lib/python3.11/site-packages/auto_scheduler/cli/schedule_single_station.py", line 483, in schedule_single_station
auto-scheduler_1 | print_scheduledpass_summary(
auto-scheduler_1 | File "/usr/local/lib/python3.11/site-packages/auto_scheduler/utils.py", line 172, in print_scheduledpass_summary
auto-scheduler_1 | sat_entry = satellites_catalog[int(satpass["satellite"]["id"])]
auto-scheduler_1 | ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
auto-scheduler_1 | KeyError: 69015
My docker-compose.yml:
auto-scheduler:
# image: librespace/satnogs-auto-scheduler:master
image: registry.gitlab.com/librespacefoundation/satnogs/satnogs-auto-scheduler/satnogs-auto-scheduler:master
user: '999'
#command: 'bash -c "echo Lol; sleep 3600;"'
command: 'bash -c "while true; do sleep 30; schedule_single_station.py -s $$SATNOGS_STATION_ID $$AUTO_SCHEDULER_EXTRA; sleep 3600; done"'
#command: "schedule_single_station.py --help"
#command: "cat /opt/mb/mbPrio.txt"
read_only: true
env_file:
- ./station.env
environment:
CACHE_DIR: '/var/lib/satnogs-client/.cache/auto-scheduler'
depends_on:
- satnogs_client
volumes:
- type: 'tmpfs'
target: '/tmp'
- type: 'volume'
source: 'satnogs-client'
target: '/var/lib/satnogs-client'
- ./mbOpt:/opt/mb
restart: unless-stopped # du not use with exiting client as this will just loop
stop_grace_period: 1s
in the mean time, there has been a network update, that changed some API-responses. There is an update to auto-scheduler aswell. You’d need to take the latest version of it.
Might I aks where the “update” hides ? I installed the auto_scheduler in the new (.venv) environment and mine, not a docker installation, also crashes
Found 4 scheduled passes between 2026-09-07 09:20:30 and 2026-09-07 13:20:30 on ground station 1441.4 passes selected out of 0, 2716 s out of 12028 s at 22.581% efficiencyGS | Sch | NORAD | Start time | End time | Duration | AzR El AzS | Priority | Transmitter UUID | Mode | Freq | Satellite name| misuse |Traceback (most recent call last):File “/home/hacker2/auto-scheduler/.venv/bin/schedule_single_station”, line 8, insys.exit(main())File “/home/hacker2/auto-scheduler/.venv/lib/python3.10/site-packages/auto_scheduler/cli/schedule_single_station.py”, line 334, in mainschedule_single_station(File “/home/hacker2/auto-scheduler/.venv/lib/python3.10/site-packages/auto_scheduler/cli/schedule_single_station.py”, line 505, in schedule_single_stationprint_scheduledpass_summary(File “/home/hacker2/auto-scheduler/.venv/lib/python3.10/site-packages/auto_scheduler/utils.py”, line 164, in print_scheduledpass_summarysat_entry = satellites_catalog[int(satpass[“satellite”][“id”])]KeyError: 98405
Thanks Jan, Max
Installed in the 3.11 .venv
Ran the setup, which wrote a .env file in ~/
Moved that to ~/satnogs (which I created myself ) after which I needed to add --flush-cache to my schedule command to actually schedule instead of getting "No appropriate passes found for scheduling. "
-U, --allow-unavailable
Allow scheduling on stations which are in unavailable
mode [default: False]
This has to do with the fact that the latest db/network changed the testing behavior. testing is now also allowing others to create obs on your testing station.
Only with un-checking testing and available will give you a similar behavior as before.
This only wasn’t supported by the auto-scheduler and therefor the update.
(.venv) hacker2@hacker2:~$ schedule_single_station -s 3442 -T -d 4 --flush-cache
Flushing cache.
Update satellites, transmitters and TLEs:
Download satellite information from SatNOGS DB...
Download list of active transmitters between 2100 and 2310 MHz from SatNOGS DB...
Download TLEs from SatNOGS DB...
Download transmitter statistics from SatNOGS Network (this will take some minutes)...
Filter transmitters based on ground station capability.
Download list of scheduled passes from SatNOGS Network...
Found 0 scheduled passes between 2026-09-07 18:05:37+00:00 and 2026-09-07 22:05:37+00:00 on ground station 3442.
Search passes for 812 transmitters across 686 satellites:
100%|[00:05<00:00, 154.06it/s]
19 passes selected out of 732, 11576 s out of 14400 s at 80.389% efficiency
I have been troubleshooting 3 Docker stations keeping black till I finally noticed those where in testing before the DB update, and did not automatically switch to “Available” . I have to find my way in the new settings because my “testing” also could mean the station had no antenna. That would be sad for others if they schedule on a station without antenna…
Green is a station that is online, available for scheduling and not in test mode.
Yellow is a station that is online, available for scheduling and in test mode.
Test mode is set when the station owner decides that the station doesn’t perform as it should and needs testing, this could be testing of different configurations, for example different gains, testing of different setups, for example testing different SDRs or Antennas.
An observation that is performed from a station in test mode, is marked as experimental, giving the opportunity to people that are interested in this observation to know that this may not have come from a station that performs the best. For example someone that wants to study/research the performance of a satellite, for better results may avoid using experimental observations.
