Spotted an interesting change in signal form on this waterfall. Well, interesting to me. What should I make of it?
Seems to be APT-like before the LRPT signal (that I’ve yet to successfully decode) dominates. It seems to be very close to the centre frequency although I suppose it’s a common frequency. Is this likely to be the (same) satellite, or just terrestrial interference? It’s not long enough to tell from the doppler shift.
Curious.
It most likely is an APT signal. One of the NOAA sats often waterfall-bombs METEOR-M 2.
On the note of decoding LRPT, I have’t been able to get the LRPT demodulation flow-graph working under Gnuradio 3.8. Gives some assert error relating to the costas loop block which I haven’t had time to investigate.
Simple - that page is old.
We had a LRPT flowgraph that was working with the older GNURadio version, but doesn’t work with the newer one. I’ve updated the page accordingly.
OH, ok thank , do you plan to write a slightly simpler doc to explain how to add modules for decoding? thank you
There’s some stuff on the Wiki under the Contribute menu - e.g. SatNOGS Client Development but looks to be a little out of date in places so you may be better digging straight into GitLab README.md files.
yep, but beginner I find it hard to understand how to use these files and install them and make the difference between stable versions and those still in development
On the note of decoding LRPT, I have’t been able to get the LRPT demodulation flow-graph working under Gnuradio 3.8. Gives some assert error relating to the costas loop block which I haven’t had time to investigate.
I had a bit of a play with this out of curiosity and learning a bit more. I seem to have GNU Radio 3.8.1.0 on my dev box. I don’t get any assert errors as much as I can tell, but neither am I getting what I believe it correct output.
To have a vague chance of knowing what I was doing and knowing what success looked like, I started with an APT signal. After a couple of false starts I managed to get a picture out (see Understanding ‘satnogs-flowgraphs’ although there might be a better place for it).
So for METEOR LRPT, I decided it sensible to start with an IQ recording, rather than an OGG, although as I did get APT decoding working with the OGG maybe that would have been suffiicent. I grabbed the IQ samples for a new Observation 2073897. I then tried to plumb it into lrpt_demod.grc:
As I understand from reading the source, any observations without a specific decoder use the default GNURADIO_SCRIPT_FILENAME (from satnogsclient/settings.py). So that’s satnogs_fsk_ax25.py on my station or fsk.grc in the latest satnogs-flowgraphs. Parameters like frequency and sample rate are fed in from the scheduler.
So I questioned what sample rate the IQ recording was at. It looks like METEOR-M 2’s LRPT 1 runs at 80,000 baud. The FSK flowgraph Doppler Compensation target sampling rate derives from multiplying the baudrate by a ‘decimation’ of 4. The latter is calculated from max(4,satnogs.find_decimation(baudrate, 2, audio_samp_rate)). So 80k x 4 = 320k sample rate. (Although as I’m writing this I now realise the Soapy Source takes the samp_rate_rx parameter as it’s sample rate. I assume they’re one and the same although I better go into the code and try and figure that whether that’s right. For now, I’ll assume the output does hit the target. Does this sound correct?)
I guess one fix would be to collect a sample at the right rate same as in lrpt_demod.grc, but that leads me down another rabbit hole of getting an actual development station set up to schedule, or find a way to schedule a customised IQ pass on my working station…
So am I correct to assume I can fiddle with the Rational Resampler values to decimate this down to a 156250 sample rate - or thereabouts, is it critical? I’m a bit confused by the note: “IQ is at 156.24ksps rate” as this seems to the quadrature rate after the 10/16 resample. Was the original IQ in lrpt_demod.grc 250,000?
Here’s what I’ve got at the moment. I don’t know as much as I should about the modulation side. That’s what I wanted to learn more about.
I’m not getting a coherent constellation, but I know all manner of things could break that.
Bit of a brain dump, but if I can be sure my sample rate is correct I can look elsewhere.
I dug a bit deeper and after a lot of faff and learning came up with this after following LRPT Decoding Flowgraph + Scripts for the image generation (rotated to N-S orientation and highly compressed):
It’s just after sunset (I guess that’s where every METEOR-M 2 pass will be?) so a bit dark, but once rotated I can make out the UK.
This is from Observation #2161118 which unfortunately failed to upload due to muppetry on my part - managed to run out of space… I have a feeling I might get a bit more before LoS to the north without this faux-paus.
I need to grab the IQ from a morning pass for a better picture really. Perhaps tomorrow if I remember.
@vk5qi: I didn’t get any assert errors from the Costas loop in GnuRadio 3.8. (I’ve only done this on my Ubuntu dev box at the moment, not on the Pi.) Not really understanding the maths I did have to faff quite a bit with sample rates and the like until it worked (had a 320khz IQ grabbed with the default observer), but I got there in the end. It looks like the LRPT transponder’s switched to a 72K symbol rate which was somewhat throwing me off! I imagine I should update the database to reflect that.
Great to hear! Can you post the flowgraphs somewhere?
I think it’s pretty much your lrpt_demod.grc with some values tweaked, but I’ll do a proper diff tomorrow.
Is the SatNOGS client architecture any better for post-processing than it was in 2017? I could be tempted to try and re-integrate it but I’d have to figure out how to run dev versions of satnogs-flowgraphs and satnogs-client on my Pi.
I’ve put my flowgraph in a GitLab fork. It seems to run okay locally, but I’m just trying to get it running on the Pi in time for the next pass. It may well need a few more tweaks, not least adjusting the baudrate of the satellite transmitter, which is pending on the database.
If I get a sucessfully uploaded waterfall and a local symbol file to play with I’ll be happy for today.
I’ve approved the transmitter change, it may take a little while for it to sync into the network.
I surprised myself getting a waterfall from my new code’s first observation rather than errors I thought were far more likely, but soon realised there was no audio uploaded. I’ve missed that off the flowgraph, but am not sure how helpful audio is for this - it’s moreorless converted to the symbol bitstream by the time the IQ is no longer required.
Yes, I see no point to save audio for LRPT observations.
