[Ground-station] channelized FM SDR

[Robert McGwier]

If you have not done so I strongly urge you to install 64 bit Raspbian,
Ubuntu 20.04 LTS 64 bit version, etc.  It makes a difference.

Bob


On Sun, Oct 25, 2020 at 7:02 PM Phil Karn via Ground-Station
<ground-station at lists.openresearch.institute> wrote:

> This may be of interest to those working on multi-channel voice
> bandwidth satellite uplinks.
>
> I've been working on my own multichannel SDR for some time. I've got it
> demodulating all 216 FM channels in the TASMA 2m (soCal spectrum
> coordinator) bandplan and multicasting the demodulated PCM and Opus
> compressed audio on my home LAN.
>
> The front end hardware is an Airspy R2 providing 20 Ms/s. The samples
> are real, so it covers a 10 MHz bandwidth minus some for anti-alias
> filtering. The R2 is connected to a Pi4 that multicasts the raw samples
> on my home Ethernet at 250 Mb/s, where they're picked up by an 8-core
> 3.4 GHz i7 running Linux and the bulk of the SDR code.
>
> I can plug the R2 directly into the i7 but I wanted to stress-test the
> network and see what the Pi can do. Unless something major happens, I'll
> see *no* sample drops between the Pi4 and the SDR program on the i7. I
> tried connecting a second Airspy R2 on the same Pi4, but it only has a
> single USB 2.0 bus and that was asking too much.
>
> My SDR makes extensive use of the overlap-save method of fast
> convolution for filtering. One of the really neat properties of
> overlap-save is that you can have an arbitrary number of independent
> filters all sharing a single forward FFT. The incoming sample stream is
> converted to the frequency domain, and then each demodulator thread
> picks just the frequency domain bins it wants. (The usable bin size is
> controlled by the FFT block rate, which is currently 100 Hz.) The
> forward FFT is shared by all demodulator threads. Each demodulator needs
> its own inverse FFT to convert back to the time domain, but they run at
> a much lower sample rate (48 kHz at present). The output sample rate is
> controlled by the number of FFT bins chosen, so you can easily decimate
> to any multiple of the block rate, i.e., any output sample rate that's a
> multiple of 100 Hz.
>
> The SDR is highly threaded so it takes good advantage of multi-core
> CPUs. One thread runs the 400 k point forward FFT (10 ms block rate (100
> frames/sec) with a 2:1 overlap for the fast convolutions. This takes
> about 38% of one CPU core, shared by all demodulators.
>
> Each channel demodulator runs in a separate thread and is completely
> independent of the others. They downsample (to 48 kHz), apply the
> desired filtering (currently 16 kHz, but easily changed) and demodulates
> to baseband. I'm using the FM demodulator for 2m, but I also have a
> 'linear' demodulator for all the other modes (SSB, CW, IQ, envelope AM,
> synchronous AM, etc). Fine tuning is done for RF frequencies not
> multiples of 100 Hz, but that's more important for the linear modes than
> FM.
>
> My FM demodulator has an experimental "threshold extension" scheme that
> looks at the magnitude of each pre-demod sample and attenuates the
> demodulator output when the magnitude is below some fraction of the
> average amplitude. I haven't quantified it yet but it very audibly
> attenuates the "popcorn" noise you get in a FM signal at threshold. My
> squelch works from first principles: measure the mean and variance of
> the signal amplitude, convert to SNR, and open the squelch if it's above
> a threshold (currently 6 dB). It works so well I haven't felt the need
> for a squelch knob.
>
> While the NBFM demodulator needs the 48 kHz sample rate, I *could* use a
> lower sample rate (e.g., 16 kHz or even 8 kHz) for the narrowband modes.
> But I currently run the linear demodulator at 48 kHz since that's what
> the Opus codec prefers, and it doesn't seem to cost much anyway. (The
> compressed Opus bit rate only depends on the quality setting, not the
> input sample rate).
>
> Each FM demodulator thread uses about 0.7% - 1.0% of a CPU core, which
> is too small to get an accurate reading. When demodulating 216 channels
> everything uses about 133% CPU, i.e. 1.33 cores (of 8) on average. Opus
> compression actually requires considerably more CPU horsepower than FM
> demodulation, and I've discovered I need to thread it more. (Normal
> activity on the 2m band isn't a problem; I discovered the Opus limit
> only when I introduced a bug in my FM SNR routine that opened most of
> the 216 squelches at once.)
>
> I also have a 1200 bps AFSK AX.25 packet demodulator running on every
> channel, reporting whatever it hears to the APRS network. This doesn't
> take much CPU since it runs only when a squelch is open. The packet
> demodulator is a separate Linux program, reading the demodulated PCM
> audio from the SDR and multicasting its decoded frames back onto the
> LAN, where they're picked up by yet another program that reports them to
> the APRS network.
>
> My thinking for some time is that a satellite transponder designed to
> regenerate narrowband voice should have a multichannel receiver much
> like mine feeding the received digital audio streams into a single
> multiplexed downlink. In effect, I now have exactly this on my home
> network. To listen, I fire up an audio monitor program on my laptop that
> joins the IP multicast groups carrying the Opus-compressed audio and
> each active 2m channel pops up on my local display. I can pan each
> signal in the stereo image, adjust its gain, mute certain channels, etc.
> Joining the multicast group is handled by the network subsystem
> (including my smart Ethernet switch). The SDR itself just shovels out
> the bits and it doesn't care or even know how many users are listening.
>
> In a satellite, these multicast streams would come down multiplexed onto
> a single high speed downlink like the DVB-S2 subsystem you're designing.
> At the moment, my receiver only handles analog FM, compressing each
> audio channel with Opus. But it provides the framework for narrowband
> digital modes, or a hybrid analog/digital system. Each digital
> demodulator can run as an independent Linux process, reading the
> multicast output of a channel from my SDR, demodulating the signal and
> multicasting its own bit stream back onto the network. I'm looking at
> porting the MMDVM code to my system so it will work with multicast PCM
> audio in and out.
>
> In a satellite I envision a mixture of Opus-encoded analog FM streams
> and demodulated digital uplink streams, with an eventual transition to
> digital only.
>
> Anyway, this is all a proof of concept I think you might find
> interesting. The main programs are currently 'airspy', 'radio', 'opus',
> 'packet' and 'aprs'. Each runs as a Linux daemon, automatically started
> at boot time. The 'radio' program reads a single configuration file
> telling it the frequencies and modes on which to listen and where to
> multicast the demodulated outputs (one IP multicast group can handle
> multiple streams).
>
> So this thing can operate totally turnkey with NO user interface except
> for the config file. It just demodulates each stream and multicasts the
> results for anybody on the LAN who wants to listen. I've been running an
> earlier version as a turnkey APRS receive-only iGate for several years
> on a Raspberry Pi 3 and an AMSAT UK Funcube Pro+ dongle (its 192 kHz
> sample rate is easily handled by a Pi2 or 3).
>
> There is an optional control/status interface to each demodulator that
> uses my own UDP-based protocol for which I've written a control client.
> You can enable/disable this on a per-demodulator basis in the config
> file. I typically start the regular demodulators without a control
> channel, then add one I can use to look around manually if I want.
>
> I'm ready to put this code out for general play. It's still pretty rough
> but I think it's a good proof of concept.
>
> Phil
>
>
>
>
>
>

-- 
Bob McGwier
Founder, Federated Wireless, Inc
Founder and Technical Advisor, HawkEye 360, Inc
ARDC Grants Committee
Adjunct Professor Virginia Tech
Former Chief Scientist:  The Ted and Karyn Hume Center for National
Security and Technology
Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20201027/e0aff4a2/attachment.html>