rs1729
commented
2 years ago I played around with basic server/client here https://github.com/rs1729/RS/tree/master/demod/iq_svcl (cf. https://github.com/projecthorus/radiosonde_auto_rx/issues/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
helioshk
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: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:
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: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:
Returns:
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:
Returns:
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: