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.
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
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
- 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
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
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.
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.
AirSpy > PlutoSDR > RTL-SDR > HackRF in Terms of Signalquality.
— Manawyrm (@Manawyrm) August 21, 2017
Concerning max sample rate, I wrote a program on the PLUTO to pick 8 bits of the 12 bit samples, and transfer across socket to host computer. Without dropped data, I can achieve 6 MSPS, but not quite 6.5 MSPS. This is almost good enough to stream TV signals. I will try with 2 cores in the future, and see if this can be improved.
Hi jim, can you share or explain how you manage to pick 8 bits of the 12 bit samples in software?.
My ADALM-PLUTOSDR just arrived and I immediately tried the frequency and dual core “hacks”. Next up is getting it to work on MacOS.
The config file on it’s mass storage partition and the documentation mention wifi capabilities, if a dongle is connected to a USB port. Did anyone try that? I have a couple of wifi-dongles lying around and having the SDR attached to an antenna, communicating with it via wifi would fit my setup very very well.
But I haven’t found documentation regarding wifi on the device.
If you ever make any progress with MacOS please let me know on sdr at zendata dot com, I am struggling with gr-iio. Thanks.
According to , USB max throughput should be 26MiB/s.
Am i wrong if i say that since for a pair of I and Q samples of 12 bits each, so 3 bytes, we should have around 8,6 MSPS, not only 4?
Maybe the limitation is that by default the Pluto is working in full duplex mode, so half is reserved for Tx and half for RX, with only 4.3 MSPS for each?
But maybe is it possible to force half duplex mode and double the bandwidth?
Sorry, it seems i failed to include the link correctly. Let me try again!
According to https://wiki.analog.com/university/tools/pluto/devs/performance …
I measured the consumed bandwidth at 4.2MSPS and it seemed to be 140Mbps which is about 16.7MiB/s. Increasing the sample rate did not increase the bandwidth usage so I assumed it reached the port speed. Nevertheless it seems possible to transfer 26MiB/s through the USB backed so if some optimizations can be made to get close to the theoretical 6.5MSPS it would be a huge win in my book.
This other page https://wiki.analog.com/university/tools/pluto/users/name gives some explanations about USB and achievable sample rate:
“(…)Since it is half duplex, that would be ~22.5 Mbytes/second for transmission, and ~22.5 Mbytes/second for reception. (…) What we actually achieve with the PlutoSDR is closer to 7.5 – 12 MSPS, but this depends on the USB host, and what other traffic is happening. This is about 65% to 100% of the theoretical rate, meaning that most depends on the host, but there still may be optimizations to be done.”
Those figures are quite different from the ones they give on the other page https://wiki.analog.com/university/tools/pluto/devs/performance and from the 4.2MSPS we are currently achieving.
Can someone please tell me what support is necessary in the linux kernel (what modules) in order to get this thing going?
I think it figured it out. I guess this are the main options:
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
CONFIG_USB_FOTG210_HCD=m
CONFIG_USB_FOTG210_UDC=m
# CONFIG_USB_DWC3_GADGET is not set
# CONFIG_USB_ISP1760_GADGET_ROLE is not set
CONFIG_USB_GADGET=y
# CONFIG_USB_GADGET_DEBUG is not set
# CONFIG_USB_GADGET_DEBUG_FILES is not set
# CONFIG_USB_GADGET_DEBUG_FS is not set
CONFIG_USB_GADGET_VBUS_DRAW=500
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
CONFIG_USB_GADGET_XILINX=m
# CONFIG_GADGET_UAC1 is not set
CONFIG_USB_GADGETFS=m
CONFIG_USB_MIDI_GADGET=m
It would be good to see comparison on l-band. In case of r820t2 sensitivity drop after +/- 1 Ghz, I think, the PlutoSDR must win Airspy.
I have just made a test with the pluto and adam patchantenna for the l band.
The program is sdr# ,with only 20db i could see the aero signals and some data signals
The iridiumband was not clear due to rfi in the neigbourhood wich gives a sawtooth signal over the iridiumband
Tested L-band today and updated the post. Yes the Pluto is very good on L-band, no external LNA needed to receive the STD-C channel. Seems similar to the RSP2.
What antenna did you use for the test?
The Outernet metal patch antenna. Unfortunately they don’t seem to be selling that anymore.
Made a patch antenna for 5,8 ghz and could receive wifi signals on 5260 mhz.
This is without a lna and gain at 62db with sdr#
It seems that the plutosdr is very good in the shf ranges
For me 5 GHz wifi signals are very well visible with the stock tiny antenna. I’d say PlutoSDR shines in 2+ GHz range because firstly it receives well in that range, and secondly because there are not many SDRs available that can receive anything above 2 GHz.
Thanks, fortunately I’ve previously bought the kit that includes one, so I could make my own comparison (which has shown about the same results as yours).
Hi! (plugin dev here 😉 )
There is a trick to start the AD IIO Oscilloscope at the same time as the SDR# plugin,
this way you can fiddle around with the settings “live”.
I live in a rural area myself and even with strong amplifiers and good antennas I don’t see any aliasing/imaging in my signals. You might be able to change the RF bandwidth to get a better signal or enable the /8 decimation in the FPGA, maybe that would help.
If you find a way to clean the signal up a bit, please let me know which settings you changed, so I can implement a way to do this in the plugin…
Best wishes,
Tobias (@Manawyrm)
If you would what is that trick
i fiddled with the AD IIO Oscilloscope and there are a lot of settings around ,bandwith and lna and much more
The trick is starting both at the same time, itself.
You could try changing the Bandwidth manually, change some of the Filter settings, and many presumably many more…
Lucky you! Pager signals (~930 MHz) produce quite crazy images for me (I live in a city and probably close to the pager signal transmitter), but mostly in ranges close to the originally transmitted frequency. However BCFM doesn’t produce any images at all.