You can enable the IQ file creation via sudo satnogs-setup and then the option advanced -> radio
There are two options that influence the behavior:
ENABLE_IQ_DUMP
Type
boolean
Default
False
Required
No
Description
Create I/Q data dumps for every observation. Use this feature with caution. Enabling this setting will store large amount of data on the file-system.
IQ_DUMP_FILENAME
Type
path
Default
None
Required
No
Description
Path to file for storing I/Q data dumps.
The files created are pretty big and if you use a Pi the writing of these files can wearout your SD card.
Yes the meteor_demod and meteor_decode were just built from the github source today.
After the meteor_demod finished it had 00:00:00 for the time and no files generated. I will give it another try after the next good pass. Thanks again.
You need to set -s 128000 instead of -s 144000. But if you have individual saved I/Q files, try first to run manually on these dumps, then add the post-obs script if all works fine
It looks like the VIT never drops below 1300 during the decode. I have a couple of METEOR M2-3 METEOR 2 2-3 METEOR-M N2-3 (whatever it is called) daylight passes coming and will try some more settings.
Thanks for the help everyone that contributed to the thread. I have finished the work to automate the METEOR M2 2-3 observations and then upload the results including the decoded graphic.
For the satnogs-client configuration I change the client file by hand and here is the code that I am using. SatNOGs version 1.8.1
sudo nano /etc/default/satnogs-client
SATNOGS_API_TOKEN="xxxx....."
SATNOGS_DB_API_TOKEN="xxxx....."
SATNOGS_STATION_ID="xxxx"
SATNOGS_STATION_LAT="30xx"
SATNOGS_STATION_LON="-99xx"
SATNOGS_STATION_ELEV="500"
SATNOGS_SOAPY_RX_DEVICE="driver=rtlsdr"
SATNOGS_RX_SAMP_RATE="2.048e6"
SATNOGS_ANTENNA="RX"
UDP_DUMP_HOST="127.0.0.1"
SATNOGS_RF_GAIN="8.7"
#SATNOGS_RF_GAIN="32.8"
#SATNOGS_RF_GAIN="16.6"
SATNOGS_GAIN_MODE="Overall"
# Black Nooelec SDR
# 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
# Silver Nooelec SDR
# -1.0 1.5 4.0 6.5 9.0 11.5 14.0 16.5 19.0 21.5 24.0 29.0 34.0 42.0
#METEOR The IQ file is huge so it goes to an external drive with satnogs:satnogs ownership
ENABLE_IQ_DUMP="1"
IQ_DUMP_FILENAME="/media/usb/satnogs/iq.dat"
###Control the PSTROTATOR with this stuff
SATNOGS_ROT_MODEL="ROT_MODEL_NETROTCTL"
SATNOGS_ROT_BAUD="0"
SATNOGS_ROT_PORT="192.168.14.144:4533"
SATNOGS_PRE_OBSERVATION_SCRIPT="satnogs-pre {{ID}} {{FREQ}} {{TLE}} {{TIMESTAMP}} {{BAUD}} {{SCRIPT_NAME}}"
#METEOR Run this script after the observation
SATNOGS_POST_OBSERVATION_SCRIPT="/home/pi/postob.sh {{ID}} {{TIMESTAMP}}"
The post observation script postob.sh
Again I am storing the IQ file on an external drive to avoid wearing out the Raspberry Pi SD Card
Again I am storing the IQ file on an external drive to avoid wearing out the Raspberry Pi SD Card
If you have sufficient amount of RAM, you can also store these I/Qs in /dev/shm. Those (i mean, I/Qs) can be rather big, 1/2 gigabytes or so, so check it in advance.
So, if we do an FSK 32000 recording, just change the above -s 144000 to -s 128000. And then all will work automatically: SatNOGS Network - Observation 7823743. It seems that now Meteor M2-3 is transmitting the 72ksps OQPSK images at 137.1MHz and not at 137.9MHz.
I changed to using the 137.1 IQ Transmitter and had to change to 128000 for the demod. Also did the post processing with SmoothMeteor Smooth Meteor. Much better that my earlier results. SatNOGS Network - Observation 7829917
Can you change the FSK 32000 mode to FSK 36000? Then, the I/Qs would be exactly the same for LPRT and these modes… just to minimize the post-processing issues even this alternation between 137.1 and 137.9 makes trouble…
Another idea: can we add a mode of FSK 288000, centered at 137.5? In this case, a post-processing script can try to make a +/- 400kHz correction and decimation of 8 to 144000ksps after, and then trying to decode both channels…
@cgbsat had a similar suggestion, it will be a bit demanding and possibly lock up some stations, not sure if this is better rather than doing a few obs on either frequency. for investigation we can just split a pass in two and do two different obs.
If we are talking custom flowgraphs etc, we still want the metadata of the obs to match what we are producing as data (images, waterfall, frames). otherwise it will get messy very fast and the obs frequency doesn’t match what data is produced.
I can report that my automation works now, check out the previously linked repo.
This is the first obs that produced image, weak reception so not so many lines: MPDUs received: 1142 (456 lines)
The issue I missed at first was the floats that comes over udp needs to be converted to ints for the demod (this could be added to meteor_demod at some point).