←back to thread

940 points mihau | 1 comments | | HN request time: 0s | source
Show context
clueless ◴[] No.45263512[source]
more than 15 years ago I got a chance to play with gnu radio and back then it was hailed as the next big industry.. fast forward, and beyond the hacking community (and the hobbyist), it still has not taken over.
replies(1): >>45263522 #
NoiseBert69 ◴[] No.45263522[source]
It's super popular within the RF industry.

But for the normal users - to be honest - most topics are too heavy on complex math. And there's no way to avoid it if you want results.

Most advanced radio stuff much more complicate than checking out a repo from GitHub and compiling it.

replies(1): >>45263770 #
dummydummy1234 ◴[] No.45263770[source]
My impression is that gnuradio is fine for prototyping/poc, but has issues in its design when you try and run production workloads with more complex workflows (ie, writing custom Mac layers/ workflows that involve heavy feedback, etc. you end up having to do a a lot of hacking around with the message passing infrastructure).

That being said last I used it extensively was v3 so maybe v4 is better. Did they get rid of thread per block and allow you to have a single thread service a sub signal chain? I remember that the number of context switches between threads, and balancing latency vs buffer sizes was a pain in the rear.

replies(1): >>45264625 #
structural ◴[] No.45264625[source]
The threading model is still difficult, and it's still enough slower that thinking you're going to be comparable to custom silicon that's been designed for a particular protocol is silly.

It's great fun for doing signal analysis, but I'd never want to try and implement a full-duplex communication system in production with it.

replies(1): >>45267057 #
1. ronsor ◴[] No.45267057[source]
If I were doing SDR-based comms in production, a custom C (or C++) application would be on the table, and nothing else.