Tagged: gnuradio

GR-Con17 Talks: GPS Beamforming with RTL-SDRs, Direction Finding with RTL-SDRs on Android and much more

GRCon17 is the yearly convention all about GNU Radio and the talks are generally all about technical cutting edge developments in the software area of the SDR world. If you didn't already know, GNU Radio is an open source tool that makes implementing digital signal processing code significantly easier by providing a framework and several ready to use DSP blocks. It is an advanced tool used a lot in industry and research, but the visual nature of the blocks means that the basics can be easily learned in a few days. See Micheal Ossmans video tutorials for an excellent introduction.

This year at GRCon17 there were multiple interesting talks, and over the last few days videos of them have been released on YouTube. Slides for each presentation are also available in the YouTube description boxes. The full list of presentations can also be found on the Technical Processing page at GNURadio. A selection of our favorites videos are presented below, with several talks utilizing low cost RTL-SDRs as the core radio in the research.

GPS Beamforming with Low-Cost RTL-SDRs - Wil Myrick

In this talk Wil Myrick discusses how he's been using low cost RTL-SDR dongles to perform beamforming experiments with GPS signals.

Real-Time Direction Finding Using Two Antennas on an Android Phone - Sam Whiting

In this talk Sam Whiting shows how he used two coherent RTL-SDR dongles running on on an Android phone for direction finding. At the end of the video he demonstrates his results.

Hacking the Wireless World 4.0 - Balint Seeber

In this video Balint Seeber continues with his popular Hacking the Wireless World series of talks and this time talks about FMCW & Passive Radar and FPV decoding with SDRs.

ADALM-PLUTO SDR: Unboxing and Initial Testing

The PlutoSDR (aka ADALM-PLUTO) is a new RX and TX capable SDR from Analog Devices who are a large semiconductor manufacturer. The PlutoSDR covers 325 – 3800 MHz, has a 12-bit ADC with a 61.44 MSPS sampling rate and 20 MHz bandwidth. It is also priced at the bargain price of only $99 USD over on Digikey, although it seems they only produced a small batch as at the moment they seem to be already sold out. This may also be a promotional price, with the normal price $149 USD as that is the price we see on the analog.com store. But even at $149 the value for what you get is very high.

A few months ago we preordered a PlutoSDR from the analog.com store, and it was received it a few days ago.

Unboxing

plutosdr_unbox1
plutosdr_unbox2
pluto_pcb2
pluto_pcb1

The unit comes in a nice professionally designed cardboard box. Inside is the unit itself, two small 4cm long whip antennas a short 15 cm SMA cable and USB cable. The PlutoSDR unit itself comes in a blue plastic box which measures 11.7 x 7.9 x 2.4 cm and weighs 114 g in total. Two SMA ports are available, one for RX and one for TX. At the other end are two LEDs, a USB port and a power only USB port.

The PCB itself looks to be designed nicely. On the PCB you can see the main AD9363 front end chip, which is actually a 2 x 2 transceiver chip. It supports a tunable channel bandwidth of up to 20 MHz. The other chip is the ZYNQ XC7Z010 which is an ‘All Programmable SoC’. This is an FPGA, processor and ADC for the unit.

Hardware

The PlutoSDR can tune from 325 to 3800 MHz. It has an ADC which can sample at up to 61.44 MSPS with a resolution of 12-bits. There is no TCXO used, so the frequency accuracy is only 25 PPM. Although the maximum sample rate is 61.44 MSPS, the front end AD9363 only has a maximum signal bandwidth of 20 MHz, so that limits the available bandwidth.

For TXing, a claimed TX power of up to 7 dBm is available which is comparable to the TX power of the HackRF.

The unit has no shielding on it via PCB cans or a metal box, so may pick up spurious signals. However, for the intended purpose of learning and testing, no shielding is fine.

Software

Unfortunately software for the PlutoSDR is quite lacking. At the moment there is only really support for MATLAB and GNURadio.

That’s quite understandable however as the PlutoSDR is designed and promoted as a ‘learning module’ or in other words a device for students to learn with. However, if software support for SDR#, HDSDR, SDR-Console, GQRX etc was available it would also make a great unit that could not only compete with the HackRF and LimeSDR SDRs, but also perhaps the Airspy and SDRplay RSP RX only units, at least for UHF applications above 325 MHz.

