Skip navigation
> RoadTest Reviews

Digilent 1x1 USB Software-Defined Radio Platform - Review

Scoring

Product Performed to Expectations: 10
Specifications were sufficient to design with: 10
Demo Software was of good quality: 8
Product was easy to use: 8
Support materials were available: 8
The price to performance ratio was good: 10
TotalScore: 54 / 60
  • RoadTest: Digilent 1x1 USB Software-Defined Radio Platform
  • Buy Now
  • Evaluation Type: Test Equipment
  • Was everything in the box required?: Yes
  • Comparable Products/Other parts you considered: 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.

    Size comparison between the older and larger B200 and the new B205Mini

     

    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.

     

    Output of the uhd_usrp_probe command directing the user to run /usr/lib/uhd/utils/uhd_images_downloader.py

     

    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.

     

    The B205MINI SDR attached to an 868MHz antenna

     

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

    Spectrum and waterfall plots of FM radio broadcasts

     

    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.

    Frequency plot showing 3 square edged transmissions.

     

    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.

    A frequency plot showing a single block approximately 8MHz wide

     

    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.

     

    A frequency and waterfall plot showing bright stripes in the waterfall.

     

    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.

     

    A small loop of fine insulated wire taped to a wooden skewer.

     

    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.

     

    A test probe held over the under-side of a Raspberry PiA frequency plot with a strong spike at 125MHz

     

     

    A test probe held over the SD card in a running Raspberry PiA frequency plot with a wide spread-spectrum clock at around 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.

     

    A B205 SDR connected to a uBlox MAX8 module via some in-line SMA attenuators and a DC block.

     

    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:

     

    $GNGLL,5130.04882,N,00007.49280,W,235958.00,A,A*64

    $GNRMC,235959.00,A,5130.04922,N,00007.49340,W,0.095,,311216,,,A*70

    $GNVTG,,T,,M,0.095,N,0.175,K,A*32

    $GNGGA,235959.00,5130.04922,N,00007.49340,W,1,04,1.45,-96.8,M,45.6,M,,*4F

    $GNGSA,A,3,02,29,26,21,,,,,,,,,2.49,1.45,2.02*1D

    $GNGSA,A,3,,,,,,,,,,,,,2.49,1.45,2.02*13

    $GPGSV,1,1,04,02,11,036,31,21,30,170,33,26,43,291,36,29,71,066,38*74

    $GLGSV,1,1,00*65

    $GNGLL,5130.04922,N,00007.49340,W,235959.00,A,A*63

    $GNRMC,235960.00,A,5130.04958,N,00007.49401,W,0.078,,311216,,,A*76

    $GNVTG,,T,,M,0.078,N,0.145,K,A*32

    $GNGGA,235960.00,5130.04958,N,00007.49401,W,1,04,1.45,-96.2,M,45.6,M,,*40

    $GNGSA,A,3,02,29,26,21,,,,,,,,,2.49,1.45,2.02*1D

    $GNGSA,A,3,,,,,,,,,,,,,2.49,1.45,2.02*13

    $GPGSV,1,1,04,02,11,036,30,21,30,170,33,26,43,291,36,29,71,066,38*75

    $GLGSV,1,1,00*65

    $GNGLL,5130.04958,N,00007.49401,W,235960.00,A,A*66

    $GNRMC,000000.00,A,5130.04992,N,00007.49455,W,0.031,,010117,,,A*77

    $GNVTG,,T,,M,0.031,N,0.058,K,A*32

     

    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.

     

    Conclusions

     

    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.


Comments

Also Enrolling

Enrollment Closes: Jul 7 
Enroll
Enrollment Closes: Jul 19 
Enroll
Enrollment Closes: Jul 14 
Enroll
Enrollment Closes: Jul 12 
Enroll
Enrollment Closes: Jun 28 
Enroll