Digilent 1x1 USB Software-Defined Radio Platform - Review

Table of contents

RoadTest: Digilent 1x1 USB Software-Defined Radio Platform

Author: gpolder

Creation date:

Evaluation Type: Development Boards & Tools

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?: SDR boards and modules, ranging from the very cheap RTL-SDR USB stick, to more expensive and more capable radios, as the ADALM-Pluto, Airspy, SDRPlay, LimeSDR or BladeRF.

What were the biggest problems encountered?: Dropped samples on the Raspberry Pi 4 and an Apple MacBook. Incompatibilities in different versions of GURadio examples and other software. From the perspective of board protection, operating temperature and unwanted signals picked up by the circuit, I was really missing the original Ettus enclosure kit. Also a GPIO connector or cable would have been helpful for some of my applications.

Detailed Review:

Introduction

First, I want to thank Element14 and National Instruments for giving me the opportunity to review the the USRP B205mini-i software defined radio board. I am really happy that my applications was selected. This is quite an impressive software defined radio board.

 

My application

There was quite a lot of interest for this SDR, 81 applicants in total, so I'm happy that mine convinced the jury. To be transparent, and also to inspire other members, for future roadtests, here are the relevant parts of my application:

 

(d) Why did you apply for this particular roadtest?

 

In my scarce free time I'm a HAM radio amateur and I enjoy playing with RF electronics. Specifically Software Defined Radio is one of my favourites.

Up till now I used a RTL-SDR, a FunCube Dongle, and build software defined radio's using a Teensy and PSoC (Cypress PSoC® 5LP Prototyping Kit - Review ). As a HAM I do have the necessary antennas available.

I'm currently running an OpenWebRX server on a Raspberry Pi with an RTL-SDR dongle. I'm very interested to test the USRP B205mini-i and compare its performance to the RTL-SDR. Other applications I will test the USRP B205mini-i on will be NOAA weather satellite reception and decoding, ADS-B, Mode S, and Mode 3A/3C demodulator and decoder that will receive and decode aircraft transponder messages (Dump1090).

Last but not least, I will explore the use of GNU-Radio or Matlab to transmit some signals in the HAM Radio bands.

I realise that I have to build a small amplifier to increase the USPR output of 10 dBm to e.g. 30dBm (1W) and possibly some filters to get a clean signal according to the regulations.

 

 

(e) What is your testing procedure or project plan (Be as specific as you can)?

 

Proposed time schedule:

 

Day

Task

Deliverable

1-5 Get used to the board, read documentation and tutorials, 'Hello World' application
6-10 Build a receiver using GQRX and OpenWebRX on the Raspberry Pi Working SDR receiver
11-20 Test decoding of NOAA Weather satellite signals using WXtoImg Weather images received
21-30 Test decoding of ADS-B, Mode S, and Mode 3A/3C aircraft transponder messages Aircraft tracking
30-55 Build a software defined HAM Radio transceiver with GNU-Radio, USRP B205, and a small power amplifier GNU HAM transceiver
56-60 Wrap-up and finalising the roadtest report Roadtest report

Unboxing

Unboxing pictures are mainly not that informative, but in my opinion a review must contain some images on how the device is delivered.

image

There is a for me unknown logo on top of the box, which surprised me a bit as the roadtest was advertised as being from Digilent, which on its own also confused me as the board comes from Ettus Research. After opening it became a bit more clear.

image

The card is telling us that the box comes from National Instruments who is currently in the process of creating a new look. I know NI for years already, from their data acquisition software LabView. Ettus appears to be a NI brand since 2010, and Digilent is even longer under the umbrella of NI. The box contains the B205mini SDR board well packed in a anti static box and anti static bag. A USB 3 cable is also supplied.

image

imageimage

The B205mini is not a very novel board, the getting started document, in the box is dated on Oktober 2015.

image

 

First impression

Installation and setup of the software tools on macOS

Although I want to test the USRP on the Raspberry Pi, I decided to run the first tests on macOS. On the website of Ettus a page is dedicated to step-by-step guide for installing UHD (and GNU Radio) on OSX (Mac OS X / MacOS X 10.4 to 10.15) and macOS 11. I'm running the latest macOS version (Big Sur 11.3.1) and since 11 is mentioned I don't expect problems there.

Here is the link: https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_OS_X .