In a previous post in February we’ve seen on Twitter that Alex Csete (programmer of GQRX) has had his PlutoSDR running on GQRX, but it seems the current public release does not yet support the PlutoSDR (please correct me if i’m wrong!).

The documentation is mostly all available on the PlutSDR wiki. However documentation for setting the unit up with MATLAB and GNURadio, and examples for actually using it is also still quite poor. There is a quickstart guide, but this barely helped. Presumably once more units ship out the documentation will be enhanced. 

To install the PlutoSDR drivers on Linux we used the instructions kindly provided by xavier_505 in this Reddit thread. Once GNU Radio was installed, installation of the gr-iio driver was as simple as running the two lines provided in the thread.

Testing

We’ve given the PlutoSDR a few tests in Linux with GNURadio, and very quickly with the ADI IIO Oscillioscope software for Windows.

In GNU Radio the PlutoSDR source can be found under the “Industrial IO” heading in the block menu on the right, or simply by doing CTRL+F “Pluto”.

One important note is that when using the source you need to set the “Device URI” to ip:pluto.local. This feature presumably allows you to control multiple devices via the network, but for now we’re just using it locally. Also, this may have been a problem related to running Linux in VMWare, but PlutoSDR creates new “Wired Connection” in Linux and we had to always remember to set the network connection to the PlutoSDR using the the network selector in the Linux taskbar for the network to be able to see it.

First we tested a simple FFT and Waterfall sink using the PlutoSDR source. We set the sample rate to the maximum of 61.44 MSPS, and the RF bandwidth to 60M (although the max is 20 MHz). The demo ran well and we were able to see the 900 MHz GSM band. It seems the max sample rate is not used as the output is only 30 MHz, or perhaps it’s only one ADC.

Next we adapted a simple FM receiver from csetes GNU Radio examples by replacing the USRP source file with the PlutoSDR. After adjusting the decimation we were able to receive NBFM clearly.

Next we tried adapting a simple transmit test by creating a flowgraph that would transmit a .wav file in NBFM mode using the PlutoSDR Sink. Again this ran easily and we were able to verify the output in SDR# with an RTL-SDR. No harmonics were found (the one seen in the screenshot is a harmonic from the RTL-SDR).

Finally we tested using the PlutoSDR ADI IIO Oscilloscope software and were able to generate a FFT spectrum of the GSM band.

pluto_waterfall
pluto_rx_test
pluto_TX_test
pluto_ADI_IIO_Oscilloscope

Conclusion

This is a very nice SDR with good specs and a very very attractive price. However, it is mostly aimed at experimenters and students and you’ll need to be comfortable with exploring GNU Radio and/or MATLAB to actually use it. If you’re okay with that, then adapting various GNU Radio programs to use the PlutoSDR is quite easy.

In the future hopefully some programmers of general purpose receiving programs like SDR#/GQRX etc will release modules to support this unit too.

This is a good alternative to more expensive experimenter TX/RX SDR units like the HackRF and LimeSDR, although you do lose out on frequencies below 325 MHz.

GR-Con17 Talks: GPS Beamforming with RTL-SDRs, Direction Finding with RTL-SDRs on Android and much more

GRCon17 is the yearly convention all about GNU Radio and the talks are generally all about technical cutting edge developments in the software area of the SDR world. If you didn't already know, GNU Radio is an open source tool that makes implementing digital signal processing code significantly easier by providing a framework and several ready to use DSP blocks. It is an advanced tool used a lot in industry and research, but the visual nature of the blocks means that the basics can be easily learned in a few days. See Micheal Ossmans video tutorials for an excellent introduction.

This year at GRCon17 there were multiple interesting talks, and over the last few days videos of them have been released on YouTube. Slides for each presentation are also available in the YouTube description boxes. The full list of presentations can also be found on the Technical Processing page at GNURadio. A selection of our favorites videos are presented below, with several talks utilizing low cost RTL-SDRs as the core radio in the research.

GPS Beamforming with Low-Cost RTL-SDRs - Wil Myrick

In this talk Wil Myrick discusses how he's been using low cost RTL-SDR dongles to perform beamforming experiments with GPS signals.

Real-Time Direction Finding Using Two Antennas on an Android Phone - Sam Whiting

