FSK and FM demodulation (was: Missing option, --f_offset not recognised)

[janvgils]

With the lasted build and trying to decode a BPSK observation I am running in the following error:

gr_satellites satellite: error: unrecognized arguments: --f_offset 12e3

I am trying this with the following cli command:

gr_satellites 46277 --wavfile UPMSat-2_satnogs_2798315_2020-09-06T11-09-46.wav --samp_rate 48e3 --f_offset 12e3 --hexdump

gr_satellites --version 46277
gr_satellites v3.4.0-git
Copyright (C) 2020 Daniel Estevez
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Observation used: https://network.satnogs.org/observations/2798315/

Is the support for freq offsets dropped in the current releases?

[daniestevez]

UPMSat-2 uses FSK, not BPSK, hence the lack of the --f_offset option.

Now some rationale about this. With FSK satellites, 99% of the time we're using recordings of FM-demodulated data (and I mean the whole community, not just gr-satellites). This is because traditionally people have used conventional radios in FM mode to record these, and now they're using SDR software in FM mode. In fact, this is actually not so good. The fact that FM mode is done before the decoder precludes other better methods of decoding. It would be better to record FSK signals in "wide-SSB" mode, so that they fit into the 24kHz passband of a 48ksps real signal, or in IQ mode, but people very rarely do this.

With this in mind, gr-satellites works as described in FSK demodulation and IQ input. Basically, if you don't use the --iq option, it expects an audio signal which is already FM-demodulated. If you use --iq, it expects an RF signal which still has FM. This may be counter-intuitive and somewhat strange, because changing to IQ mode changes the demodulation method, but I figured that this is what would work with most of the recordings out there, since most non-IQ recordings are already FM-demodulated and all IQ recordings have FM.

Now we come to UPMSat-2. This satellite uses 1k2 FSK, which is a bit uncommon, given its low baudrate. In my opinion, this should be recorded or demodulated in FM mode, just as we do with other FSK signals. As mentioned above, it is not the best approach, but it is consistent with what we do with other satellites.

Now we have the pitfalls. The audio output of a conventional radio is AC coupled, and will block the low frequency signals needed by 1k2 FSK. So demodulating 1k2 FSK with a conventional radio may not work. With most SDR software we don't need to worry. Everything is digital, so there is no such thing as AC coupling and they will preserve the signal perfectly.

It also happens that this kind of 1k2 FSK signal fits into the 2700Hz passband of a conventional SSB receiver, so people may attempt to receive or record the signal in USB mode. In my opinion this is inconsistent with what we do with other FSK signals, but the main point here is that FSK signals of higher baudrate won't fit into 2700Hz, so they must be recorded in FM mode (or in wide-SSB mode, as I suggested above).

Finally, software able to decode 1k2 FSK AX.25 is not that common. The standard modes for Amateur packet radio are 1k2 AFSK AX.25 and 9k6 FSK AX.25 + G3RUH. So you'll find that for instance Direwolf, and probably UZ7HO soundmodem don't support 1k2 FSK. However, these decoders can be tricked by the following method: if we take a 1k2 AFSK signal and demodulate in FM (as we usually do), the result is similar to what we get by receiving 1k2 FSK in USB mode.

This method is not very good. First, the tones of an AFSK signal don't have any Doppler (almost), since they are at audio frequency. However, with FSK in USB mode the tones have any uncorrected Doppler. A usual AFSK decoder will assume this and be quite picky about FSK signals received in USB that have any uncorrected Doppler or are not centred in frequency (with UZ7HO I think you can click on the waterfall to change the tone frequencies, though). Second, depending on the FSK deviation, the tone spacing of the USB-demodulated FSK signal will not coincide with that of an AFSK signal (which uses Bell tones at 1200 and 2200Hz). I think that the FSK tones of UPMSat-2, either by design or by coincidence, are spaced 1000Hz, though.

So even though people are using USB mode to then use their regular AFSK decoder by pretending this was an AFSK signal that has been received in FM, this is not a very good or sound approach.

Sources of (mis)-information don't help. I've just seen that the mode is listed in SatNOGS as "1k2 BPSK AFSK Tones". This description doesn't make any sense. The UPMSat-2 documentation doesn't help either, since it says "UPMSat-2 public telemetry messages are sent in AX.25 Unnumbered Information Frames at 437.403.500 Hz at 1200 bauds, USB mode". This doesn't really mean anything, and honestly the first time I read it I thought it was intended to mean 1k2 BPSK.

By the way, there has been the following Twitter discussion with the company that built the UPMSat-2 radio. Also, by no means is UPMSat-2 the first satellite to use 1k2 FSK. There have been others, like 1KUNS-PF and Astrocast 0.1, and people have usually recorded these in FM mode. Maybe the difference here is that these others didn't use AX.25, so people couldn't trick their AX.25 AFSK decoders by using USB mode.

To get to the bottom of your question, there is currently no way to process these UPMSat-2 USB recordings by using suitable command line parameters with gr_satellites. Not all is lost. It is possible to make a simple flowgraph where the signal is moved to baseband, optionally FM-demodulated using "Quadrature Demod", and then decoded with the "Satellite Decoder" block. I did something similar to decode the unknown satellite in this VV16 launch. This is attached here in case it helps:

unk.zip

Alternatively, you can do as people are doing with other decoders and trick gr-satellites into thinking this is an AFSK signal. For this, you can make your own modified .yml file by looking at the information for a "true" AFSK satellite, such as AmicalSat. I already explained why I think this is a good idea, but you might prefer its simplicity.

In view of all this, I intend rethink how gr-satellites handles FSK signals. Ideally we would want to be able to decode anything regardless of how it has been recorded, so it might make sense to have --f_offset as we do for BPSK signals. However this would only make sense for non-FM demodulated signals (both IQ and non-IQ). We should have an option to tell gr-satellites that the signal is already FM-demodulated (off the top of my head --post_fm, but probably there's a better name). To avoid confusing people, I think the defaults should be as now: --post_fm disabled for non-IQ data, and enabled for IQ data. Note the interactions between these three parameters: both --iq and --f_offset mandate --post_fm False, since they don't make sense with --post_fm True. Also, --iq should change the default of --f_offset, just as we do for BPSK.

My plan is to release v3.4.0 as soon as the VV16 satellites have definitive NORAD IDs, so this modification to how FSK decoding works will have to wait for v3.5.0. As always, I'm open to any suggestions about what is more useful (or less confusing) to users. I'll be leaving this issue open for discussion and as a reminder that I need to change FSK demodulation.

[daniestevez]

For anyone trying to demodulate recordings of UPMSat 2 as I suggested above, the following flowgraph may be useful as a reference

upmsat_usb.zip

I have tested it with this SatNOGS recording and it decodes one packet. The other packets are much weaker, and perhaps impossible to decode.

[N6RFM]

Hi Dani,
Looks like this topic is bumped to gr-satellites 3.7. Thanks.

FWIW, here is a link to a short IQ file for UPMSat-2 which may be of use.
https://www.dropbox.com/s/elpbzudl7gbyz32/upmsat2_437.405MHz_50Ksps_29Nov20_145400Z.raw?dl=0

At present, the satyaml approach with IQ or quadrature demod input do not work for me. However as you noted above , it is possible to decode UPMSAT-2 by mixing a signal (1860 Hz in my case) to downshift the pass-band and feeding that output to Direwolf expecting standard 1K2 AFSK. Best, Bob