Using the GRAVES Radar to Listen to Reflections from Meteors, Planes and Spacecraft

Over on his blog DK8OK has created a post that explains how European SDR users can use their devices to monitor reflections coming off the Graves space radar. Graves is a space surveillance radar based in France which is designed to track spacecraft and orbital debris.

If you are in Europe you can also make use of the Graves radar simply by tuning to its frequency of 143.050 MHz and listening for reflections of its signal bouncing off things like meteors, planes and spacecraft. Since Graves points its signal upwards, it’s unlikely that you’ll directly receive the signal straight from the antenna, instead you’ll only see the reflections from objects.

DK8OK also explains in his post how you can use SDR-Console V3 to create a level diagram which shows power vs time, allowing you to count reflections and visualize the response of the reflection.

Any SDR that can tune to VHF frequencies such an an RTL-SDR can be used for monitoring reflections like this. If you aren’t in Europe you might consider looking for distant strong transmitters such as for TV/FM which you could also monitor for reflections.

Graves reflection of a meteor trail visualized in SDR-Console V3.
Graves reflection of a meteor trail visualized in SDR-Console V3.

SDR Academy Talks: RPiTX TX for the Masses, Transmitter Localization with TDOA, HackRF as a Signal Generator and more

Over on YouTube the Software Defined Radio Academy channel has uploaded some new interesting SDR related conference talks, some of which may be of interest to readers. Some of our favorites are posted below. Other new interesting talks from channel include:

  • Derek Kozel, AG6PO, Ettus: Hardware Accelerated SDR: Using FPGAs for DSP (Link)
  • Mario Lorenz, DL5MLO: Across the Solar System – using SDRs for real long-distance communication (Link)
  • Andras Retzler, HA7ILM: Demodulators from scratch: BPSK31 and RTTY (Link)
  • Gerald Youngblood, K5SDR (President of FlexRadio): Direct Sampling and Benefits of the Architecture (Link)
  • Dr. Selmeczi Janos, HA5FT: A new lightweight data flow system (Link)
  • Chris Dindas, DG8DP: Standalone SDR-TRX, Highend – Lowcost – Homebrew (Link)
  • Erwin Rauh, DL1FY: Charly25 – SDR Transceiver Project – Community Development (Link)
  • Črt Valentinčič, S56GYC, Red Pitaya: HamLab (Link)

Evariste Courjaud, F5OEO: Rpitx : Raspberry Pi SDR transmitter for the masses

Low cost RTL-SDR democratize access to SDR reception, but is there an equivalent low cost solution for transmission : Rpitx is a software running on Raspberry Pi which use only GPIO to transmit HF. This presentation describes how to use it as a SDR sink but also describes details of how it is implemented using PLL available on the Raspberry Pi board. Warnings and limits of this simple SDR are also provided before going “on air”. Last paragraph shows what are potential evolutions of this system : low cost DAC and third party software integration.

Evariste Courjaud, F5OEO: Rpitx : Raspberry Pi SDR transmitter for the masses

Stefan Scholl, DC9ST: Introduction and Experiments on Transmitter Localization with TDOA

Time-Difference-of-Arrival (TDOA) is a well-known technique to localize transmitters using several distributed receivers. A TDOA system measures the arrival time of the received signal at the different receivers and calculates the transmitter’s position from the delays. The talk first introduces the basics of TDOA localization. It shows how to measure signal delay with correlation and how to determine the position using multilateration. It also covers further aspects and challenges, like the impact of signal bandwidth and errors in delay measurement, receiver placement and synchronization as well as the requirements on the network infrastructure. Furthermore, an experimental TDOA system consisting of three receivers is presented, that has been setup to localize signals in the city of Kaiserslautern, Germany. The three receivers are simple low-cost devices, each built from a Raspberry PI and a RTL/DVB-USB-Stick. They are connected via internet to a master PC, which performs the complete signal processing. The results demonstrate, that even with a simple system and non-ideal receiver placement, localization works remarkably well.

Stefan Scholl, DC9ST: Introduction and Experiments on Transmitter Localization with TDOA

Frank Riedel, DJ3FR: The HackRF One as a Signal Generator