In this talk Sam Whiting shows how he used two coherent RTL-SDR dongles running on on an Android phone for direction finding. At the end of the video he demonstrates his results.

Hacking the Wireless World 4.0 - Balint Seeber

In this video Balint Seeber continues with his popular Hacking the Wireless World series of talks and this time talks about FMCW & Passive Radar and FPV decoding with SDRs.

ADALM-PLUTO SDR: Unboxing and Initial Testing

The PlutoSDR (aka ADALM-PLUTO) is a new RX and TX capable SDR from Analog Devices who are a large semiconductor manufacturer. The PlutoSDR covers 325 – 3800 MHz, has a 12-bit ADC with a 61.44 MSPS sampling rate and 20 MHz bandwidth. It is also priced at the bargain price of only $99 USD over on Digikey, although it seems they only produced a small batch as at the moment they seem to be already sold out. This may also be a promotional price, with the normal price $149 USD as that is the price we see on the analog.com store. But even at $149 the value for what you get is very high.

A few months ago we preordered a PlutoSDR from the analog.com store, and it was received it a few days ago.

Unboxing

plutosdr_unbox1
plutosdr_unbox2
pluto_pcb2
pluto_pcb1

The unit comes in a nice professionally designed cardboard box. Inside is the unit itself, two small 4cm long whip antennas a short 15 cm SMA cable and USB cable. The PlutoSDR unit itself comes in a blue plastic box which measures 11.7 x 7.9 x 2.4 cm and weighs 114 g in total. Two SMA ports are available, one for RX and one for TX. At the other end are two LEDs, a USB port and a power only USB port.

The PCB itself looks to be designed nicely. On the PCB you can see the main AD9363 front end chip, which is actually a 2 x 2 transceiver chip. It supports a tunable channel bandwidth of up to 20 MHz. The other chip is the ZYNQ XC7Z010 which is an ‘All Programmable SoC’. This is an FPGA, processor and ADC for the unit.

Hardware

The PlutoSDR can tune from 325 to 3800 MHz. It has an ADC which can sample at up to 61.44 MSPS with a resolution of 12-bits. There is no TCXO used, so the frequency accuracy is only 25 PPM. Although the maximum sample rate is 61.44 MSPS, the front end AD9363 only has a maximum signal bandwidth of 20 MHz, so that limits the available bandwidth.

For TXing, a claimed TX power of up to 7 dBm is available which is comparable to the TX power of the HackRF.

The unit has no shielding on it via PCB cans or a metal box, so may pick up spurious signals. However, for the intended purpose of learning and testing, no shielding is fine.

Software

Unfortunately software for the PlutoSDR is quite lacking. At the moment there is only really support for MATLAB and GNURadio.

That’s quite understandable however as the PlutoSDR is designed and promoted as a ‘learning module’ or in other words a device for students to learn with. However, if software support for SDR#, HDSDR, SDR-Console, GQRX etc was available it would also make a great unit that could not only compete with the HackRF and LimeSDR SDRs, but also perhaps the Airspy and SDRplay RSP RX only units, at least for UHF applications above 325 MHz.

In a previous post in February we’ve seen on Twitter that Alex Csete (programmer of GQRX) has had his PlutoSDR running on GQRX, but it seems the current public release does not yet support the PlutoSDR (please correct me if i’m wrong!).

The documentation is mostly all available on the PlutSDR wiki. However documentation for setting the unit up with MATLAB and GNURadio, and examples for actually using it is also still quite poor. There is a quickstart guide, but this barely helped. Presumably once more units ship out the documentation will be enhanced. 

To install the PlutoSDR drivers on Linux we used the instructions kindly provided by xavier_505 in this Reddit thread. Once GNU Radio was installed, installation of the gr-iio driver was as simple as running the two lines provided in the thread.

Testing

We’ve given the PlutoSDR a few tests in Linux with GNURadio, and very quickly with the ADI IIO Oscillioscope software for Windows.

In GNU Radio the PlutoSDR source can be found under the “Industrial IO” heading in the block menu on the right, or simply by doing CTRL+F “Pluto”.

