After 4 (long) years, I can finally make good on my promises to revisit building a DIY Layer 1 and Layer 2 with my SDRs. I've been calling it #pigeon (using my RF library #sparky to build it -- my #hztools successor) -- I've written down as much as I could and have just hit "publish" on a now 4-year old draft post (now 16 posts) at https://k3xec.com/pigeon/
1 Boost
0 Likes
@jamey Thank you so much! Very humbled and appreciate that a great deal!
I've mostly done it to force myself to learn how this all works -- I started off because it was confusing to me. I think I generally (conceptually) could read a flowgraph and reason about things but the /how/ it was doing each of those things was still a questionmark. I forced myself to implement everything from {librtlsdr, libuhd, libairspyhf, libhackrf, libiio} up to where I'm at now purely as a learning exercise
@jamey I only really stopped at librtlsdr (and friends) because they all made sense already (and felt like if push came to shove I could implement it as required) so started at "IQ input" / "IQ output" as the boundary.
I definitely see what you're saying but I've also never used gnuradio (yet!) -- it would definitely be frustrating to not reach through abstraction layers when required!
@paul Yeah, I think the "samples in/out" boundary is a great line to draw for learning this stuff. On one side everything is DSP, while on the other side everything is hardware interfaces, and they're both interesting but there's not much to gain from mixing them.
@paul I read some but not all of these posts and enjoyed what I read! Rants about OSI are always amusing, and your writing style is doubly so. And I was entertained by your notes on FCC-compliant test procedures: I think most of those methods would probably suffice without doing any of the others, but kudos for thoroughness.
I'd be especially interested in reading about what motivated you to write not one but two SDR libraries and what you learned from those efforts. I have one technical complaint about GNU Radio from the time I tried to use it two decades ago, which I think still applies today, so I've been interested in the software engineering aspects of SDR for a long time, and would love to hear your thoughts on that.
(My complaint was that the ability to wire together dataflow graphs of simple reusable components is amazing, right up to the point where you need feedback, when suddenly you can't reuse any of the existing components any more and have to write custom C++ from scratch. And so many protocols require feedback to demodulate. I don't blame them because it's hard to get good performance if you can't process samples in large batches, but from my point of view that little restriction made the whole thing unusable, and I've been wondering how to do better ever since.)