The usability and performance of the HackRF One SDR experimental platform as a signal generator up to 6 GHz is examined by means of an HPIB driven measurement system. The effective circuit of the HackRF One used in the CW TX mode is described and its components are linked to the parameters of the command line tool ‘hackrf_transfer’. The frequency accuracy of the HackRF One is measured against a frequency standard, output signal levels and spurious emissions are determined using a spectrum analyzer.

Frank Riedel, DJ3FR: The HackRF One as a Signal Generator

A showcase of our Metal RSP-1 Enclosure

Back in March of this year together with Mike (KD2KOG) we brought out a metal enclosure for the SDRplay RSP1. The enclosure includes a BCFM filter as well as a nice carry case. We’ve been collecting a few images of users using this enclosure, and this is simply a picture showcase of those images.

If you’re interested in the enclosure we still have some limited stock remaining over on our store at www.rtl-sdr.com/store.

Some Further Tests with the ADALM-PLUTO SDR

Last week we posted about the unboxing of the ADALM-PLUTO SDR as well as some information about a hack that can be used to increase the tuning and bandwidth range of the SDR. In this post we show some initial tests and first impressions of the the receive performance of the SDR.

We tested the PlutoSDR on a number of frequencies, some in the default tuning range, and some in the frequencies enabled by the hack. In terms of sensitivity not much difference was noticed in the expanded frequencies. Sensitivity overall is decent and seems to be comparable to other SDRs. However, the PlutoSDR does suffer quite heavily from out of band imaging. Although there is a 12-bit ADC being used, filtering is still necessary for many signals. Broadcast FM, DAB, HDTV and GSM are all very problematic and images of these signals can be found all over the spectrum if they are strong. Above about 800 MHz two broadcast FM stations show up in the exact same place at all frequencies, no matter the gain setting.

Imaging is probably expected as the IIP3 spec of the AD9363 RF chip used in the PlutoSDR is not that great at only -18 dBm at max gain. Other SDRs like the Airspy Mini and RSP2 don’t have imaging anywhere as bad as the PlutoSDR as they have naturally high dynamic range in the case of the Airspy and filter banks built-in in the case of the RSP2.

Below are some example screenshots of the imaging we saw from strong signals. We used SDR# with the new PlutoSDR plugin, and set the sampling rate to 3 MSPS. On these screenshots we note that turning down the gain did not help, so these images were present in some way no matter the gain settings. There is probably still some optimization to go in the SDR# plugin, so it’s possible that imaging could be reduced with further work.

DAB Appearing at 79 MHz
GSM at 133 MHz
No imaging here (see next slide)
But moved 1 MHz up and there is heavy imaging
GSM @ 315 MHz
BCFM Pulsing in at 415 MHz
BCFM interference shows up like this at all frequencies above 800 MHz
DAB Appearing at 79 MHz GSM at 133 MHz No imaging here (see next slide) But moved 1 MHz up and there is heavy imaging GSM @ 315 MHz BCFM Pulsing in at 415 MHz BCFM interference shows up like this at all frequencies above 800 MHz

To test sensitivity we recorded audio on a few weak signals that did not have any images present, and we kept the gain at the highest it could go without the noise floor rising or images showing up.

Again we used SDR# with the PlutoSDR plugin, and set the sampling rate to 3 MSPS. We note that anything higher than 4 MSPS causes lost samples and thus jittery audio as this is the hardware limit of the PlutoSDR.

BCFM

This is a weak BCFM station. The PlutoSDR actually seemed to receive it better than the Airspy Mini. The RSP2 could not receive it, and the weak audio heard on the RSP2 is audio from an image.

PlutoSDR
Airspy Mini
SDRplay RSP2
PlutoSDR Airspy Mini SDRplay RSP2

161 MHz

This is a voice weather station. Here the PlutoSDR was very comparable to the Airspy Mini and RSP2. Not much sensitivity degradation in the ‘hacked’ expanded frequency range.

PlutoSDR
Airspy Mini
SDRplay RSP2
PlutoSDR Airspy Mini SDRplay RSP2

858 MHz

This is a digital trunking signal (there was no stable voice source this high to test with). Sensitivity is about the same as the other SDRs.

PlutoSDR
Airspy Mini
SDRplay RSP2
PlutoSDR Airspy Mini SDRplay RSP2

BCAM (Night)

