Software-Defined Radio for Engineers (2018) [pdf](analog.com)
analog.com
Software-Defined Radio for Engineers (2018) [pdf]
https://www.analog.com/media/en/training-seminars/design-handbooks/Software-Defined-Radio-for-Engineers-2018/SDR4Engineers.pdf
63 comments
Does anyone have any recommendations for GNU Radio "guides"? I would like one which is a bit hand-holdy but steps through the theory along with a the practical example of building it in GRC, preferably with known good captures of the intended signal so that I don't need to spend time wondering if I've botched my capture somehow.
Are you piping to influx db through ignition?
I've just started getting into SDR - what receivers and transmitters are you using? Would love to give a similar project a go at my place!
If you want to decode transmissions from common weather sensors, be sure to check out rtl_433 [https://github.com/merbanan/rtl_433]. If you have and RTLSDR dongle, it should just work.
RTL-SDR is an inexpensive way to get started, only a receiver though. Transmitters are more complicated (legally) since a lot of spectrum is off limits without a license in most jurisdictions. They have a kit with a couple basic antennas to get you started.
https://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/
https://www.rtl-sdr.com/buy-rtl-sdr-dvb-t-dongles/
The RTL-SDR dongle with GQRX is highly recommended, and go well with a NanoVNA.
https://www.tindie.com/products/hcxqsgroup/4-nanovna-v2-plus...
LimeSDR are a bit more involved, but like most SDR transceivers still need band-pass filters and power amplifiers to perform well. Works well when combined with a GPS locked 10MHz GPSDO like a BG7TBL. =3
https://www.tindie.com/products/hcxqsgroup/4-nanovna-v2-plus...
LimeSDR are a bit more involved, but like most SDR transceivers still need band-pass filters and power amplifiers to perform well. Works well when combined with a GPS locked 10MHz GPSDO like a BG7TBL. =3
I've played around with Gnu Radio, and even though I've been able to do some very sophisticated things with GRC, I also realize just how little I really know. Part of that is that the math makes my head spin. I'd be lost without those blocks doing a lot of the work for me.
If you are serious about getting into SDR, having background in DSP can take you very far. Most of the painful SDR dragons are based in stuff that was optional at university time, but is otherwise not that hard to pick up once you know it exists.
Understanding the frequency domain, why it's useful, and how to get there & back, is like 80% of the puzzle.
Understanding the frequency domain, why it's useful, and how to get there & back, is like 80% of the puzzle.
What do you wish you knew about dsp and frequency back then that you know mow?
Ubiquity of the concepts. I'd have paid more attention if I had known. Things like aliasing, kernels and minimum viable sample rate show up pretty much everywhere.
If you were to give advice / do a talk on more details or areas to apply those suggestions what might they be?
Sorry just trying to get more detail out of you and apply it towards some code to make it practical. :)
Sorry just trying to get more detail out of you and apply it towards some code to make it practical. :)
I think as a counter point, Michael Ossmann, the creator of HackRF One has worked really hard to make it a lot more accessible.
In one of my favorite YT videos ever he talk about how he design RF PCB. The point of it is kind of like, the field of RF and SDR is incredibly deep and complicated, but at the same time, most filters/mixers/amplifiers and everything else needed for making an SDR are ICs that one can buy from Digikey and put them together (or likely have assembled).
So, not denying how deep SDR can be, but it can also be accessible with enough effort!
https://www.youtube.com/watch?v=TnRn3Kn_aXg
In one of my favorite YT videos ever he talk about how he design RF PCB. The point of it is kind of like, the field of RF and SDR is incredibly deep and complicated, but at the same time, most filters/mixers/amplifiers and everything else needed for making an SDR are ICs that one can buy from Digikey and put them together (or likely have assembled).
So, not denying how deep SDR can be, but it can also be accessible with enough effort!
https://www.youtube.com/watch?v=TnRn3Kn_aXg
> weather station that reports temp/humidity/lignthing strikes/rain amount/wind speed+direction, and lux
Do you get this information from radio waves? would love to know more about your setup.
Do you get this information from radio waves? would love to know more about your setup.
Not OP but the idea is simple: You put transmitters somewhere outdoor (or wherever you want to measure) plop a battery in there and be set for a few years.
Such weather stations were really commonplace 20 years ago, I remember my grandparents having a sensor outside and a basic LCD display in the kitchen displaying the outdoor temperature and humidity. These days we want that data digitally on our phones or home assistant so you need a receiver that talks TCP/ip and runs a real os. That's where the SDR comes in to bridge the gap between primitive RF Tech and modern computing. Of course you could also put an esp8266 outdoors, which natively talks wifi, but then you lose range and your battery life goes from years to weeks.
Such weather stations were really commonplace 20 years ago, I remember my grandparents having a sensor outside and a basic LCD display in the kitchen displaying the outdoor temperature and humidity. These days we want that data digitally on our phones or home assistant so you need a receiver that talks TCP/ip and runs a real os. That's where the SDR comes in to bridge the gap between primitive RF Tech and modern computing. Of course you could also put an esp8266 outdoors, which natively talks wifi, but then you lose range and your battery life goes from years to weeks.
Apparently 433mhz environmental sensors is a whole category: https://www.amazon.com/wireless-433Mhz-weather-sensors-Home-...
433MHz is attractive because it's low frequency allows it to propogare farther with less energy input than higher freqs (900MHz; 2.4GHz) would need and does not suffer from nearly as much reflection off of obstacles thanks to that longer wave.
There are several frequency ranges in the US that are unlicensed for transmission. But don't confuse unlicensed with a lack of rules governing what you are allowed to transmit; how often you can transmit and for how long. Because you can plop a 433MHz transceiver into anything, you want to be careful that you're not clogging up the local airwaves by not knowing to know the rules. Also, most smart meters (near me anyway) operat in this band sending out pulses every so often. They mesh together to relay the data towards a central collector. Thanks to that low frequency, hundreds of meters can be visible at times showing up as tiny chirps all over this area of the spectrum. Unfortunately this also means that some cheap receivers (just looking for any signal on a very specific frequency in that range, can be randomly triggered by this 'noise'. But also, because it's used by utilities, to want to make sure they don't end up having an issue with meter readings because you began running a wifi link over 433MHz.
There are several frequency ranges in the US that are unlicensed for transmission. But don't confuse unlicensed with a lack of rules governing what you are allowed to transmit; how often you can transmit and for how long. Because you can plop a 433MHz transceiver into anything, you want to be careful that you're not clogging up the local airwaves by not knowing to know the rules. Also, most smart meters (near me anyway) operat in this band sending out pulses every so often. They mesh together to relay the data towards a central collector. Thanks to that low frequency, hundreds of meters can be visible at times showing up as tiny chirps all over this area of the spectrum. Unfortunately this also means that some cheap receivers (just looking for any signal on a very specific frequency in that range, can be randomly triggered by this 'noise'. But also, because it's used by utilities, to want to make sure they don't end up having an issue with meter readings because you began running a wifi link over 433MHz.
This is a tool for receiving a lot of 433MHz stuff: https://github.com/merbanan/rtl_433
They're using weather stations that broadcast on 433MHz around their property and receive those messages with their SDR, then they pipe that into their database and display system.
Getting some hands on experience with the signal processing side of SDR, with GNU Radio can help with understanding things like negative frequencies, complex signals, etc.
It's open source, and you can just play with your audio ports for starters. Later adding a $40 rtlSDR kit goes a long way. I used mine to build a VOR receiver.
It's open source, and you can just play with your audio ports for starters. Later adding a $40 rtlSDR kit goes a long way. I used mine to build a VOR receiver.
As a pilot with an amateur radio license (though an inexperienced ham) this sounds really interesting. Could you elaborate more on building the VOR receiver?
The transmitter has an electronically switched antenna that virtually moves in a circle at 3600 rpm, causing FM modulation phased with direction. The carrier is also AM modulated with a reference phase signal.
I built a gnu radio flowgraph to receive both and display heading to the VOR.
I built a gnu radio flowgraph to receive both and display heading to the VOR.
Sorry I was working from memory yesterday... It's 1800 rpm / 30 Hz, not 60.
https://en.wikipedia.org/wiki/VHF_omnidirectional_range
https://en.wikipedia.org/wiki/VHF_omnidirectional_range
Woah coming from a dsp / synth background that’s wild to hear.
In terms of software-defined radio learning resources, I can wholly recommend PySDR: https://pysdr.org/
It's written by one of the GNURadio developers, but it uses NumPy and SciPy instead so you really get a feel for the low-level algorithms. Concepts are well explained and build on each other from module to module.
It's written by one of the GNURadio developers, but it uses NumPy and SciPy instead so you really get a feel for the low-level algorithms. Concepts are well explained and build on each other from module to module.
Good resource, thanks.
There's another book namely the RFSoC book complementing this SDR book that's also available for free download.
This newer book focus on the more powerful RFSoC from AMD rather the less powerful but the very popular Adalm Pluto kit by Analog Devices that's being covered in this SDR book.
[1] RFSoC book:
https://www.rfsocbook.com/
This newer book focus on the more powerful RFSoC from AMD rather the less powerful but the very popular Adalm Pluto kit by Analog Devices that's being covered in this SDR book.
[1] RFSoC book:
https://www.rfsocbook.com/
I inherited a HackRF One from a friend and this thread reminded me about it. Does anyone have any cool projects they recommend doing just to gain some experience in SDR / have fun?
I found following these videos through was a good intro: https://m.youtube.com/watch?v=BeeSN14JUYU&pp=ygUII2hhY2tyZmY...
There were a few things in GNU radio which have changed since then (different block names) but with a bit of googling you can figure out how to work around it.
Unfortunately for me, SDR is too much like $dayjob so I lost interest. I already spend 8 hours a day at a computer I cannot be convinced to spend more time at a computer doing SDR as I would much rather being doing stuff outside.
There were a few things in GNU radio which have changed since then (different block names) but with a bit of googling you can figure out how to work around it.
Unfortunately for me, SDR is too much like $dayjob so I lost interest. I already spend 8 hours a day at a computer I cannot be convinced to spend more time at a computer doing SDR as I would much rather being doing stuff outside.
Do SDR stuff outside! Seriously though, I know for ham radio stuff at least, a lot of it can be outside if you want.
For ham radio I can see it, but SDR stuff is fundamentally programming and for me the majority of time was doing programming like tasks and not actually doing stuff with the finished code.
Ham radio on the other hand is like an appliance and so there isn’t any programming necessary.
Ham radio on the other hand is like an appliance and so there isn’t any programming necessary.
Write a FM receiver/transmitter from scratch.
It's very straight forward, depending on your desired level of difficulty: Do it first using blocks in gnuradio, then redo it with blocks you write yourself.
After that do the same thing, but with digital psk modulation, it has the added difficulty of requiring channel estimation/ equalization.
It's very straight forward, depending on your desired level of difficulty: Do it first using blocks in gnuradio, then redo it with blocks you write yourself.
After that do the same thing, but with digital psk modulation, it has the added difficulty of requiring channel estimation/ equalization.
Has anyone work on decoding over-the-air TV digital signal in software? I remember way back there were some cards that can decode OTA signals to be recorded into DVR.
The RTL-SDR was originally intended as a DVB-T receiver, using an app called "BlazeVideo."
Anyway, many, many open source implementations exist for this as it's a popular first/early SDR project. All you'll you need is the right keywords - for the US, ATSC, and for Europe, DVB-T2.
Anyway, many, many open source implementations exist for this as it's a popular first/early SDR project. All you'll you need is the right keywords - for the US, ATSC, and for Europe, DVB-T2.
Yep.
I just dug my RTL SDR v4 out of the drawer right before a trip to Florida. Guess this is a sign to get it going.
I just dug my RTL SDR v4 out of the drawer right before a trip to Florida. Guess this is a sign to get it going.
With something with more bandwidth than an RTL-SDR you may be able to at least capture the data but having dedicated hardware for the target signal is the easiest if you're looking to tune. I've seen POC Analog TV signal decoding but not digital signals in software beyond some exploration and general signal analysis.
GNU Radio comes with receivers for ATSC and DVB-T. You'll need an SDR that can provide 6 MHz (ATSC) or 8 MHz (DVB-T) of bandwidth (which an RTL-SDR cannot do).
DVB-T2 and ATSC 3.0 receivers are too difficult and nothing exists for them.
Here's a screenshot where I'm transmitting to myself (GNU Radio also has an ATSC transmitter).
https://www.w6rz.net/atscdemo.png
DVB-T2 and ATSC 3.0 receivers are too difficult and nothing exists for them.
Here's a screenshot where I'm transmitting to myself (GNU Radio also has an ATSC transmitter).
https://www.w6rz.net/atscdemo.png
> (which an RTL-SDR cannot do)
Is that true? RTL-SDR are derived from a chip designed for DVB-T tuners.
Is that true? RTL-SDR are derived from a chip designed for DVB-T tuners.
Maximum sample rate is 3.2 MS/s.
https://www.rtl-sdr.com/about-rtl-sdr/
https://www.rtl-sdr.com/about-rtl-sdr/
To be clear I’m not doubting you, but how does this square with the fact that these are literal DVS-B tuners? Do they perform some decoding in hardware for this purpose?
The output of the dongle in it's normal DVB-T mode is an MPEG-2 Transport Stream. The maximum bitrate of DVB-T is 31.67 Mbps or ~4 Mbytes/s. It's thought that the USB interface was designed to support that rate and not a whole lot more (3.2 MS/s would be 6.4 Mbytes/s since it's 2 bytes per sample).
The key is that the general-purpose SDR mode is an originally-undocumented test/debug mode. Different drivers are used to access it; the standard DVB-T drivers don't provide access to it.
If always wonder if their was a 4g to 3g converter to keep old devices working when 3g network shut down.
Yes, but very expensive.
https://www.ettus.com/products/
Also the limeSDR are supposed to do this. I had one, it arrived inoperable, I sent it back, never heard from them again. Still a little bitter, because I paid in to the crowdfunding.
https://www.ettus.com/products/
Also the limeSDR are supposed to do this. I had one, it arrived inoperable, I sent it back, never heard from them again. Still a little bitter, because I paid in to the crowdfunding.
Aaaand now I've gone and dropped £35 on an SDR dongle.
GQRX is great
Now you can use one of your unused Raspberry Pi:s (we have all got them) to cobble together an ADSB unit that may be critical in recording important low-height ADSB flight data points in your immediate area in case of accidents.
And also get free premium accounts on sites like flightradar24 etc.
https://hub.balena.io/apps/1829313/balena-ads-b
And also get free premium accounts on sites like flightradar24 etc.
https://hub.balena.io/apps/1829313/balena-ads-b
> Now you can use one of your unused Raspberry Pi:s
I do, in fact, have two. Great suggestions, thank you.
I do, in fact, have two. Great suggestions, thank you.
Wait'll you hear what you can do with 4 SDRs and a raspberry pi...
Small demo https://youtu.be/QBjgTsOrgao?si=jCfL4AnhDGDjBITh
Small demo https://youtu.be/QBjgTsOrgao?si=jCfL4AnhDGDjBITh
> I haven't worked for FAANG in any capacity.
Hah. Love that attitude.
Hah. Love that attitude.
Waste of money. I suggest getting an SDR that can rx AND tx. I recommend the Ettus USRP
You need a mortgage to buy most of their SDRs. Their cheapest IIRC is a B210 which is about $2,500.
The Amazon reviews for this book are bad, but hey, for free!
It's a bit surprising that after 202 upvotes and 51 comments nobody has written any comments about the contents of the linked book. Well, I guess I have to go out on a limb and say it:
This book is embarrassingly awful.
> The Fourier transform is just a different way to describe a signal. For example, investigating the Gibbs phenomenon, which states if you add sine waves at specific frequency/phase/amplitude combinations you can approximate a square wave, can be expressed mathematically as (2.1),...
1. The Gibbs phenomenon doesn't state anything. It can be observed; it exists; it is known; it entails things; it implies things; you can state things about it; but it does not, itself, state anything. It is as mute and voiceless as a nudibranch.
2. What is being described is not the Gibbs phenomenon, but the Fourier transform of a square wave. Now, it is true that the truncated Fourier transform of a square wave does exhibit the Gibbs phenomenon. But so does the truncated Fourier transform of any other function containing discontinuities. It's not specific to square waves.
3. This paragraph starts off trying to ineptly explain what the Fourier transform is (a different way to describe a signal? Different from what?), despite the fact that the previous paragraph provides a different and better explanation which is still not very good, but somehow forgets it was going to do so before getting sidetracked with committing the appalling category errors above on the Gibbs phenomenon.
4. You might reasonably assume that the above paragraph, even if poorly expressed, would be followed by some kind of discussion of what the Gibbs phenomenon is, when it matters, and/or when it arises. You would be disappointed; evidently the authors couldn't remember their undergraduate Signals & Systems courses well enough to remember what the Gibbs phenomenon was.
I had skipped ahead to chapter 2 because I couldn't deal with the mindnumbingly awful crap they stuffed Chapter 1 full of, but it didn't get any better. I have to assume the whole book is this literarily abominable and careless about accuracy.
Analog Devices' apparent choice to promote this book for training material suggests that the company's quality standards are no longer what they historically have been and what allows them to charge such a premium for their parts.
Is there some part of this book that is of passable quality? Please tell me that after some introductory filler chapters they started trying to write coherent sentences? I don't have the heart to check.
To all appearances, the HN comments on this post are both better written and far higher in information density than the book it's ostensibly about.
This book is embarrassingly awful.
> The Fourier transform is just a different way to describe a signal. For example, investigating the Gibbs phenomenon, which states if you add sine waves at specific frequency/phase/amplitude combinations you can approximate a square wave, can be expressed mathematically as (2.1),...
1. The Gibbs phenomenon doesn't state anything. It can be observed; it exists; it is known; it entails things; it implies things; you can state things about it; but it does not, itself, state anything. It is as mute and voiceless as a nudibranch.
2. What is being described is not the Gibbs phenomenon, but the Fourier transform of a square wave. Now, it is true that the truncated Fourier transform of a square wave does exhibit the Gibbs phenomenon. But so does the truncated Fourier transform of any other function containing discontinuities. It's not specific to square waves.
3. This paragraph starts off trying to ineptly explain what the Fourier transform is (a different way to describe a signal? Different from what?), despite the fact that the previous paragraph provides a different and better explanation which is still not very good, but somehow forgets it was going to do so before getting sidetracked with committing the appalling category errors above on the Gibbs phenomenon.
4. You might reasonably assume that the above paragraph, even if poorly expressed, would be followed by some kind of discussion of what the Gibbs phenomenon is, when it matters, and/or when it arises. You would be disappointed; evidently the authors couldn't remember their undergraduate Signals & Systems courses well enough to remember what the Gibbs phenomenon was.
I had skipped ahead to chapter 2 because I couldn't deal with the mindnumbingly awful crap they stuffed Chapter 1 full of, but it didn't get any better. I have to assume the whole book is this literarily abominable and careless about accuracy.
Analog Devices' apparent choice to promote this book for training material suggests that the company's quality standards are no longer what they historically have been and what allows them to charge such a premium for their parts.
Is there some part of this book that is of passable quality? Please tell me that after some introductory filler chapters they started trying to write coherent sentences? I don't have the heart to check.
To all appearances, the HN comments on this post are both better written and far higher in information density than the book it's ostensibly about.
This comment is over-the-top mean and unfair.
Alex was my advisor in grad school and I only know him to be honest, hard working and technically sound. I haven’t read this book closely but I’m not convinced that it’s poorly written based on cherry picking one paragraph from it.
Alex was my advisor in grad school and I only know him to be honest, hard working and technically sound. I haven’t read this book closely but I’m not convinced that it’s poorly written based on cherry picking one paragraph from it.
Maybe someone else was sabotaging his work. Is it possible to cherry-pick one paragraph from it that is well-written and technically sound? Because I gave up after Chapter 1 and the beginning of Chapter 2. Maybe you could ask Alex what he thinks of how the book turned out and post his answer here?
I agree that it's mean, and I feel kind of bad about it, but I think the interests of the hundreds of people who are apparently interested in reading a book about software-defined radio outweigh the interests of the four authors to not have their feelings hurt. The problem is not that they've written this colossal pile of garbage; there's nothing wrong with that, and it's often the first step toward writing something worth reading. The problem is that that pile is being promoted (by Analog Devices, no less) as a useful way to learn about software-defined radio.
I agree that it's mean, and I feel kind of bad about it, but I think the interests of the hundreds of people who are apparently interested in reading a book about software-defined radio outweigh the interests of the four authors to not have their feelings hurt. The problem is not that they've written this colossal pile of garbage; there's nothing wrong with that, and it's often the first step toward writing something worth reading. The problem is that that pile is being promoted (by Analog Devices, no less) as a useful way to learn about software-defined radio.
Great
[deleted]
I know almost nothing about actual SDR, but I've got a cheap SDR receiver/antenna inside a glass basement door that receives temp/humidity data from ~10 433Mhz transmitters in various rooms in my house + outbuildings, and a weather station that reports temp/humidity/lignthing strikes/rain amount/wind speed+direction, and lux. All that goes to an influx DB instance, and has a set of graphana dashboards built on top of it. Took me a couple evenings to get set up, and now I've got real time + historical environment data about everything I care about at my house; including high humidity alerts in rooms with dehumidifiers, freeze warnings for a crawl space, and a bunch of other stuff. It has been wildly reliable.