One important note is that when using the source you need to set the “Device URI” to ip:pluto.local. This feature presumably allows you to control multiple devices via the network, but for now we’re just using it locally. Also, this may have been a problem related to running Linux in VMWare, but PlutoSDR creates new “Wired Connection” in Linux and we had to always remember to set the network connection to the PlutoSDR using the the network selector in the Linux taskbar for the network to be able to see it.

First we tested a simple FFT and Waterfall sink using the PlutoSDR source. We set the sample rate to the maximum of 61.44 MSPS, and the RF bandwidth to 60M (although the max is 20 MHz). The demo ran well and we were able to see the 900 MHz GSM band. It seems the max sample rate is not used as the output is only 30 MHz, or perhaps it’s only one ADC.

Next we adapted a simple FM receiver from csetes GNU Radio examples by replacing the USRP source file with the PlutoSDR. After adjusting the decimation we were able to receive NBFM clearly.

Next we tried adapting a simple transmit test by creating a flowgraph that would transmit a .wav file in NBFM mode using the PlutoSDR Sink. Again this ran easily and we were able to verify the output in SDR# with an RTL-SDR. No harmonics were found (the one seen in the screenshot is a harmonic from the RTL-SDR).

Finally we tested using the PlutoSDR ADI IIO Oscilloscope software and were able to generate a FFT spectrum of the GSM band.

pluto_waterfall
pluto_rx_test
pluto_TX_test
pluto_ADI_IIO_Oscilloscope

Conclusion

This is a very nice SDR with good specs and a very very attractive price. However, it is mostly aimed at experimenters and students and you’ll need to be comfortable with exploring GNU Radio and/or MATLAB to actually use it. If you’re okay with that, then adapting various GNU Radio programs to use the PlutoSDR is quite easy.

In the future hopefully some programmers of general purpose receiving programs like SDR#/GQRX etc will release modules to support this unit too.

This is a good alternative to more expensive experimenter TX/RX SDR units like the HackRF and LimeSDR, although you do lose out on frequencies below 325 MHz.

gr-clenabled: OpenCL GPU Blocks for GNU Radio

Yesterday Mike (ghostop14) submitted to us by email a document that gives an overview of his experiments on rewriting several GNU Radio blocks to take advantage of OpenCL GPU acceleration. High end discrete gaming GPU’s (Graphics Processing Unit) on PC’s are a very powerful parallel processors which can be significantly faster at performing calculations than the general purpose CPU. But only algorithms that can be parallelized are worth running on the GPU, and there is an additional overhead to pass the data between the CPU and GPU. This means that only some algorithms will actually work faster on the GPU. GPU acceleration could be part of the key to allowing very high bandwidth SDRs to run on PC’s.

In Mike’s experiments he accordingly found that only some GNU Radio blocks could be accelerated by the GPU. Many blocks ran more slowly on the GPU due to the additional overheads. In the end the blocks he tested that showed actual or at least mixed acceleration were: 

  1. Log10
  2. Complex To Arg
  3. Complex To Mag/Phase
  4. A custom Signal To Noise Ratio Helper that executes a divide->Log10->Abs sequence
  5.  Mag/Phase To Complex (OpenCL performed better only for blocks above 8K for the 1070, and 18K for the 970 and 1000M)
  6. Signal Source (OpenCL outperformed CPU only for the 1070 for 8K blocks and above)
  7. Quadrature Demodulation (OpenCL performed better only for blocks above 10K)

The project is called gr-clenabled, and the open source code for gr-clenabled is available over on GitHub. A document documenting a full study of the implementation and performance of GPU GNU Radio blocks can be found here. Below is an excerpt from Mike’s overview document (if you want more information we suggest reading the overview first, and then the full study document):

About 4 months ago I decided to take on a project that I had wished existed for some time. With all of the code available for using graphics cards for signal processing why were there not a wealth of GPU-accelerated blocks for GNURadio? Really leveraging my new graphics card (an NVIDIA GTX 1070), couldn’t I drive 80 MSPS or higher through if I had hardware that could supply it? (I know USB 2.0 bus speeds, some decoders require hardware for speed, etc. but an SDR enthusiast can still dream)

My idea seemed simple enough. Why not develop OpenCL versions of the most common blocks used in digital data processing? I may not hit my throughput goal but I bet I can really accelerate my flowgraphs. And since I can dream up whatever I want before I have to actually make it, why not make it even more scalable? Why not be able to take full advantage of multiple graphics cards in a system by being able to assign different blocks to run on different cards?

