A few hours ago I created a new SatNOGS station here in Brazil and to my surprise the turnstile/rtlsd V3 setup already gave me two satellite passes with signal!!!
But I realized that apparently the network works with manual scheduling and I even read some things about automatic scheduling but these are things that were published over a year ago and maybe we have new things
As everything is very recent I still have a lot to learn about the network
I have to take into account that I’m dumb at Linux and I have this difficulty
Thanks for contributing with a station, especially in an area that we lack stations/coverage.
The current situation of scheduling automation hasn’t been changed the last year. Currently station owners use auto-scheduler.
The plan is to bring auto-scheduling in Network. The first simple form will work with two priority lists:
The first one will be for each station and will be optional, this will define any preferences that station owner has for observing satellites.
The second one will be for the whole Network and will be used for generic scheduling and for specific events for example deployments, urgent satellite incidents, scheduled transmission (SSTV etc). This is similar on what we manually do today
Unfortunately as we are in an organizing phase of SatNOGS project, is difficult to estimate when this will be ready, but a very rough estimation would be during the next year.
I understand that Linux usage could be a barrier for people, but we are here as community to help everyone. Also for more direct communication, feel free to join our chat rooms.
How wonderful, Fredy, I eagerly await the advancement of the wonderful SatNOGS project (I was amazed by the number of observable satellites and the power of the RPi3 B+)
Currently my setup is not very good because my observation location is very dirty with buildings, but I intend to raise the antenna a little higher and place an LNA+Filter combo.
I will TRY to install the automatic scheduler and keep updates here…thanks in advance for the quick support
8GB should be fine for now. The waterfall/audio/data that are uploaded to network are saved temporarily in the RPi memory until their upload. The only reason to change that is if your upload speed is limited, however in such case it is better to use another storage solution as re-writing the sd-card will damage it sooner or later.
For the other questions around auto-scheduling I’ll bring here @ENSFNM answer from the matrix room:
You go inside the directory (folder) where you have the auto-scheduler installed/downloaded and you type in the command line the command pwd. This will return the path to the current directory which is the of the auto-scheduler.
For the path to the priority list you do the same but you add in the result of the pwd the name of the file.
EDIT:
The format should be something like: /home/username/directory1/directory2 or something similar.
Hi, look at this post back from a discussion in July 2023. Here I have provided my documentation about setting up the satnogs-auto-scheduler. Maybe this helps.
You can check if your auto-scheduler works by appending the -n option, which computes the passes but does not schedule them, by simply running your command within the satnogs-auto-scheduler directory (In your case this the directory where you have installed the package by running the virtualenv, pip install, commands …). E.g. as provided within the README file you can run following command:
schedule_single_station.py -s <ground station ID> -n
where you need to replace <ground station ID> with your ground station ID, e.g. 3045.
Note that you have to change beforehand into the the respective directory, e.g. by running following command:
cd /home/pi/satnogs-auto-scheduler/env/bin/
As I can see from your posts from above the correct path for you is:
cd /home/pu4elt/env/bin/
since you did not setup a new folder prior to installation.
To know if your crontab work, I would suggest to set your crontab timestamp to something in the future and simply look if your satnogs-auto-scheduler schedules the desired satellite passes. There are crontab time generator available, just google them. Moreover, there are some other general ways to test if a cron-job works. Just google for “How to verify if crontab is working”.
Thank you very much for your help, but since my last post I studied a little more and managed to get everything working…the next step now is to understand gr-satellites (it’s already installed by the looks of it)
Regarding gr-satellites you have to consider that SatNOGS is still based on GNU Radio 3.8, meaning that you have to install the maint-3.8 branch of gr-satellites. Moreover, to combine gr-satellites with SatNOGS you need the satnogs_gr-satellites module.
I’m sorry about the time difference (here in Brazil it’s 4am hehehehehehe)
Apparently I have everything installed including the satnogs_gr-satellites module but I still haven’t been able to understand how I actually decode a packet
I myself have been trying to decode the USP 4k8 of the UmKA-1 that I managed to receive with a certain quality here in Brazil… the soundmodem decodes it but I was unable to transform the raw data into something readable
(observation link fixed to the satellite name)
Anyway, I still have a lot to learn (I’m impressed with the processing power that an old RPi 3B+ has)
If everything is installed and set up correctly it should decode automatically and uploads it to SatNOGS DB.
Maybe you have set DISABLE_DECODED_DATA to True and therefore your are not uploading the decoded data? Did you set the SATNOGS_PRE_OBSERVATION_SCRIPT, SATNOGS_POST_OBSERVATION_SCRIPT and UDP_DUMP_HOST according to the installation instructions of satnogs_gr-satellites?
Can you provide a screenshot of your SatNOGS Client configuration (sudo satnogs-setup → Show)? (Please, black both API keys before providing the screenshot!) I will look through your configuration, maybe their are some wrong settings for uploading decoded data.
In the meantime you can check if gr-satellites is working. Since maint-3.8 does no support .ogg-files just download your audio-recording of the observation and use an online “ogg-to-wav” converter. Than use the .wav-file as input for the gr-satellite command line tool, e.g.:
As far as I can see from the metadata of your observations you at least did not set the UDP_DUMP_HOST, which is required for the satnogs_gr-satellites module. No UDP stream, no data for gr-satellites to demodulate/decode.