Ettus recommend using MacPorts as package manager to install the necessary tools, but I prefer to use home-brew (https://brew.sh/ ). Surprisingly the UHD and GNU Radio ports in homebrew are more up to date than in MacPorts.

 

These are the steps I did:

brew update

brew upgrade

brew install uhd

brew install gnuradio

brew install uhd-devel

brew install gnuradio-devel

Unfortunately the last two are not available in the home-brew repository. Let's try without them, first without the device connected:

% uhd_usrp_probe

[INFO] [UHD] Mac OS; Clang version 12.0.0 (clang-1200.0.32.29); Boost_107500; UHD_4.0.0.HEAD-0-g90ce6062

Error: LookupError: KeyError: No devices found for ----->

Empty Device Address

%

 

now connected

% uhd_usrp_probe

[INFO] [UHD] Mac OS; Clang version 12.0.0 (clang-1200.0.32.29); Boost_107500; UHD_4.0.0.HEAD-0-g90ce6062

[WARNING] [B200] EnvironmentError: IOError: Could not find path for image: usrp_b200_fw.hex

 

Using images directory: <no images directory located>

 

Set the environment variable 'UHD_IMAGES_DIR' appropriately or follow the below instructions to download the images package.

 

Please run:

 

"/usr/local/Cellar/uhd/4.0.0.0_2/lib/uhd/utils/uhd_images_downloader.py"

Error: LookupError: KeyError: No devices found for ----->

Empty Device Address

%

So it looks like the images are not installed by homebrew.

% python3 /usr/local/Cellar/uhd/4.0.0.0_2/lib/uhd/utils/uhd_images_downloader.py

[INFO] Using base URL: https://files.ettus.com/binaries/cache/

[INFO] Images destination: /usr/local/Cellar/uhd/4.0.0.0_2/share/uhd/images

[INFO] No inventory file found at /usr/local/Cellar/uhd/4.0.0.0_2/share/uhd/images/inventory.json. Creating an empty one.

21486 kB / 21486 kB (100%) x3xx_x310_fpga_default-gbe53058.zip

......................................

......................................

 

04839 kB / 04839 kB (100%) usb_common_windrv_default-g14000041.zip

[INFO] Images download complete.

%

After installing the images the device can be found.

% uhd_find_devices                                     

[INFO] [UHD] Mac OS; Clang version 12.0.0 (clang-1200.0.32.29); Boost_107500; UHD_4.0.0.HEAD-0-g90ce6062

--------------------------------------------------

-- UHD Device 0

--------------------------------------------------

Device Address:

    serial: 31E26E5

    name: B205i

    product: B205mini

    type: b200

Probe still gives an error.

% uhd_usrp_probe                                       

[INFO] [UHD] Mac OS; Clang version 12.0.0 (clang-1200.0.32.29); Boost_107500; UHD_4.0.0.HEAD-0-g90ce6062

[INFO] [B200] Loading firmware image: /usr/local/Cellar/uhd/4.0.0.0_2/share/uhd/images/usrp_b200_fw.hex...

[INFO] [B200] Detected Device: B205mini

[INFO] [B200] Loading FPGA image: /usr/local/Cellar/uhd/4.0.0.0_2/share/uhd/images/usrp_b205mini_fpga.bin...

[INFO] [B200] Operating over USB 2.

[INFO] [B200] Initialize CODEC control...

[INFO] [B200] Initialize Radio control...

[INFO] [B200] Performing register loopback test...

[INFO] [B200] Register loopback test passed

[INFO] [B200] Setting master clock rate selection to 'automatic'.

[INFO] [B200] Asking for clock rate 16.000000 MHz...

[INFO] [B200] Actually got clock rate 16.000000 MHz.

Error: RuntimeError: Cannot access! Property types do not match at: /mboards/0/eeprom

gerrit@GerritPldersMBP ~ %

But according to Using B200/B210/B200mini/B205mini on OSX / macOS with UHD - Ettus Knowledge Base most UHD-based applications will still work properly even with this specific bug in uhd_usrp_probe.

 

Next I did some tests as described in https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio. First a benchmark test. According to the macOS UHD application note MacPorts installs this example into /opt/local/share/uhd/examples/; but in my case homebrew  uses the default install location as provided by CMake, which  is /usr/local/lib/uhd/examples/.

 

% cd /usr/local/lib/uhd/examples

% ./benchmark_rate --args type=b200 --rx_rate 1e6 --tx_rate 1e6 --channels 0

 

[INFO] [UHD] Mac OS; Clang version 12.0.0 (clang-1200.0.32.29); Boost_107500; UHD_4.0.0.HEAD-0-g90ce6062

[00:00:00.032412] Creating the usrp device with: type=b200...

[INFO] [B200] Detected Device: B205mini

[INFO] [B200] Operating over USB 3.

[INFO] [B200] Initialize CODEC control...

[INFO] [B200] Initialize Radio control...

[INFO] [B200] Performing register loopback test...

[INFO] [B200] Register loopback test passed

[INFO] [B200] Setting master clock rate selection to 'automatic'.

[INFO] [B200] Asking for clock rate 16.000000 MHz...

[INFO] [B200] Actually got clock rate 16.000000 MHz.

Using Device: Single USRP:

  Device: B-Series Device

  Mboard 0: B205mini

  RX Channel: 0

    RX DSP: 0

    RX Dboard: A

    RX Subdev: FE-RX1

  TX Channel: 0

    TX DSP: 0

    TX Dboard: A

    TX Subdev: FE-TX1

 

[00:00:01.143563497] Setting device timestamp to 0...

[INFO] [B200] Asking for clock rate 32.000000 MHz...

[INFO] [B200] Actually got clock rate 32.000000 MHz.

[00:00:01.508592542] Testing receive rate 1.000000 Msps on 1 channels

Setting TX spp to 2040

[00:00:01.536878862] Testing transmit rate 1.000000 Msps on 1 channels

[00:00:11.845450315] Benchmark complete.

 

 

Benchmark rate summary:

  Num received samples:     10279848

  Num dropped samples:      0

  Num overruns detected:    0

  Num transmitted samples:  10308120

  Num sequence errors (Tx): 0

  Num sequence errors (Rx): 0

  Num underruns detected:   0

  Num late commands:        0

  Num timeouts (Tx):        0

  Num timeouts (Rx):        0

 

 

Done!

During the benchmark a green and red led at the RX and TX port lights up.

image

Next test is an ascii FFT:

./rx_ascii_art_dft --freq 144e6 --rate 5e6 --gain 20 --bw 5e6 --ref-lvl -30

Resulting in:

image

The peak between 145 and 146 MHz is a transmission I made at 145.475 MHz using my two meter ham radio handheld.

Finally I tested the transmit capability, by connecting the USRP to my spectrum analyser.

% ./tx_waveforms --freq 145.475e6 --rate 5e6 --gain 0

This nicely showed a peak at the expected frequency.

image

With a gain of 0db the signal is quit low. The maximum gain for the B205mini is 89.75 dB.

% /usr/local/lib/uhd/examples/tx_waveforms --freq 145.475e6 --rate 5e6 --gain 90

 

Creating the usrp device with: ...

[INFO] [UHD] Mac OS; Clang version 12.0.0 (clang-1200.0.32.29); Boost_107500; UHD_4.0.0.HEAD-0-g90ce6062

..................

..........

Setting TX Gain: 90.000000 dB...

Actual TX Gain: 89.750000 dB...

On the spectrum analyser, with a 20 dB attenuator in between it shows:

image

Making the maximum signal -15 + 20 = 5 dBm (3 mW). This is more or less in line with the specs, that state a maximum power output of 10 dBm.

 

GNU Radio

According to the title the https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio  application node should explain how to test the USRP with GNU Radio. Unfortunately it does not. But luckily the GNU Radio website itself does have quite some information on using the USRP (https://wiki.gnuradio.org/index.php/Guided_Tutorial_Hardware_Considerations ). I replicated the Software Radio Spectrum Analyzer demo successfully. Since I'm new to GNU Radio, I had some issues to get it up and running on macOS, including the problems described here: https://github.com/gnuradio/gnuradio/issues/4174, but in the end I got the spectrum analyser up and running.

Here is the flow graph:

image

And here the output frequency display and waterfall, again from my ham portable radio at 145.475 MHz:

imageimage

For some reason sometimes the signal immediately freezes, but after executing and killing the flow graph a couple of times it runs steady. I'v no idea whether this behaviour is an error in the USRP or in GNURadio. After playing a couple of weeks with GNURadio I have the impression that macOS is not the preferred OS for this. It hampers from freezes and crashes some times, and also it's performance is not that good although my macBook has enough resources.

 

Installation and setup of the software tools on a Raspberry Pi 4

For my experiments with OpenWebRX and NOAA reception I planned to use a Raspberry Pi. I did not found much information on existing binary ports of the UHD software, except for a pre-built 32 bit SDR flavored Raspberry Pi OS distro, PiSDR that includes GnuRadio and other SDR utilities. But that is not my preferred approach, first it is 32 bit, furthermore these kind of distributions are always lacking behind on the official software repositories. Therefor I decided to install UHD from source as described on the GNU Radio wiki:(https://wiki.gnuradio.org/index.php/InstallingGRFromSource_on_Raspberry_Pi#Install_UHD_from_source).

 

I mainly followed the instructions, except for a few changes:

 

  • apt install could not find cairo and pygccxml, in  stead I used:

$ sudo apt-get install libcairo2-dev

$ pip3 install pygccxml

  • I checked out a newer version:
$ git checkout v4.0.0.0
  • atomic needed to be linked in cmake

$ cmake -DNEON_SIMD_ENABLE=OFF -DCMAKE_EXE_LINKER_FLAGS="-latomic" -DCMAKE_INSTALL_PREFIX=/usr/local ../

  • make test was 98% successful, I'v no idea whether I can work without pyranges and pychdr

98% tests passed, 2 tests failed out of 81

 

Total Test time (real) =   9.22 sec

 

The following tests FAILED:

  50 - pyranges_test (Failed)

  52 - pychdr_parse_test (Failed)

Errors while running CTest

make: *** [Makefile:141: test] Error 8

  • uhd_usrp_probe worked fine, actually better than on macOS.

 

$ uhd_usrp_probe

[INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700; UHD_4.0.0.HEAD-0-g90ce6062

[INFO] [B200] Loading firmware image: /usr/local/share/uhd/images/usrp_b200_fw.hex...

[INFO] [B200] Detected Device: B205mini

[INFO] [B200] Loading FPGA image: /usr/local/share/uhd/images/usrp_b205mini_fpga.bin...

[INFO] [B200] Operating over USB 3.

[INFO] [B200] Initialize CODEC control...

[INFO] [B200] Initialize Radio control...

[INFO] [B200] Performing register loopback test...

[INFO] [B200] Register loopback test passed

[INFO] [B200] Setting master clock rate selection to 'automatic'.

[INFO] [B200] Asking for clock rate 16.000000 MHz...

[INFO] [B200] Actually got clock rate 16.000000 MHz.

  _____________________________________________________

/

|       Device: B-Series Device

|     _____________________________________________________

|    /

|   |       Mboard: B205mini

|   |   serial: 31E26E5

|   |   name: B205i

|   |   product: 30522

|   |   revision: 3

|   |   FW Version: 8.0

|   |   FPGA Version: 7.0

|   | 

|   |   Time sources:  none, internal, external

|   |   Clock sources: internal, external

|   |   Sensors: ref_locked

|   |     _____________________________________________________

|   |    /

|   |   |       RX DSP: 0

|   |   | 

|   |   |   Freq range: -8.000 to 8.000 MHz

|   |     _____________________________________________________

|   |    /

|   |   |       RX Dboard: A

|   |   |     _____________________________________________________

|   |   |    /

|   |   |   |       RX Frontend: A

|   |   |   |   Name: FE-RX1

|   |   |   |   Antennas: TX/RX, RX2

|   |   |   |   Sensors: temp, rssi, lo_locked

|   |   |   |   Freq range: 50.000 to 6000.000 MHz

|   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB

|   |   |   |   Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz

|   |   |   |   Connection Type: IQ

|   |   |   |   Uses LO offset: No

|   |   |     _____________________________________________________

|   |   |    /

|   |   |   |       RX Codec: A

|   |   |   |   Name: B205mini RX dual ADC

|   |   |   |   Gain Elements: None

|   |     _____________________________________________________

|   |    /

|   |   |       TX DSP: 0

|   |   | 

|   |   |   Freq range: -8.000 to 8.000 MHz

|   |     _____________________________________________________

|   |    /

|   |   |       TX Dboard: A

|   |   |     _____________________________________________________

|   |   |    /

|   |   |   |       TX Frontend: A

|   |   |   |   Name: FE-TX1

|   |   |   |   Antennas: TX/RX

|   |   |   |   Sensors: temp, lo_locked

|   |   |   |   Freq range: 50.000 to 6000.000 MHz

|   |   |   |   Gain range PGA: 0.0 to 89.8 step 0.2 dB

|   |   |   |   Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz

|   |   |   |   Connection Type: IQ

|   |   |   |   Uses LO offset: No

|   |   |     _____________________________________________________

|   |   |    /

|   |   |   |       TX Codec: A

|   |   |   |   Name: B205mini TX dual DAC

|   |   |   |   Gain Elements: None

  • I tested the same examples as I did on macOS, which worked fine, except for rx_ascii_art_dft which was missing

 

$ cd /usr/local/lib/uhd/examples

$ ./benchmark_rate --args type=b200 --rx_rate 1e6 --tx_rate 1e6

 

[INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700; UHD_4.0.0.HEAD-0-g90ce6062

[00:00:00.034666] Creating the usrp device with: type=b200...

 

$ ./rx_ascii_art_dft --freq 144e6 --rate 5e6 --gain 20 --bw 5e6 --ref-lvl -30

-bash: ./rx_ascii_art_dft: No such file or directory

 

$ ./tx_waveforms --freq 145.475e6 --rate 5e6 --gain 0

 

Creating the usrp device with: ...

GNU Radio was already installed earlier with the packet manager but I needed to still install soapysdr-tools, which is a generalized API and runtime library for interfacing with SDR devices and used by Gqrx and OpenWebRX to interface with the USRP (https://github.com/pothosware/SoapySDR/wiki).

$ sudo apt install gnuradio

$ sudo apt install soapysdr-tools

$ SoapySDRUtil --info

######################################################

## Soapy SDR -- the SDR abstraction library

######################################################

....................

$ SoapySDRUtil --probe=driver=uhd

######################################################

## Soapy SDR -- the SDR abstraction library

######################################################

 

Probe device driver=uhd

[INFO] [UHD] linux; GNU C++ version 8.2.0; Boost_106700; UHD_3.13.1.0-3

[WARNING] [B200] EnvironmentError: IOError: Could not find path for image: usrp_b200_fw.hex

 

Using images directory: <no images directory located>

....................................

This proves that Soapy is installed properly, also that it found the USRP hardware, but it could not find the FPGA images. Therefore I needed to set the UHD_IMAGES_DIR environment variable:

$ export UHD_IMAGES_DIR=/usr/local/share/uhd/images/

pi@sdrpi:~ $ SoapySDRUtil --probe=driver=uhd

######################################################

## Soapy SDR -- the SDR abstraction library

######################################################

 

Probe device driver=uhd

[INFO] [UHD] linux; GNU C++ version 8.2.0; Boost_106700; UHD_3.13.1.0-3

[INFO] [B200] Loading firmware image: /usr/local/share/uhd/images/usrp_b200_fw.hex...

[INFO] [b200_impl.cpp:385] [B200] Detected Device: B205mini

[INFO] [B200] Detected Device: B205mini

[INFO] [b200_iface.cpp:441] [B200] Loading FPGA image: /usr/local/share/uhd/images/usrp_b205mini_fpga.bin...

[INFO] [B200] Loading FPGA image: /usr/local/share/uhd/images/usrp_b205mini_fpga.bin...

[INFO] [b200_impl.cpp:432] [B200] Operating over USB 3.

[INFO] [B200] Operating over USB 3.

.....................

Success!

 

From GNU Radio it is advised to run a volk_profile on your terminal to help libvolk to determine the optimal kernels (may speed up GNU Radio).

$ volk_profile

RUN_VOLK_TESTS: volk_64u_popcntpuppet_64u(131071,1987)

..........

RUN_VOLK_TESTS: volk_32f_tanh_32f(131071,1987)

generic completed in 24563.7ms

series completed in 3098.69ms

Best aligned arch: series

Best unaligned arch: series

........

Creating "/home/pi/.volk"...

Writing /home/pi/.volk/volk_config...

 

 

Build a receiver using GQRX and OpenWebRX on the Raspberry Pi

Gqrx

All requirements are now installed in the previous steps, Let's try Gqrx (https://gqrx.dk/ ). Gqrx was already on my system, since I used it in the past with a RTL_SDR USB stick.

$ sudo apt install gqrx-sdr

I'm running a Raspberry Pi 4, with a 7 inch touchscreen. Gqrx was started with the -r option, which resets the configuration file. Gqrx now discovers devices attached to the computer and fills the proper device string in the device settings window. The pictures and video below show the successfull reception of a broadcast station using WFM modulation around 98 MHz.

 

 

imageimage

 

OpenWebRX

OpenWebRX is a multi-user SDR receiver that can be operated from any web browser without the need for any additional client software. It is the ideal solution to provide access to the HF spectrum at your location of choice to a wide audience. All you need is a computer, an SDR device and network access (https://www.openwebrx.de/ ).

I used the Raspberry Pi 4 as server, to share the SDR radio to my laptop in a very convenient way.

I used docker to install and run OpenWebRX  (https://github.com/jketterl/openwebrx/wiki/Getting-Started-using-Docker ):

$ sudo docker pull jketterl/openwebrx:stable

$ export UHD_IMAGES_DIR=/usr/local/share/uhd/images/

$ docker run --env UHD_IMAGES_DIR=/usr/local/share/uhd/images/ --device /dev/bus/usb -p 8073:8073 --tmpfs=/tmp/openwebrx -v openwebrx-settings:/var/lib/openwebrx -v /usr/local/share/uhd/images/:/usr/local/share/uhd/images/ jketterl/openwebrx:stable

Since an fpga image needs to be downloaded to the USRP at startup, docker need acces to the folder containing the fpga images. This is te reason for the additional command line options: --env UHD_IMAGES_DIR=/usr/local/share/uhd/images/ and -v /usr/local/share/uhd/images/:/usr/local/share/uhd/images/.

 

Device settings in OpenWebRX are as follows:

imageimage

As you can see the sample rate is 6 MHz, which is more or less the limit for this setup. When putting it higher I get Soapy overflows.

Here is the reception of a broadcast FM station at 102.1 MHz.

image

To compare here is the screenshot for FM reception using a RTL-SDR stick. as you can see due to the lower sample rate, the bandwidth is a lot smaller.

image

 

Some other examples, an narrow band FM signal on the 70 cm HAM radio band, full range and zoomed:

imageimage

And a POGSAC signal at 172.450 MHz:

image

Decoding NOAA Weather satellite signals using WXtoImg

I am running a Fully Automatic Amateur Satellite Ground Station some time already, using a RTL-SDR (https://github.com/stdevPavelmc/FAASGS).

This software uses rtl_fm to receive the signal from the NOAA satellites and wxtoimg (https://wxtoimgrestored.xyz/) to convert the received sound file into a weather image.

Its running from just one shell script, and includes satellite pass predictions. Output is to a web page.

All in all it is a powerful and convenient setup. In order to run this with the USRP, the only thing that needs to be changed is the rtl_fm call:

timeout $5 rtl_fm -p "${RTL_PPM}" -f "${FREQ}M" -s "${rxbw}" \

  -g 44.5 -E deemp -F 9 - | \

  sox -t raw -r "${rxbw}" -e signed -b 16 -c 1 - ${WSATP}.wav rate 11025

Unfortunately Ettus does not provide us with something like uhd_fm. A search on the internet brought me to https://github.com/rxseger/rx_tools.

This should give me rx_fm, rx_power, and rx_sdr tools for receiving data from SDRs, based on rtl_fm, rtl_power, and rtl_sdr from librtlsdr, but using the SoapySDR vendor-neutral SDR support library instead, intended to support a wider range of devices than RTL-SDR. Unfortunately I could not compile due to:

$ cmake .

-- Could NOT find SoapySDR (missing: SoapySDR_DIR)

CMake Error at CMakeLists.txt:19 (message):

  Soapy SDR development files not found...

As you have seen earlier in this review Soapy was properly installed, so I have no idea how to fix this. Furthermore this rx_tools repository is not maintained anymore, last commit was two years ago.

My idea now is to make a gnu radio version of rtl_fm, but due to time constraints this will be done after finishing this review. I will let you know here if I succeed, stay tuned.

In the mean time I used Gqrx to record a NOAA signal, which I processed from the command line with wxtoimg:

image

$ cat gqrx_20210607_195806_137623100.wav |sox -t raw -r "48k" -e signed -b 16 -c 1 -v 0.5 - gqrx_20210607_195806_137623100_sm.wav rate 11025

$ wxtoimg -t n -A -c -I -e HVC -K -q gqrx_20210607_195806_137623100_sm.wav gqrx_20210607_195806_137623100_HVC.jpg

Unfortunately the result is not great, I think I have to wait for a better satellite pass. With the RTL-SDR I sometimes have similar signals, sometimes worse and sometimes better. Stay tuned until I implemented a rtl_fm replacement.

image

 

Decoding aircraft transponder messages

Automatic Dependent Surveillance – Broadcast (ADS–B) is a surveillance technology in which an aircraft determines its position via satellite navigation and periodically broadcasts it, enabling it to be tracked. The information can be received by air traffic control ground stations as a replacement for secondary radar. It can also be received by other aircraft to provide situational awareness and allow self separation. On the waterfall the signal looks like:

image

For ADS-B decoding, dump1090 is an RTL-SDR compatible program that is commonly used. Current version of dump1090 (https://github.com/flightaware/dump1090 ) supports RTL-SDR, BladeRF, HackRF and LimeSDR, but not the USRP. Luckily there is a gnu radio based implementation specifically for the USRP (https://kb.ettus.com/Implementation_of_an_ADS-B/Mode-S_Receiver_in_GNU_Radio). An earlier version was also available through the Raspberry Pi package manager. I installed it that way, and modes_rx indeed nicely showed incoming  ADS-B data:

$ modes_rx -A TX/RX

[INFO] [UHD] linux; GNU C++ version 8.2.0; Boost_106700; UHD_3.13.1.0-3

[INFO] [B200] Detected Device: B205mini

[INFO] [B200] Operating over USB 3.

[INFO] [B200] Initialize CODEC control...

[INFO] [B200] Initialize Radio control...

[INFO] [B200] Performing register loopback test...

[INFO] [B200] Register loopback test passed

[INFO] [B200] Setting master clock rate selection to 'automatic'.

[INFO] [B200] Asking for clock rate 16.000000 MHz...

[INFO] [B200] Actually got clock rate 16.000000 MHz.

[INFO] [B200] Asking for clock rate 32.000000 MHz...

[INFO] [B200] Actually got clock rate 32.000000 MHz.

Setting gain to 38

Gain is 38

Rate is 4000000

(-54 0.80628909) Type 17 BDS0,9-1 (track report) from 47340e with velocity 451kt heading 270 VS 0

(-64 0.93453059) No handler for message type 24 from be0fb2

(-53 1.13113759) Type 11 (all call reply) from 47340e in reply to interrogator 0 with capability level 6

(-64 1.73868409) Type 0 (short A-A surveillance) from c46708 at 20200ft (speed 600-1200kt)

(-55 1.89775734) Type 17 BDS0,9-1 (track report) from 47340e with velocity 451kt heading 270 VS 0

(-64 2.09478134) No handler for message type 24 from 6eb0e5

(-54 2.18655609) Type 11 (all call reply) from 47340e in reply to interrogator 0 with capability level 6

(-57 2.19458434) Type 11 (all call reply) from 47340e in reply to interrogator 0 with capability level 6

(-55 2.21050434) Type 11 (all call reply) from 47340e in reply to interrogator 0 with capability level 6

(-56 2.21868459) Type 11 (all call reply) from 47340e in reply to interrogator 0 with capability level 6

(-55 2.22692459) Type 11 (all call reply) from 47340e in reply to interrogator 0 with capability level 6

(-56 2.23499884) Type 11 (all call reply) from 47340e in reply to interrogator 0 with capability level 6

(-59 2.24274959) Type 20 identification from 6464b0 with text RYW ZV   at 38000ft

modes_gui was less successful:

$ modes_gui

Traceback (most recent call last):

  File "/usr/bin/modes_gui", line 24, in <module>

    from PyQt4 import QtCore,QtGui,QtWebKit

ImportError: cannot import name QtWebKit

After a short search on the internet I discovered that this is a known issue for which no one takes responsibility (https://discourse.myriadrf.org/t/implementation-of-an-ads-b-mode-s-receiver-in-gnu-radio/3192 ). I decided to leave it at that.

 

HAM Radio transceiver

Finally in the application I promised to build a ham radio transceiver. There appeared to be some gnu radio ham transceivers available on the internet. There are very interesting gnuradio ham transceiver implementations from W7FU (https://w7fu.com/ ),  DL8RDS (https://www.dl8rds.de/index.php/GNURadio_and_USRP2 ) and Barry Duggan KV4FV (https://github.com/duggabe/gr-control). For this review I started with tutorials from Ettus (https://files.ettus.com/tutorials/labs/Lab_1-5.pdf ) in which a narrow band fm receiver and transmitter is described. Reason for this choice is that it gives quite some background information and understanding on the principle of the system. I really want to build this myself, in stead of just downloading some .grc files.

I started on macOS. Unfortunately both the receiver (lab4) as the transmitter (lab5) hampered from underflows, showing a lot of 'U's on the console indicating the USRP ran out of samples to transmit, so the host isn't producing them quickly enough, or the other way around while receiving. Then I switched to Barry Dugan's gr-control. This already is a full featured transceiver, implementing antenna and PA switching through a raspberry pi. I adapted the software a bit, specifically the XMT/RCV Control block, so the raspberry Pi was not needed for switching. In a later stage this switching can be done by the GPIO ports from the B205MINI, although the GPIO cable from ETTUS is extremely expensive (https://www.ettus.com/all-products/gpio-cable-4/ ). The project consists of several modules, each with its own flowchart and GUI window. Most important is the xmt_rcv_switch. When starting the switch and an fm receiver it works fine in first instance, but very weird, when I just move one of the other windows, it immediately stops an start to show underflows:

 

 

 

I think this is due to incompatibility between GNURadio and macOS and has not much to do with the USRP.

Also the transmitter shows underflows:

 

 

 

Finally I switched back to the ettus tutorials lab4 and lab5, but now on the Raspberry Pi 4. Here are the flow charts, they are a bit different then in the labs, since QT GUI is used, and I made some adaptations to the GUI. The first picture shows the receiver, it did work, but I'm not impressed on the audio quality and sensitivity. The gr-control above was much better in that sense:

image

Below is the flow graph of the transmitter. In first instance I used a sound input at 48 kHz , although by default the Pi does not have a sound input interface. The program did not work well, producing a lot of underflows. Then I recorded a morse code sound file at 11 kHz, and used that as input. This audio rate was good for no underflows.

image

The video below shows how this looks like in real life:

 

 

As described above the max power output of the USRP measured at 145 MHz is 5 dBm (3 mW), which is a bit low for a HAM radio transceiver. To increase the power I used a cheap wideband LNA, with a SPF518z. This amplifier is mainly used as preamplifier for receivers, but can of course also be used in transmitters. Its output power is around 20 dBm (100 mW) and the gain is around 18 dB. I used a module from RTL-SDR BLOG (https://www.rtl-sdr.com/new-products-in-our-store-wideband-lna-spare-metal-v3-enclosures/). In order to increase the output to 1W, I designed a small amplifier from parts in my junk box:

 

image

Be aware this is not a linear amplifier, so it works fine for FM, but not for AM or SSB. The filter at the output suppresses harmonics with 60 dB.

Trying out all the different options with GNURadio took me so much time that I couldn't build the amp before the review deadline. Below is a picture of the current state. As you can see I have yet to place the parts. As soon as I have some more time I will finish and test this amp, stay tuned.

image

 

Discussion

The USRP B205mini is a very capable SDR board with a small footprint. I mainly tested it at the lower frequencies. Highest frequency I used was 1090 MHz. I didn't really measure it, but I have the impression that the sensitivity is more or less equal to my FT-817 HAM Radio transceiver. It is anyway better than the cheap RTL-SDR dongle, but that is not a surprise as the RTL is 8 bit, and the  B205 12 bit. If you like to see numbers, Alexandru Csete and Sheila Christiansen did a very nice Evaluation of SDR Boards and Toolchains of different boards, including the RTL and the USRP (https://gitlab.com/librespacefoundation/sdrmakerspace/sdreval/-/raw/master/Report/pdf/Evaluation_of_SDR_Boards-1.0.pdf).

 

It is really a pity that the board is delivered without case, that will protect the board from picking up unwanted signals and increase the operating temperature range by cooling the chips. I had the impression that some  10dbM signals from my WSPR transmitter were picked up by the circuit somewhere behind the antenna connector. I would rather like to test this, if National Instruments/Digilent/Ettus will provide the enclosure kit (https://www.ettus.com/all-products/usrp-b205mini-i-enclosure/ ).

 

For switching antenna and/or power amplifiers, the GPIO ports should be very useful. I didn't use them up till now, but I would rather like to when finishing up my ham radio transceiver. I didn't check yet, but I hope I can find some standard connectors which will fit in the GPIO socket, since the GPIO cable provided by Ettus is extremely expensive (€79,-).

 

Although the board is rated at upto 61.44 MSPS, with the hardware combinations I tested (Raspberry Pi 4 and Apple MAcBook pro, I could not get near to that. On both platforms most applications are using Soapy as interface in the middle, which is possibly causing this problem. Maybe I need to write my transceiver in C++? Also with low frame rates like 250k, I ran into problems specifically with the transmitter.

 

There appear to be a lot of incompatibilities between different gnuradio versions and as the B205mini is already 5 years on the market,  quite a lot of software is made in gnuradio 3.7, while the current version is 3.9. This also gave me some hassles once and a while.

Also running gnuradio on a mac went not always smoothly. As an example, gr-control which nicely was made with grc 3.9, makes use of an external library (gr-cessb). It was not a problem at all to compile this library, but getting it to run with the homebrew based gnuradio installation was a challenge that I didn't met in the end.

 

Despite these minor issues, I had a lot of fun with the board, and for Gqrx and OpenWebRX you really see the improvements over the RTL-SDR.

The review took me quite some time and not all plans are completed as you have seen, so stay tuned, I plan to update this review when I do additional testing.

 

Resources

Anonymous