Multi-Channel Decode Thoughts

[darksidelemm]

Trying to collate some thoughts on what auto_rx would need from a multi-channel SDR server (think: SpyServer, but actually open source) into one place, instead of scattered across multiple issues.

auto_rx needs two things to be able to receive radiosondes:

RF Spectrum Snapshot / Average

auto_rx needs a power spectral density snapshot of the RF spectrum over the frequency range of interest. auto_rx performs peak detection on this (with a user-configurable SNR threshold) to decide what frequencies it should try and receive radiosonde signals on.

This doesn't necessarily need to be power spectral density - it could also be an SNR estimate.

It important that this snapshot of spectrum is actually an average (or possibly a max hold?) over a definable time period. Many radiosonde types do not transmit continuously, so we need to be observing for at least 1 second to ensure we catch those sonde types.

Currently, auto_rx uses rtl_power to get this information. rtl_power will perform power averaging over a user-definable time period (auto_rx sets this to 20 seconds by default), and provide a CSV output. Currently we use a frequency bin size of 800 Hz. Another neat thing rtl_power will do is jump the SDR in frequency to cover a frequency range wider than the SDR's bandwidth. Not required if you have a SDR that will cover the entire range of interest of course...

IQ / FM-demodulated RF

Once we have a candidate radiosonde frequency, auto_rx then performs a 'detection' step. It feeds 48 kHz BW IQ (signed 16-bit) into the 'dft_detect' utility, which performs correlation against known radiosonde packet headers to determine if the candidate signal is in fact a radiosonde, and which type it is. It will also estimate the actual centre frequency of the radiosonde. This information is then returned to auto_rx.

auto_rx then starts up the appropriate decoder. The majority of radiosonde decoders in auto_rx take IQ input (signed 16-bit format). Due to some optimisations in the FSK demodulator used (fsk_demod), the IQ bandwidth must be an integer multiple of the signals baud rate. Currently we use rtl_fm to provide this narrowband IQ (-M raw) The following sample rates are used:

• RS41, RS92, M20, LMS6, iMet-54, MRZ: 48000 Hz (2400/4800/9600 baud)
• RS92-NGP: 96000 Hz (still 4800 baud, but higher modulation index)
• DFM: 50000 Hz (2500 baud)
• M10: 48080 Hz (9616 baud)

The LMS6-1680 is a special case, and does not use fsk_demod. It has a very high modulation index, and required a much wider sample rate:

• LMS6-1680: 240000 Hz

Finally, some radiosondes use AFSK (FSK-over-FM), and for these we need to pass a FM-demodulated signal (signed 16-bit, mono) into the decoder. The filter bandwidth prior to the FM demodulator should be configurable to optimise for the known signal bandwidth. The FM demod should also not have any audio-level filter applied (either high-pass or low-pass).
Currently we use rtl_fm to perform fm demodulation (-M fm), with the following filter bandwidths:

• iMet-1/4: 15 kHz
  Note that the audio bandwidth send to the decoder is still 48 kHz.

We also decode the Meisei iMS-100 sondes using a FM-demodulated signal (15 kHz filter bandwidth, 48 kHz sample rate), though it should be possible to feed this decoder with IQ as well (needs to be tested).

Update: All decoders now support accepting IQ data, so FM support is no longer required.

Requirements for a Multi-Channel Server

So - we want to be able to receive many radiosondes at once using one SDR. Something like an Airspy R2 (12 MHz) or Airspy Mini (6 MHz) would be sufficient to cover the entire radiosonde band in many parts of the world. Ideally we want to get to a point where the only limit on the number of radiosondes we can receive in parallel is the bandwidth of the SDR we are using, and how much CPU we have available.

It may be possible to extend this concept to making use of multiple SDR servers, each with a narrower-band SDR (e.g. a RTLSDR), with multiple SDRs providing coverage over the required range.

There is already a SDR server that almost fits the requirements - SpyServer. There is a command-line client from which we can request a snapshot of power spectrum, and narrowband IQ. However - SpyServer is closed source, is limited in what SDRs it supports, and has other restrictions which don't make it a good fit. The protocol used is not completely documented, and some features of it are 'restricted' to SDR# only. This is not a good candidate for integration with auto_rx - we want a completely open-source server.

To somewhat minimise what could be a significant level of complexity in auto_rx's configuration, I would suggest that the frequency range covered is configured entirely in the server itself. auto_rx can determine the available frequency range based on the results of the power/SNR request.

So, based on the above information, if we want to integrate a multi-channel SDR back-end into auto_rx, it would made far simpler if we had two client utilities:

Request Power Spectrum or SNR

This can return either Power Spectrum or a SNR estimate - either is fine.

Command-line parameters:

• Connection details of SDR Server (network address, port?)
• Bin Size (Hz) - (If this is adjustable, and not a function of some parameter in the server)
• Sampling time (seconds)
• Optional: Selection between averaging, or peak-hold.

Returns:

• Some representation of power/SNR vs frequency. The exact format is not that important, and a parser can be written for whatever is available. This could be something like two arrays, one for power/SNR and one for frequency, or it could be a start frequency and frequency step, then the power/SNR data.

auto_rx would then perform peak detection on the resultant data (or if SNR, it could just threshold), then continue on to the detection -> decode stages.

Request Narrow-Band IQ / FM Slice

This would be a command-line client that accepts some arguments, and outputs samples on stdout. These can then be piped into the existing demodulator chain with ease.

Command-line parameters:

• Centre frequency (Hz) - If this is out of range of the SDR server, the client should return an error!
• Demodulation Type: IQ (signed 16-bit complex samples), FM (signed 16-bit mono samples)
• Output sample Rate (Hz) - Often 48000 Hz, but some odd samples rates are sometimes needed - see further above.
• FM Filter Bandwidth (Used to narrow up a filter around a signal for better resultant SNR)

Returns:

• Sample data on stdout, in either signed 16-bit complex, or signed 16-bit mono format.

auto_rx would terminate the client when no packets are detected based on some timeout, as works currently.

Update: All decoders now support accepting IQ data, so FM support is no longer required.

Other Notes

Having a multi-channel backend means we can make some changes/additions to the way auto_rx normally operates. This could include:

• Always-on decoders: If the frequency and radiosonde of a launch site is known to be consistent, and we have sufficient CPU, we could have a decoder running continuously. This would reduce any delay in reception after a sonde is launched.

[rs1729]

I played around with basic server/client here
https://github.com/rs1729/RS/tree/master/demod/iq_svcl
(cf. #72)
However if you (or fsk_demod) want individual sample rates (for the IQ output) that are multiples of the baud rate of a particular radiosonde, you would need rational resampling.
And if you want to run this on a raspberry, you would need more optimization I guess.
So I'm not sure if the modular approach would still be the way to go.
What would be expected, 2-3 signals and scanning/detecting with a raspi 4 and airspy 6 MHz? Or 2 MHz and max 3 signals plus scanning/detecting?
On better hardware 4 signals and more simultaneously and airspy should work even with the simple/basic approach above.

[darksidelemm]

As an update on this, using an Airspy Spyserver and an Airspy Mini, i've successfully had a RPi 4 decoding 5 radiosondes simultaneously.

[helioshk]

ogn-rf does demodulate multiple fsk signals in a rtlsdr channel.
https://github.com/glidernet/ogn-rf
I don't know how this works but it's probably not easy to port.

[darksidelemm]

At this point the Spyserver, and (hopefully soon) KA9Q server solutions will provide this functionality in a suitable manner.