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 My introduction to SDR was as a student doing a GSoC project over a few months. I was trying to produce an open implementation of 802.11 (the original, 1Mbps BPSK with 11 chips of DSSS per bit, version). Since I couldn't use GNU Radio without bypassing most of its cool features and writing the whole demodulator as a single C++ class, I skipped all of it and did all my DSP work in Haskell, and got the same kind of experience that it sounds like you did.
I didn't get to test it on real hardware though, for a reason which caught me by surprise. It's not because I used Haskell, which was actually fast enough to keep up, as long as I was careful. But the original Ettus Research USRP had a USB 2.0 High Speed connection to the host, and was configured for 16-bit sampling on each of I and Q, and in that configuration it turned out that 480Mbps of USB bandwidth was not enough for a full 802.11 channel, which by Nyquist needed a bare minimum of 11 million I/Q samples per second.
A few years later I did another SDR project with a student rocketry group building an open-hardware GPS receiver. That time it was my fault that I didn't correctly think through the required bandwidth when specifying how the EEs built the hardware, but the outcome was kind of the same.
So I haven't had great luck doing SDR, but gosh, it's both fun and very educational, isn't it?
@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.)