I tinkered with gnuradio back when rtl-sdr just took off (2012ish?).

I had no background in dsp or signal processing and found it so opaque as to be unusuable, even though I saw more skilled folks do amazing things with it.

*scratches head*

Might give it another go.

▲

vmilner 6 hours ago | parent | next [-]

New textbook may help

https://www.gnuradio.org/news/2025-01-29-gnuradio-textbook/

▲

perrygeo 7 hours ago | parent | prev | next [-]

I've tinkered with SDR some and did a bit professionally. I always found GNU Radio to fall into the uncanny valley - too GUI to scratch my programming itch but too low-level to be useful for exploration. Between libraries like `pyrtlsdr` and desktop apps like `sdrangel`, I can't seem to find a niche for GNU Radio.

	▲	keeda 7 hours ago \| parent [-]
		I worked with GNU Radio quite a bit at one point a decade+ ago, even writing a custom C++ block, but I almost exclusively used it via Python rather than the GUI toolkit. I found it much quicker to mess around with flow graphs in code than their various UI frameworks, spawning windows as needed when plotting waveforms / spectra etc. The GUI as you said was too cumbersome. I understand that they were trying to make a pretty complicated topic more approachable, but I always felt the push to GUI was misguided. Maybe they would have had more luck embracing the “S” in “SDR” and making programming languages the primary development paradigm.

▲

Enginerrrd 6 hours ago | parent | prev | next [-]

I have to say having just done a very tricky project with a long DSP pipeline in gnuradio, that LLMs are a godsend for getting up to speed on gnuradio blocks. I too found it historically impenetrable, but was able to get a pipeline completed. That said, prepare yourself for a lot of debugging and work to diagnose problems if you’re doing anything of sufficient complexity.

▲

sigbottle 3 hours ago | parent | prev | next [-]

At the end of the day, DSP is a lot of math and a lot of hardware. A lot of GNU Radio's code is a monster unification of so many different choices into certain interfaces (or duplication of the same choices) for, presumably performance reasons? Or just keeping every single DSP technique ever in the God Library for the super power greybeard to use.

If you have a certain DSP goal in mind (say, RF comms), and you want to do stuff but not absolutely balls-to-the-walls processing (at that point, presumably you'd move to hardware), you can design your stack in fairly modular and composable ways. The field is pretty mature and the techniques just work.

In a software context, you can decompose the abstractions fairly cleanly. You won't get 5G high performance networking but you can get good enough results.

▲

stackghost 7 hours ago | parent | prev [-]

Run through pysdr[0], which I found has the right complexity gradient and the right levels of abstraction for people with technical chops but who aren’t familiar with SDR

[0] https://www.pysdr.org/