A night time BCAM test. The PlutoSDR was coupled with a SpyVerter. Performance was quite good and on par with the Airspy Mini.

PlutoSDR
Airspy Mini
SDRplay RSP2
PlutoSDR Airspy Mini SDRplay RSP2

L-Band

Tested reception with a L-band patch antenna (no external LNA). Tested STD-C reception too. The PlutoSDR worked very well on L-band and had similar performance to the SDRplay. The Airspy is not good at L-band without an LNA and could not receive the STD-C channel by itself.

PlutoSDR
PlutoSDR STD-C
Airspy Mini
SDRplay RSP2
SDRplay RSP2 STD-C
PlutoSDR PlutoSDR STD-C Airspy Mini SDRplay RSP2 SDRplay RSP2 STD-C

Conclusion

It’s clear that the PlutoSDR wasn’t made to be a general purpose high performance SDR, but rather a hackers/experimenters/learning SDR.  Performance in terms of out of band imaging is not great, and for any real listening filters may be required. That said, the performance is overall still not bad and overall still a bit better than an RTL-SDR or HackRF. With filtering the performance could be comparable to something like the Airspy Mini or SDRplay RSP2. Performance on L-band is very good, assuming you can filter or use a directional antenna to attenuate strong blocking signals. It’s also possible that further tweaks to the filter settings of the SDR# PlutoSDR plugin could improve imaging problems.

It’s also a bit disappointing that the maximum sample rate available is only 4 MSPS without drops. So this is the highest rate that you can use if you want to decode a signal, or listen to audio. For wideband waterfalls or spectrum analysis or other applications tolerant to dropped samples it should be possible to go up to the full 61.44 MSPS.

All in all, if you are interested in a low cost wideband SDR that does almost everything including TX, and are not too concerned about strong signals, images and overload, then this is still a great purchase at $99 USD (Digikey out of stock now, available for $149 on the Analog.com store). This SDR should be especially interesting to you if you are an SDR hacker/experimenter/student or are a fan of cheap SDRs/RTL-SDR/HackRF etc. If you are a ham or DXer and want something that just works with your high performance antennas and strong signals then you might look elsewhere.

On Twitter others have come to similar conclusions.

PlutoSDR SDR# Plugin + New Dual Core CPU Hack

A new plugin for SDR# has been released which allows SDR# to be used with the ADALM-PLUTO SDR. To use the plugin you’ll have to apply the frequency range hack first, which allows the PlutoSDR to tune to 70 – 6000 MHz. Then simply extract the plugin to the SDR# directory and add the key to the FrontEnds.xml file.

We tested the plugin out and found that it worked well with our PlutoSDR. The interface allows you to set the sample rate up to 19 MSPS, but anything over 4 MSPS causes dropped samples and anything over 5 MSPS is labelled as not supported. The advertised hardware limit of the PlutoSDR with no dropped samples is 4 MSPS, and we did notice audio jitter at 5 MSPS and above. Anything higher than 5 MSPS shows noticeable jitter in the waterfall display too. Note that this is not a problem of the plugin or SDR#, but rather of the hardware limitations.

Over on the PlutoSDR forums user jocover also discovered a new hack which allows you to enable dual-core support on the PlutoSDR. It’s not clear if this helps with anything useful yet, but maybe useful for some custom applications that make use of the CPU.

PlutoSDR running in SDR#
PlutoSDR running in SDR#

Receiving the Bitcoin Blockchain from Satellites with an RTL-SDR

Bitcoin is the worlds first and most popular digital currency. It is steadily gaining in value and popularity and is already accepted in many online stores as a payment method. In order to use Bitcoin you first need to download a large database file called a ‘blockchain’, which is currently at about 152 GB in size (size data obtained here). The blockchain is essentially a public ledger of every single Bitcoin transaction that has ever been made. The Bitcoin software that you install initially downloads the entire blockchain and then constantly downloads updates to the blockchain, allowing you to see and receive new payments.

Blockstream is a digital currency technology innovator who have recently announced their “Blockstream satellite” service. The purpose of the satellite is to broadcast the Bitcoin blockchain to everyone in the world via satellite RF signals, so that even in areas without an internet connection the blockchain can be received. Also, one problem with Bitcoin is that in the course of a month the software can download over 8.7 GB of new blockchain data, and there is also the initial 152 GB download (although apparently at the moment only new blocks are transmitted). The satellite download service appears to be free, so people with heavily metered or slow connections (e.g. 3G mobile which is the most common internet connection in the third world/rural) can benefit from this service as well.

