@ve2dsk Yes but M2 has been experiencing axis stabilization anomalies for the last several days and is only transmitting in HRPT (1.7 GHz) and not LRPT (137 MHz).
Scott
2 Likes
Witch python section process create the “.s” file…??
I just update to new client v1.81
Redo all modif, but seem not creating any S file…
Any idea? Real
Hi Real, it has been a long time! I haven’t updated yet, and have no VHF station at this moment. So I didn’t test the new version yet. The .s file gets generated by the LRPT flowgraph. This is described in step 1 of the Howto. It should be in /tmp. Your screenshot shows the data dir where the images get moved to.
Can you take a look in /tmp. Be careful it gets cleared at reboot! You may need to run a fresh observation.
Edit: The LRPT flowgraph appears to be running as it provided a wide waterfall.
Best regards, Eelke.
Oh, now i remember the correct “S” file directory …
As you see, flowgraph generate the file but my problem is the post convert process…
My .s file seem not be treated Real
I maybe have a clue…
After satellite pass, I can manualy execute the cmd sudo python ./process_meteor.py
So something with post observation script, I believe…
Real
(only VIS proceed)
Hi Real,
It is difficult to guess what is wrong. Can you take a look at the log file, after an observation and post it here?
journalctl -f -u satnogs-client.service -n 100
We should be able to see the error there and this should give a hint what goes wrong. I think you have got it almost working as all pieces work. Just not automatically yet.
Best regards, Eelke.
Hi Eelke
Wow…Synthax error wen I create directory name…!! /satnogs-Extrats/scripts (Cap E).
Thank for help… Real
3 Likes
Hi Real, I think it works again! Congrats!
Hi Eelke
Yes and…No…!
I put back Client v1.7 for this specific pass.
After correcting directory name in v1.8, got permission denied with medet_arm.
Is medet_arm should be satnogs:satnogs as owner and group…??
Real
Hi Real, you got me there! 
The access rights for the medet_arm file look OK. But also check if the satnogs user can access the folders. Can the satnogs user read from the folder /home/pi? And also from the subfolder /medet?
The satnogs user is different then the pi user. So it needs at least the right most r-x on the folders and files.
Is at the fact I put back medet_arm file, from archive, without recompiling (CMake from source) in new buster OS. Real
I think medet did work in an earlier test, when you ran it manually. So it should be OK. Can you take a look at the folders?
ls -l /home
ls -l /home/pi
ls -l /home/pi/medet
They all should have at least r-x at the right end. Then the satnogs user can access the medet_arm file.
You point me in the right direction Eelke
The error came from medet directory permission itself…(!)
Real
1 Like
ls -l /home/pi
Look like this now… Many Thanks Real
1 Like
Hi @bcsak
Did you need to change anything for the new Meteor M2-3 satellite to get it decoding?
@geoscan attended me to your beautiful observation:
https://network.satnogs.org/observations/7788561/
Thanks!
2 Likes
Hi @EelkeVisser and @geoscan
Unfortunately it won’t work out of the box with the previous scripts, however we left it unchanged temporary to have baudrate=72.0e3 with LRPT observations.
We have turned on I/Q recording and insert a simple script in the postobs which uses Davide Belloli’s demodulator and decoder codes. First we demodulate the I/Q file then pass it to the decoder and save the result with the appropriate naming in /tmp/.satnogs/data/
3 Likes
The full processing script looks like this:
ID="$1"
DATE="$2"
demod=/usr/local/bin/meteor_demod
decode=/usr/local/bin/meteor_decode
cp /tmp/iq.dat /tmp/${ID}.dat
${demod} --batch --quiet -O 8 -f 128 -s 144000 -m oqpsk --bps 16 /tmp/${ID}.dat --stdout | \
${decode} --batch --quiet --diff -a 65,65,64 -o /tmp/.satnogs/data/data_${ID}_${DATE}.png -
rm -f /tmp/${ID}.dat
4 Likes
That is cool (:
It should be possible to use the UDP sink for this then ?
in preobs, launching netcat to spit out the data to stdout, piping it to demod and in postobs kill it and launch the decoder.
Or implement udp input in the demod.
1 Like
Maybe yes! Or just piping the iq.dat using tail -f or something equivalent to the decoder when the pre-obs script is called.
The problem now is the output of the demod/decoder differs on a raspberrypi and on a normal x86/linux server while runing exactly the same demod|decode pipeline on the exactly same I/Q input. The latter (i mean normal x86/linux server) decodes more blocks from the image.
Can you explain which flowgraph you use to dump IQ data sampled at the right sample rate?