Digilent 1x1 USB Software-Defined Radio Platform - Review

Table of contents

RoadTest: Digilent 1x1 USB Software-Defined Radio Platform

Author: nathandumont

Creation date:

Evaluation Type: Test Equipment

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: https://limemicro.com/products/boards/limesdr/ https://greatscottgadgets.com/hackrf/one/

What were the biggest problems encountered?: The unit for review was the "bare-board" variant. For use on the bench, rather than integration into a larger system I would have preferred the version with a case.

Detailed Review:

I've been using the Ettus USRP products for years, they keep getting smaller and easier to use and this is no exception.  I've been using an SDR as an alternative to dedicated RF signal generators and spectrum analysers for a few years.  They save on space and also cost at the expense of calibration and absolute measurement.  It's been particularly important in the last year working exclusively from home.  Recently I've been using a LimeSDR and an Ettus/NI USRP B200.  The B205-mini performed well in all the things I tried with it and takes up less space than ever.  I've addressed some applications and use cases in this review, I can't comment on how easy it is to get started with as a first time user because I'm not.  I started using the USRP series when they were more or less the only SDR in town and you had to compile the drivers and in some cases firmware from scratch so I've got a lot of hard-won knowledge about what to do if things don't work right and how to set it up.


My setup

For the purposes of this review I have been using a ThinkPad T430, an ageing laptop but it has an Intel Core i5 and 16GB of RAM and 2 USB 3.0 ports.  It is running the KDE variant of Ubuntu 20.04 natively, and was installed fresh only a couple of weeks ago, so I'd not used any SDR software with it since install.  I use Ubuntu daily for development and design work and I've been using USRP hardware on Linux for more than 10 years, hopefully that means I know where to poke to get the most out of the device but it does mean my experience is quite different from someone new to the hardware.


Comparison with the B200

The B205-Mini has a larger FPGA but the same I/O capabilities as the much larger B200 as you can see in the photo.



The larger FPGA would allow some processing to be offloaded from the host general purpose processor, making this a good choice for embedded systems. Creating a custom FPGA bit-stream although well documented is a time consuming process I don't have time for in this review. This level of customisation is possible with this hardware though and it's one of the reasons to choose the platform because you can start off with a powerful PC doing most of the work, then when you are confident with the design, invest the time to move some of the processing into the FPGA and reduce your power/size/cost accordingly. I have done this before with Ettus products quite successfully but, like any big optimisation job, it is a significant time investment.


Like the B200 the 205MINI-I comes as a bare board. This can be a bit of a nuisance if you are using it as a bench tool. There are cases available for both (I have one for the B200 I've been using regularly) which will protect your board from ESD or shorting something out on a stray SMA connector. I can't seem to find the case separately on Farnell in the UK, but if you are considering this as a bench tool I'd highly recommend the cased version B205MINI-I With CaseB205MINI-I With Case. The B205 does feature some mounting holes which is an improvement over the B200 which had to be slid into a board guide. It's size and mounting options make it a very attractive option for integration into some larger piece of test equipment or automated testing infrastructure.


Getting it running

As I mentioned earlier I'm running on an Ubuntu 20.04 based system, I've almost always used Linux for SDR stuff, the drivers and general performance always seem better and you don't need a license for it.


To start with I installed GNURadio which is a standard Ubuntu package and installs the low level libraries, hardware drivers and a clean and intuitive block based GUI all in one go.


sudo apt install gnuradio


Once that was installed I fired up GNURadio-Companion which is the GUI based radio system design tool and made a quick spectrum analyser application.  I plugged the B205 into one of my USB 3  ports and ran the application, but alas, an error.  GNURadio reportsnit cannot find any hardware.  I'm quite familiar with the Universal Hardware Driver (UHD) which sits between GNuRadio and the USRP devices so I knew where to look, but you'd need to go googling if not.  On the command line I used the low level uhd_usrp_probe command which lists all USRP devices found on the system or network.




It too states that it can't find the hardware but helpfully notes this is because there is no firmware available on the system and provides a command to run to fetch the latest.  The USRP uses a Cypress USB bridge chip which can run some firmware and a completely volatile FPGA so every time you power the board on it appears as a blank Cypress chip and the driver downloads firmware then FPGA image.  This takes a few moments the first time you start it up after plugging it in but it makes managing the firmware as simple as keeping the right files on your host device. It also means if you did have a custom firmware that was running an extra filter in the FPGA you could explicitly require that in your host code and the right image would be downloaded when you ran the code so no confusion about whether the device was still at factory state or running custom firmware.  To get the latest binaries from Ettus I ran the command specified in the output of uhd_usrp_probe. (It has to be run as sudo because the drivers are downloaded to a system folder.)


Now does uhd_usrp_probe work? No. Now there's a permissions issue. Permissions for USB hardware are managed by udev in Linux which is a long and complicated subject.  I knew where to look and quickly found that the udev rules file that came with the Ubuntu hardware driver is out of date, it doesn't include the device ID for the B205MINI.  I checked the official file on Ettus' GitHub and there's just one line missing from the packaged version.


I first copied the file I had on the system:

sudo cp /usr/lib/udev/rules.d/60-uhd-host.rules /etc/udev/rules.d/10-uhd-host.rules


Then editing the new file I had created, I added the missing line:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="2500", ATTRS{idProduct}=="0022", MODE:="0666"


(By making this file in /etc and giving it a lower number it overrides the one that came with GNURadio, but will not get replaced if the GNURadio package gets updated.)

Finally, to load the new rules without having to reboot, I ran:

sudo systemctl restart udev


and unplugged/replugged the USRP and this time it all came good.


I'm a bit disappointed it's still this complicated to get started. It's a lot easier than it used to be, but it should be easier. To be fair to the hardware manufacturer I was using the software maintained by Ubuntu, not them because I wanted an easy to maintain experience. I feel Ubuntu have been slack on maintaining this package, according to the headers the udev changes for the B205 were done in 2018 so should be in the 20.04 package.


What can we see?

The first thing I always do with a new SDR is hook up an antenna and start looking for interesting signals to just check that everything is working. For this testing I was using an 868MHz antenna that I had around from some LoRa work. For some of the signals I'm looking at this will be a bad match, but it is good enough to look at relative power. If you're actually trying to demodulate data always pick a good antenna for your band to get the most signal and reject the most out of band noise.




First up, near the lowest end of the device's range is an FM radio broadcast:



This should be BBC Radio 2 which is an FM transmission on about 89MHz. You can see the peak in the spectrum plot and the frequency modulation is visible in the waterfall plot.


Next I took a look at digital radio transmissions, you can see 3 and a bit multiplexes simultaneously in the 10MHz bandwidth I was surveying here. DAB is transmitted using OFDM which has this characteristic square block appearance in the frequency domain making it easy to see.  Each transmission is allocated a 2MHz spectrum chunk which includes some guard band so the chunks can be placed next to one another.



Next up I looked at a DVB multiplex at 570MHz. This looks a lot like the DAB, but it's a wider channel, 8MHz this time. You can see one full multiplex and a neighbouring one just on the edge of the plot here.



Finally I looked at the WiFi from my laptop. you can't see this very clearly in the frequency plot and I think I would need 20MHz bandwidth to see the whole transmission but you can see the bursts as bright horizontal lines in the waterfall very clearly.




Of course I've not covered half of what the unit can do as it goes all the way up to 6GHz.


RF debugging


Next up I wanted to try out a technique I picked up from my supervisor whilst doing a post-doc in RF design. When I was doing it at the university I was using a high end (££££) Rohde & Schwarz spectrum analyser, but with a bit of patience you can apply the same technique with an SDR. I've recently seen the technique well documented in this YouTube video so I won't go into detail now.  Basically I use a small H-field antenna to pick up signals in a very local area, allowing me to trace RF power along PCBs or locate a noise source for EMC compliance testing.




Here's the probe which my wife made when watching the video above,it's just twisted wire-wrap wire taped to a wooden skewer for a bit of extra support. Twisting the feeder wires together so that the induced common mode voltage is zero is important to make sure you're only picking up signal from then loop at the tip.


I tried it out on a a Raspberry Pi 4.  I found what appears to be the gigabit Ethernet clock line which is strongly radiating 125MHz and I'd guesz the internal processor in the Samsung EVO micro SD card runs at 400MHz.







To find these signals with my simple spectrum analyser code required me to manually pick the 10MHz band I was interested in and then look for spikes. You also need to be a bit careful about picking a centre frequency that's exactly where you're looking because you can get some carrier breakthrough from the LO (that is you get a bit of a spike at the centre of your frequency span which is actually just the internal clock in the SDR). This effect seems to be better than with the old WBX board from Ettus but it's still there.


In the video tutorial they were using a very much cheaper SDR for this work, if this is your on!y reason to get one then you probably don't need a B205, but there are a few advantages I've found using the B200 (which performs identically for this but is just bulkier):

  • You only need one device (if you've already got an SDR or need it for something else).
  • You can work in a greater frequency range, I've traced shorts in RF circuits at >3GHz using this technique by following the signal across the board and noting that it stops (or at least reduces unexpectedly) at a particular location. A lot of the cheaper SDRs don't go up that high.
  • You can generate a signal from the TX and look at how it progresses through some receiver. I've used the B200 to feed a signal into the circuit under test and monitor how it progresses through various filters/amplifiers and mixers to verify the design. The cheaper SDRs often don't have a transmit.

In summary the B205MINI performs as well as my B200 for this task at less than half the size so great for a clearer bench or field testing.


RF playback test

One application of this kind of embeddable software defined radio is systems testing. One I come across frequently in my work in timing systems is how to test systems response to a leap second event. If you want to read about leap seconds take a look at the Wikipedia article. Basically they are impossible to predict and rare but can have significant impact on systems, most often a deployed unit will learn of them from a GPS receiver since they are part of the data payload from the satellites. One way to test for them is to use a GPS simulator, but they're really expensive pieces of kit. I wanted to see how hard it would be to build one of my own using this SDR and some open source software I found on GitHub.


I am using a uBlox M8 receiver I had on my desk, it is wired into a Raspberry Pi for a prototype sensor system, mostly that's irrelevant here, the important thing is that the antenna is connected via an off-board connector which I can replace with a direct wire from my SDR. Don't transmit via an antenna at GPS frequencies, in most places it's illegal! The software operates in a two step process, first you feed it real satellite data downloaded from NASA and it generates a binary file which is just a list of RF samples. Then you "play" that list of samples out through your SDR of choice. One of the supported examples is for a USRP 2 which is a much older version of the Ettus device, but they've made a good job of maintaining API compatibility over the years so I thought it was worth a shot.


The code compiled without issues on my Ubuntu machine and after a bit of searching I found the satellite data file I wanted from December 2016 (the last time there was a leap second added). I ran the simulation in "static" mode, that is I gave it a fixed latitude, longitude and altitude so the receiver will assume it is stationary at that location throughout the scenario. I asked for a 30 minute (1800 second) scenario centred around midnight. It takes up to 12.5 minutes to get all the date information from GPS and the leap second is added as the last second in the year before midnight rolls over. It took my laptop about 12 minutes to compile the scenario and it came out at about 18GB.


Next was the question of connections, GPS is a very weak signal in real life so you need to be careful not to overload the receiver. 40 to 60dB of attenuation are recommended on the GitHub page.  I put 3 20dB SMA inline attenuators in line from the transmit output (TX/RX connector) on the B205 giving me a 60dB loss. Finally it's important to protect RF connections from DC biases in most cases, I've not studied the design of the USRP inputs enough to check so to be safe I added a DC block. Most GPS modules with an antenna connector (mine included) bias their RF input at 3.3 or 5V, this is split off at the antenna to power a low noise amplifier to overcome losses in long cable runs.




I fired up my GPS receiver and monitored the output of the serial port. Running the simulator script to playback the scenario worked without hitch using the GNURadio libraries I'd already installed. One thing to note is that the generation script defaults to 26MHz sample rate whereas the USRP playback script defaults to 25MHz. In the old days the clocking was somewhat inflexible in SDRs and whilst some of them were USB based and seemed happier at 26MHz the old USRP 2 was gigabit Ethernet and preferred integer multiples of 25MHz. I'd not realised this until after I'd generated the scenario (generation can run at any frequency, it's just maths) and I couldn't be bothered to re-generate so I tried setting the B205 to run at 26MHz (there was a command line option to do it) I figured the modern clock synths wouldn't be as picky.  I was right, after a few moments the GPS started informing me it was nearly midnight on the 31st of December 2016. I left the scenario run and sure enough the critical moment occurred:






















So the 61st second of the last minute of the last hour of the day is there. Just looking at the NMEA this seems easier to simulate at a higher level, but there are all kinds of warning flags and messages that the receiver will have been producing before the event which this RF simulation will have simulated perfectly.


The last thing I wanted to try was running the SDR on a lower powered host. Software defined radio has been out of reach for low powered boards like the RaspberryPi until recently, mainly due to the lack of bandwidth to connect the device. I had a Pi4 on my bench already for this review so why not give it a go?


I installed the gnuradio package via apt the same as I had done on my laptop. Unfortunately this appears to pull in all of the graphical stuff needed to run the GUI even though I wanted to run headless. It's probably possible to install a subset but I didn't take the time to try. I cloned the Github repository for the GPS simulator onto the Pi as this seemed like a simple application to try out. I didn't try to generate a scenario on the Pi itself, I copied the one I already had onto it. Bear in mind the scenario was 18GB, you need a big SD card or maybe an SSD if you're going to do much of this kind of thing. I tried to run the GPS simulation playback immediately but it didn't work. Again I had the same two issues as on Ubuntu; no firmware images and the  bad permissions. The permissions fix was identical to Ubuntu, for some reason though the command in the output wasn't looking in the right place for the script.  Actually the same command as on my laptop worked.


Once those issues were overcome and uhd_usrp_probe was reporting correctly I still couldn't get the playback script to work, Python kept saying it couldn't find the gnuradio module. This left me puzzled for a few minutes with unsuccessful google searches. As a last ditch try or give up I decided to force the script to use Python 2 instead and suddenly it all sprang to life. That basically means the packages for GNURadio on the RaspberryPi are so out of date they're still bound to Python 2!


I got it working and once again the GPS was convinced that it was December 2016, so the Pi4 does have the necessary power to run a simple playback with 26MHz of instantaneous bandwidth without dropping samples. I was surprised and impressed.




This little board has succeeded at everything I've tried to do with it. It can certainly replace the much physically bulkier B200 I was using. It's got great potential to be embedded inside larger systems and its tiny form-factor lends itself well to that. The price of the board means its not a toy but then its performance isn't toy like either. As a piece of debugging equipment for RF work, maybe as a work-from-home tool when the big RF signal generators and spectrum analysers are in the office the unit I reviewed was great, only lacking in a case.


In summary if you need the microwave frequencies, need to be able to transmit or are looking for a way to embed RF sensing or simulation into a test rig or production system this board is ideal.

  • You mean the flow graph I used?  It was a throw-away 4 block thing, there's a screen-shot of it in my comment https://www.element14.com/community/roadTestReviews/3601/l/digilent-1x1-usb-software-defined-radio-platform-review#comme…

  • nice review, specifically the last part with RF playback.


    Can you please add (a pointer to) the gnuradio program you used for the receiver?

  • Your professional modesty is admirable. I started in electronics when vacuum tubes were still being used. I worked for a number of years in the aviation industry where RF transmission in many different bands was prevalent. I recall reading books on GPS because the technology was rumoured it would change aviation navigation. I left the industry to pursue a career that focused on computer systems administration. I lost touch with the technology of aviation when I left.


    I am still fascinated by satellite technology. Just finished assembling a GPS Receiver on a Raspberry Pi to generate a more precise time source. To hear that the constellation of satellite signal can be simulated in a box like this is a wonder. I have just scratched the surface of GNRadio with AM & FM transmission. When I see people demonstrate it I rush to their side trying to find some of their secrets. GNURadio is a beast of a software. To be tamed you must be caged with it if you wish to master it.


    Enjoyed the review and really enjoyed the discussion. The tricks of the lead character in the 1985 McGyver tv series left you saying, "Yeah, as if that can happen!" I suspect this credit card size device is going to appear in some tech show or already has.

  • I don't think I'd say GNURadio was buggy, really. It doesn't crash or behave unexpectedly (at least it hasn't for me for a few years). It is however very complicated, and with any complex software that's trying to achieve an "all things to all men" kind of API it often hits architectural issues. It can be hard to achieve goal A because the software blocks you're using were written by someone trying to reach goal B and they didn't think of the general use case.


    The problem is that SDR is really processor intensive.  It still challenges general purpose CPUs.  But to try and keep things portable (I ran the same code on an Intel i5 and a Raspberry Pi 4 in the example) GNURadio has to sit above the abstraction layers.


    There's lots of stuff SDR can do to be more user-friendly and not require so much hard-work around writing custom DSP code.  Looking at the advances in GNURadio Companion in the last 10 years there's a vast improvement there already.  I think open source FPGA toolchains are going to have a big impact in the next 10 years allowing easy to draw flow-graphs to generate custom FPGA bitstreams to offload the processing from the general purpose CPU.

  • That's precisely it, the SDR is pretending to be the whole GPS constellation transmitting the signals from a whole bunch of satellites at once each shifted by a small amount of time to make them appear to be at different distances from the receiver.


    It's not that complicated, mostly just a lot of geometry in theory!?! I've not gone anywhere near that level of complexity, I'm standing on the shoulders of giants, just using open source software to do the simulation. All I did was download compile and run.

  • Yeah, playback is really compelling.  Being able to run the same 30 minutes of time over and over until I'd ironed out all the weird edge cases and race conditions caused by misunderstanding or under-documented API for the u-Blox module was hugely useful.

  • the SDR is capable of synthesizing any signals within its limitations. So you can in theory do anything like that. There are some pretty cool projects were they are used to provide mobile phone service. And they even it make it possible to make calls, etc. Its a pretty cool tech, but what is a little bit behind is the software side in terms of drivers, stability, etc. GNUradio which is kinda the standard to do all type of experimentation with SDR, is pretty buggy.

  • Are you suggesting the author is using the SDR transmit capabilities to produce the GPS satellite signals? If that is the case, WOW! No wonder I went navel gazing, that is way below my knowledge level. I would need air tanks to go that deep.

  • I believe the author was simulating the GPS signal by replaying an I/Q file generated by code, attenuating the output from the SDR into the GPS. Thus the GPS is connected to the SDR's RF out port through attenuators and a DC block, with no antenna in the system, thus neither A nor B.


    - Gough

  • Response much appreciated.


    A follow-up question if permitted.



    How was the SDR connected. drawing A or B for the measurement you did with the GPS module?