The service appears to be somewhat similar to the first iteration of the Outernet project in that data is broadcast down to earth from satellites and an R820T RTL-SDR is used to receive it. The blockstream satellite uses signals in the Ku band which is between 11.7 to 12.7 GHz. An LNB is required to bring those frequencies back down into a range receivable by the RTL-SDR, and a dish antenna is required as well. They recommend a dish size of at least 45 cm in diameter. The signal is broadcast from already existing satellites (like Outernet they are renting bandwidth on existing satellites) and already 2/3 of the earth is covered. The software is based on a GNU Radio program, and can be modified to support any SDR that is compatible with GNU Radio. They write that the whole setup should cost less that $100 USD to purchase and set up.

To set it up you just need to mount your satellite antenna and point it towards the satellite broadcasting the signal in your area, connect up your LNB and RTL-SDR and then run the software on your PC that has GNU Radio installed.

More details can be found on the Blockstream Satellite website, and technical details about the software and hardware required can be found on their GitHub page.

How the Blockchain satellite works (From https://blockstream.com/satellite/howitworks/)
How the Blockchain satellite works (From blockstream.com/satellite/howitworks/)

Some may wonder what’s the point if you can’t transmit to the service to make payments with it. Over on this Bitcoin Reddit thread user “ideit” explains why it’s still useful in this nice quote.

You sell goats in a small village. A customer wants to buy a goat, but you have no banks so people have put their money into bitcoin. Your customer goes to the village center which has a few computers hooked up to the internet. He sends you payment then comes to get his goat. You don’t have internet near your goat farm, but you’re connected to the satellite so you can see he sent you payment and you give him his goat.

Or, you live in an area that caps your bandwidth. You want to run a full node, but downloading blocks eats away at your cap. Connecting to a satellite reduces your bandwidth usage.

Or, you’re using an air gapped laptop to sign transactions from your wallet for security reasons. You can now connect that laptop to the satellites so your laptop can generate its own transactions without connecting to the internet.

Or, your internet connection is terrible. You can usually broadcast transactions since they’re small, but downloading blocks and staying in sync with the blockchain is literally impossible. Connect to a satellite and now it’s simple.

ADALM-PLUTO SDR Hack: Tune 70 MHz to 6 GHz and GQRX Install

Yesterday we posted an unboxing and a few tests with the PlutoSDR. On that post user rlwsdr commented and informed us that’s it’s actually possible to do a quick hack that changes the frequency range and bandwidth from 325 – 3800 MHz and 20 MHz up to 70 MHz to 6000 MHz and 56 MHz bandwidth. All that is needed to perform this hack is setting a device string on the PlutoSDR via a USB serial connection. This hack has been confirmed by Alex Csete and others on Twitter and ourselves. It works for both RX and TX.

Alexander Csete (programmer of GQRX) also posted instructions in a comment on our last post that explained how to get GQRX running with the PlutoSDR. 

Also in the last post we mentioned that all distributors were out of stock, but a few hours after that post went out Digikey restocked and they now have (at the time of this post) 184 units left at the $99 USD price.

Frequency and Bandwidth Hack

Thanks to ‘rlwsdr’ and Alexandru Csete for bringing attention to this hack.

It seems that the current shipping version of the PlutoSDR uses the AD9363 chip which is restricted to a frequency range of 325 – 3800 MHz and bandwidth of 20 MHz. However, the higher end AD9364 chip which can support 70 MHz to 6000 MHz and 56 MHz of bandwidth is supposedly nearly identical to the AD9363 chip. The PlutoSDR can be tricked into seeing a AD9364 chip simply by changing a device string on the unit, but it’s not guaranteed to give the full tuning range and bandwidth for every single unit. It’s possible that the AD9363 chips are actually AD9364 chips that failed performance QC checks and have just been rebranded as a lower end model, or that a cheaper silicon process is used with the lower end chip.

The instructions for performing this hack are actually detailed by the official Analog.com PlutoSDR wiki on the customization page. Just search for the heading “Updating to the AD9364”. The instructions state that this is only for older PlutoSDR units which actually came with the AD9364 chip, but it seems to work with the newer PlutoSDR units that have the AD9363 chips as well.

Simply plug the PlutoSDR in, and connect to it via a serial connection. On Windows you can use a program like PuTTY for this purpose. First search in device manager for the COM port assigned to your PlutoSDR, and then input this into PuTTY leaving the speed at 9600. You can then log in and set the environment variables using the lines provided in the wiki. Now in GNU Radio, GQRX etc you should be able to tune down to 70 MHz and up to 6 GHz and set the bandwidth to 56 MHz.

PlutoSDR Upgrade instructions
PlutoSDR Upgrade instructions

The images below show the PlutoSDR serial connection screen and the commands you need to type, the PlutoSDR tuning down to broadcast FM frequencies at 100 MHz, and a TX test at 70.1 MHz. It was found that the strength of the TX is a bit lower outside the official range, but can be increased by turning off the attenuation setting.

Setting up the GQRX Experimental Branch for the PlutoSDR

First set up GNU Radio and gr-iio using the instructions from this Reddit thread.

Now install gr-osmosdr-gqrx with the iiodev branch.

git clone https://github.com/csete/gr-osmosdr-gqrx
cd gr-osmosdr-gqrx/
git checkout plutosdr
mkdir build
cd build/
cmake ../
make
sudo make install
sudo ldconfig

Install the GQRX prerequisites

sudo apt-get install git build-essential cmake qtbase5-dev qt5-default qtscript5-dev libssl-dev qttools5-dev qttools5-dev-tools qtmultimedia5-dev libqt5svg5-dev libqt5webkit5-dev libsdl2-dev libasound2 libxmu-dev libxi-dev freeglut3-dev libasound2-dev libjack-jackd2-dev libxrandr-dev libqt5xmlpatterns5-dev libqt5xmlpatterns5 libqt5xmlpatterns5-private-dev pulseaudio

Install GQRX

git clone https://github.com/csete/gqrx.git gqrx.git
cd gqrx.git
mkdir build
cd build
cmake ..
make
sudo make install

Now GQRX should be ready to use the PlutoSDR. In the GQRX confiuguration screen select the device as Other or PlutoSDR and set the device string as “plutosdr=0”. Then you can set your sample rate and RF bandwidth, decimation etc. If you’ve done the frequency range hack then remember to select “No limits” in GQRX so that you can actually tune down further.

Note that in VMWare Lubuntu we were only able to get stable audio from the PlutoSDR and GQRX at a maximum of 3 MHz. Anywhere between 3 – 60 MHz bandwidth the PlutoSDR and GQRX spectrum and waterfall runs smoothly, but the audio is crackly. Might be a VMWare problem, or maybe something that can be fixed in later GQRX releases.

We also tested the PlutoSDR together with the SpyVerter upconverter for HF reception. It seemed to work well.

The images below show the PlutoSDR working in GQRX. The images of the 2.4 GHz and 1.8 GHz bands show that there is little to no attenuation at the edges of the 60 MHz bandwidth, so the upgrade from 20 MHz to 60 MHz is working well.

900 MHz GSM Band
Broadcast FM
1800 MHz Cellular
2.4 GHz WiFi
PlutoSDR + SpyVerter Receiving Broadcast AM
900 MHz GSM Band Broadcast FM 1800 MHz Cellular 2.4 GHz WiFi PlutoSDR + SpyVerter Receiving Broadcast AM

Conclusion

So with this hack the PlutoSDR is a much nicer unit that really makes an interesting and affordable choice for those wanting to upgrade from the RTL-SDR. Combined with a SpyVerter upconverter the unit should also be able to receive HF signals quite easily, so this gives a total cost of $148 for a DC to 6 GHz receiving system with TX capability, 12-bit ADC resolution and up to 56 MHz of bandwidth.

Of course we still need to confirm what the performance of the unit is like, especially in the frequency ranges opened up by the hacks and in regards to strong signal handling. We will test those in the coming weeks. If it handles those well and other software developers support it in their software then despite the unit being advertised as a learning module for students, it might become one of the best and most affordable general purpose SDRs available.

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

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.

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.