Hacker News new | past | comments | ask | show | jobs | submit login
A Peek at GNU Radio’s Buffer Architecture (gnuradio.org)
142 points by ptr on Jan 15, 2017 | hide | past | favorite | 15 comments

tl;dr: the old magic ring buffer trick

SDR strikes me as good in theory, but breaks down for anything practical.

My core 2 duo was 100% cpu utilization simply from decoding 56kbps 2-BPSK, even with SIMD extension enabled (within GR).

It is practical, but it's important to have the core of your code optimised. In particular, you will need a very tight "multiply-accumulate" loop, as typically used in an FIR filter.

By way of real-world example, a 9600 bps P25 transceiver (with FEC) can be done on a C5500 DSP (200MHz) with about 10-20% CPU utilisation. As a further illustration, a vocoder that could not run in real-time was reduced to 5% CPU usage when a correlator (a single MAC loop in C) was replaced with the equivalent assembly that used a MAC instruction. 97% of the CPU time was being spent in that loop.

I run a HackRF One on an i7 (Intel NUC) and it is hard to peg the Cores. Typically when I do it is because some synthetic workload is dumping infinite work into the buffers and so everything is running full on, but generally real signals have been 20 - 30% of one or two cores.

Weren't Winmodems handling 56K v.92 fine on much older hardware? Or did they still have more work offloaded onto the hardware?

They had an analogue front end to reduce much of the load.

Here's a practical example of SDR to make a powerful radio telescope: https://en.wikipedia.org/wiki/LOFAR

Something's terribly wrong with your flowgraph.

I suppose it depends what you mean by practical. I use GR to simultaneously monitor several NBFM channels, and also for HF comms. SDR will probably never have the speed of dedicated hardware, or the power consumption of low power analog circuitry. But SDR definetly has it's place, and can outperform many classic architectures if power is not an issue.

You may find this SDR LTE eNodeB interesting: http://bellard.org/lte/

There's also this open-source LTE library: https://github.com/srsLTE/srsLTE

Any other prefiltering / post-processing? This processing should be pretty trivial on its own. This should be fairly easy load - definitely not pegging the CPU at 100%.

Core 2 duo was released in 2006, is it as bad on anything from this decade?

Most of the principles at work in SDR are integral parts of every 802.11 radio.

SIMD is only going to get you so far; I'd expect much greater gains from running on a GPU.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact