Hi everyone,
I was wondering why I couldn’t decode satnogs .ogg recordings of NAYIF-1, FUNCUBE-1 etc so I decided to go old school and play the ogg of a NAYIF-1 pass through the windows NAYIF-1 decoder.
All worked - loads of frames. Hurray.
So tried with gr-satelllites. Nothing even after converting the ogg to a wav with sox which usually works.
Then I remembered a previous exchange here which talked about the signal being centred on 12k in the audio (which also explains why I had trouble hearing it )
So I set the --f_offset in gr-satellites to 12e3 and voilà! Frames.
Maybe that was obvious to most - thought it might be helpful for others
As described in the documentation, gr-satellites will default to a frequency offset of 1.5kHz for BPSK signals of baudrates smaller or equal than 2400 baud, and 12kHz for baudrates higher than 2400 baud. This is because it was common practice to record BPSK signals like so, especially with non-SDR receivers having 2.7kHz SSB filters (and I have the impression that SatNOGS did the same until recently).
Now I think that SatNOGS is using 12kHz for all BPSK signals regardless of the baudrate, so as you mention --f_offset 12e3 needs to be used for baudrates less or equal than 2400 (and will do no harm for higher baudrates).
It does appear that way. I’ve just got 8 frames using my post-observation script (which isn’t pretty or efficient I’m dead sure) from this observation https://network.satnogs.org/observations/2552077/ which is with an RTL-SDR v2 dongle, an RPi 3 and a V-dipole that’s pointing vaguely north…
Happy to share the script once I’m a bit happier with it.
Yep, the reason I switched it to a 12 kHz offset for all signals was because there was often cases where the either the RX station or the transmitter were off-frequency. With the 1.5 kHz IF, there were far too many cases where the signal was either completely outside, or hitting the filter skirts, making the recordings unusable.
With it placed at a 12 kHz IF, and with the entire 24 kHz of bandwidth available, there was much more chance of the recording being usable.
Some experimentation with parameters might improve results a lot. Just setting --clk_limit 0.03 gives me 40 frames with the ogg file from that observation. This is more or less the number of frames I can count in the waterfall, not counting those which are very weak. I wonder why the clock rate limit needs to be increased. Maybe the resampling rate is slightly wrong somewhere in the SDR/gr-satnogs/the OGG file?
Now this thing about including gr-satellites in the post observation script looks quite interesting. It might be the way to push forward this thread about gr-satellites and SatNOGS integration which is pretty much dead now. The only thing I’m truly missing is for the frames decoded by gr-satellites to appear in the data tab for the observation. But this could be sent to the server by gr-satellites (I guess it’s a web service of some sort?). Maybe some of the SatNOGS devs could explain how to best do it, or point me to some code I could use as a reference.
Might be because I’m pushing the Pi3 pretty hard and it’s at the limit of what it can do.
I’ll have a read around so I can understand better what the clock limit setting actually does.
I can also try the script out on my Pi4 2Gb other satnogs station to see if that makes any difference.
Re: submitting to SATNOGS/amsat-uk etc I’ve put the gr-satellites config.ini in /var/lib/satnogs/.gr_satellites by hand but I’m not sure yet whether that’s been successful. Even so, the submission wouldn’t quite be as near-synchrous with frame reception as we’d hope, I guess.
That said, the script produces a wav file timestamped with the start of the pass so maybe it wouldn’t be impossible to marry the frame with the time of reception?
No such luck with JY1-SAT: I get an ‘unknown frame’.Putting in a print statement into funcube.py gives the frame number as 32 or 33, neither of which appear in the frametype list at the start of funcube.py.
Pushing the wav through the windows decoder extracts realtime/whole orbit data as well as the image files. Is this one for here, gr-satellites issue post or dodgy programming on my part
Yes. I’ve been trying since long ago to make the JY1SAT team share with me a copy of the full telemetry details for JY1SAT. Apparently they don’t have something ready they can share right away and they’re quite busy to make it (I understand it 100%).
They were kind enough to give me some details regarding frames 32 and 33, which are used for SSDV data. Details here. I implemented a working decoder for this in gr-satellites v1, but now I realize it has been lost in the change from v2 to v3, so I’ve left myself some homework to recover this.
In any case it’s not strange that the telemetry decoder complains about “unknown frames”, but you should be able to store the data into a file and then run the SSDV decoder on it. I’m afraid I don’t have the details to implement the realtime telemetry and whole orbit data, though.
Currently the frame data is simply stored as binary files in /tmp/.satnogs/data. If you store them with a proper timestamp (the most difficult part I think - same as with recordings) this would be the best intermediate solution until Metadata is fully implemented.
I was actually thinking of sending the data to the server (web API or whatever) directly from gr-satellites, but maybe storing demodulated data in files and letting satnogs send it is more reasonable. Would this work if gr-satellites is run in the post observation script, or not because the functionality in charge of scanning this directory has already run before gr-satellites?
The timestamp is tricky, since we’re running off a recording. Maybe it’s just more reasonable to hook gr-satellites somehow to the gr-satnogs flowgraph and run it simulatneously in real time. gr-satellites already can get samples from UDP, and it would be easy to add another interface, such as ZeroMQ.
)