I use that command and I get nothing (just a new command prompt).
Isn’t that directory just the one you created for the auto scheduler, anyway? The way this step is written, I though that I had to copy that file from the auto scheduler directory into some system folder called “.env”, but I can’t find it anywhere.
–Roy
K3RLD
Ok, the fact that you dont get anything, just a command prompt, means that you do not have that file.
(Its a file, not a directory).
You should clone the auto-scheduler files into a directory of its own, not into any system directories.
Edit. Do the command ls -la and you can see the full files, even the hidden . files.
I DID clone the auto scheduler. Where is the .env file located? I only have the “env-dist” file.
ls -la shows no additional (hidden) files in the auto-schedular folder.
The .env file is in the same directory as the other files.
Here is whats in mine.
~/satnogs-auto-scheduler $ ls -la
total 120
drwxr-xr-x 3 pi pi 4096 May 13 17:52 .
drwxr-xr-x. 6 pi pi 4096 May 14 13:45 …
-rw-r–r-- 1 pi pi 208 May 13 17:52 .env
-rw-r–r-- 1 pi pi 185 May 11 08:46 env-dist
drwxr-xr-x 8 pi pi 4096 May 11 08:46 .git
-rw-r–r-- 1 pi pi 79 May 11 08:46 .gitignore
-rw-r–r-- 1 pi pi 33893 May 11 08:46 LICENSE
-rw-r–r-- 1 pi pi 708 May 11 08:46 README.md
-rw-r–r-- 1 pi pi 61 May 11 08:46 requirements.txt
-rwxr-xr-x 1 pi pi 15199 May 11 08:46 schedule_single_station.py
-rw-r–r-- 1 pi pi 430 May 11 08:46 settings.py
-rw-r–r-- 1 pi pi 530 May 11 08:49 settings.pyc
-rw-r–r-- 1 pi pi 932 May 11 08:46 setup.cfg
-rw-r–r-- 1 pi pi 10665 May 11 08:46 utils.py
-rw-r–r-- 1 pi pi 9318 May 11 08:49 utils.pyc
EDIT. Doing a more env-dist will provide the help you need I think
more env-dist
NETWORK_USERNAME = ‘’
NETWORK_PASSWORD = ‘’
AHHHHHH.
So what I want to do is “cp env-dist .env”, and then put in my network credentials?
I understood that command to be "copy the env-dist file data (or file itself) into an existing file/folder called “.env”.
So .env never actually came with the clone, you have to create it yourself, no?
Correct. Do the cp command and copy it over.
Then edit the .env file.
.env never came with the rest of the files no.
The README file contains the steps.
Hmm. My first attempt at autoscheduling and I got an error that it "could not convert string to float: ’ qW5Nxxxxxxxxxxxxxxxx’ (this is the large string in the 25544 ISS SSTV transmitter line. Is there a description of what these lines decode to?
Yes, there is in the help:
See the line:
-P PRIORITIES, --priorities PRIORITIES
File with transmitter priorities. Should have columns
of the form |NORAD priority UUID| like |43017 0.9
KgazZMKEa74VnquqXLwAvD|. Priority is fractional, one
transmitter per line.
So it should have:
25544 1.0 qW5N27QuSrN2JMasbNiUhR
That’s why it’s complaining about “could not convert string to float” as you may have forgotten the priority setting.
I DID forget the priority number, but I meant to say the UUID - where can I find that? I’m not sure how that relates to specific transmitters. Some of the transmitters are obvious (for example, the ISS SSTV one), but others are not (for example the difference between the region downlinks on 145.800, both saying “FM” - think…)
Thanks!
–Roy
[edit]
man, I don’t know whats going on (I’ll have to look at this later), but I just got it to run - but it only scheduled 2 passes, one of which is a satellite not even in my priority list…)
Yeah, other than the station number, I found the other parameters are largely ignored. If you figure out how to get them working, please make a post.
EDIT. I have not put a ‘issue’ in because I know the whole auto-scheduling thing is due for an overhaul.
To find the UUID’s you can hover your mouse over the information button for transmitters on the SatNOGS database. If you click it you can paste it later on.
For ISS, the SSTV transmitter is at the bottom of the page at https://db.satnogs.org/satellite/25544/
However, if you’ve already ran the auto-scheduler once, then all the transmitter information is present in /tmp/cache/transmitters_<ground_station_id>.txt. So you can run something like:
grep -e "25544" transmitters_39.txt to find the active transmitters ont he ISS.
25544 EvtcWByczLm3LejfbGt8pS 17 48 276 FMN
25544 PjfcFc4PZ8M8n3thuyA6x9 1 28 1552 FM
25544 pQRPwTWqQr7unDav5Mz4pG 58 109 187 FM
25544 qW5N27QuSrN2JMasbNiUhR 62 7214 11625 SSTV
25544 yMufCB474YJ4YRdDepfMUk 49 1675 3415 FM
25544 ZJxCeQmih9zDfYNVrB4wRN 54 3591 6592 AFSK1k2
The columns here are NORAD_CAT_ID, UUID, success rate (percentage), number of succesfull observations, number of total observations, transmitter mode.
Which other parameters are largely ignored? They should all be functional, but I admit that the logic of how they influence each other is not always obvious.
Please do submit issues. The network side scheduling implementation will take a while, and any input you have on the station side scheduling may be very useful for the future.
Thanks, Everybody! Still not working completely, but I think my legacy login info is wrong. I’ll have to do some note checking to be sure I’m using the correct credentials…
–Roy
K3RLD
The -m MIN_HORIZON is the one I have failed to get working yet.
I made some recent changes to that. Do you have the latest version?
The -m MIN_HORIZON is odd to me as well. Looking at the code in line 255 in schedule_single_station, there is:
minimum_altitude = min(ground_station['min_horizon'], min_horizon_arg)
So the minimum_altitude is the lowest considering the minimum horizon passed value and the minimum horizon for the station. The problem is that if the station has a low horizon (example, 5°), and the user likes to schedule good passes (for example, looking for those reaching a minimum horizon of 30°), well, the logic above will discard the passed value for the minimum horizon. That was how I intended to use this parameter. For the moment, I do not know how to schedule only good passes.
Good point. I think I got the logic messed up and instead the -m should be used instead of the ground station value, regardless whether it is smaller or larger. Would that be how you would use it as well?
Yes. Station minimum might be lower for anyone using the station, but for the auto scheduler, I like to only have good passes.
I expected the -m setting to allow me to set a higher minimum so I can get good data.
I fixed, or at least I think I fixed, the problem with the minimum horizon settings.
I also changed how the auto-scheduler deals with stations which are in testing mode. Previously it scheduled observations on stations in testing mode. With the latest commits, it no longer does this and it needs to be explicitly enabled when running the auto-scheduler (use the -T argument).
By disabling scheduling in testing mode, users can remotely prevent the auto-scheduler from scheduling new passes should the station have troubles.
I have found this feature useful, as I have a hourly cronjob scheduling new observations, but when away from home, I have no way to stop the auto-scheduler if the station has a problem. By putting the station in testing mode remotely, no new observations will be scheduled.
Great. Thanks for the work on the update.
Do I need to pull the latest down, or is it all done on the back end?