I know, that’s a lot of questions, but sounds great if it existed right? What I didn’t realize was the scope of the box I was about to open. My first task at hand was to learn OpenCL and REALLY dig into the depths of the GNURadio code. Turns out not all signal processing algorithms lend themselves nicely to the way massively parallel processing works. And there’s a time price to pay to move data to a PCI card for processing then retrieve the results that has to be considered. Some native blocks take longer than this transfer time to run and can benefit from offloading, while others are so fast they’re done before a GPU even gets the data. But I’m getting ahead of myself here.

Throughput of the log10 GNU Radio block on various different GPU's at different block sizes.
Throughput of the log10 GNU Radio block on various different GPU’s at different block sizes.

RFTap: A Bridge Between GNURadio and Wireshark

Recently a new Linux based tool called RFTap has been released. RFTap acts as a bridge between GNURadio flow graphs and Wireshark. GNU Radio is a visual based programming environment for digital signal processing applications, such as RF signal decoders. GNURadio supports many different SDR’s including the RTL-SDR. Wireshark is a network packet analyzer/dissector that aides with troubleshooting and analysis of network protocols. RFTap also supports other DSP languages like Pothos, liquidsdr, LuaRadio as well as other packet analyzers like TShark, tcpdump, Scapy.

The author has already released three RFTap tutorials/demos. The first shows how to decode Radio Data System (RDS) and use RFTap and Wireshark to dissect each packet. The second shows how to use RFTap and Wireshark to detect MAC spoofing on WiFi networks. For that tutorial you will need a more advanced SDR that can tune to the 5 GHz WiFi frequencies and receive the full WiFi bandwidth of 20 MHz. The third tutorial shows how to use RFTap to analyze Zigbee packets.

RFTap acts as the glue between GNURadio and Wireshark
RFTap acts as the glue between GNURadio and Wireshark

GNU Radio Conference 2015: Presentations

The GNU Radio conference (GRCon15) is a yearly conference discussing all matters related to GNU Radio, an open source graphical block based DSP programming application that is compatible with most SDR’s, including the RTL-SDR. The conference started on August 24 and is due to close this Friday August 28, however many of the presentation slides are now available for viewing on their website.

This year there are many interesting talks, including a speech by Balint about radio direction finding, RF sniffing and digital FPV on drones. There are also several tutorial presentations that show how to install GNU Radio, how DSP sampling works, an intro to analog RF concepts and how to build a software radio from scratch.

gnuradio

Using the RTL-SDR to help Program a TI Chronos RF Watch

Over on our Facebook page, member Александр has posted about a project he found by Georg Campana which involves using an RTL-SDR to capture signals from his TI Chronos watch which has a programmable 433 MHz RF transmitter built into it.

Georg used his TI Chronos watch to transmit a signal copied from remote controls which are used to open his house gate, garage door, light switches and set his house alarm. When he discovered that the watch signal was not transmitting properly, he used his RTL-SDR to compare the signal coming from the watch to the original signals from the remote controls to help him with debugging. In order to detect the bit stream from the RF signal, he used a GNURadio program for decoding wireless temperature sensors, which he modified slightly to work with his watch.

Tools used to program the TI Chronos watch
Tools used to program the TI Chronos watch

Locating an Interfering Signal with Radio Direction Finding and the RTL-SDR

The people at the MIT Haystack Observatory discovered recently that someone was transmitting an interfering signal on their licensed radar band. The interferer was effectively jamming the radar, preventing them from carrying out any experiments.

After checking for local causes of interference and finding nothing, they decided that the interferer must be coming from further away. To find the location of the jamming signal they did some radio direction finding. This involved driving around with Yagi and magnetic loop antennas and RTL-SDR and USRP N200 SDRs and then measuring the signal strength at various points.

For the software they used a custom GNURadio block which calculated the power spectra using the FFTW C library, and averaged the results to disk. They then post processed the data to calculated the RFI power, and correlated the data with GPS coordinates recorded on his phone.

After all the data was processed, they discovered that the interference originated from an FM radio tower which had a faulty FSK telemetry link. They notified the engineer responsible who then replaced the link and the interference disappeared.

RFI strength at various geographic locations
RFI strength at various geographic locations