Ettus B205mini on Mac OS Part 1: Install & Setup

As I have been working with my RTL-SDR again, I was quickly reminded that I'd want the ability to transmit since the RTL-SDR only has the capability to receive. This lead me to bring out my Ettus URSP B205mini.

I've done tutorials in the past on using the B205mini with GNU Radio where I've talked about basic principles in RF board handling practices and the basic principles of what GNU Radio is that is still true today.

However, that past tutorial was for a GNU Radio installation on Ubuntu 18.04, and the flowgraph only focused on the receiver side of the RF chain. So this tutorial serves as an update for the GNU Radio installation process for Mac OS, as well as the inclusion of the transmit side of the RF chain on the B205mini in the GNU Radio flowgraph.

Install GNU Radio & UHD Software

Recently, I covered how to prep a Mac OS environment and install GNU Radio with the Radioconda installer to use with my RTL-SDR. The Radioconda installer is preferential in that it not only installs GNU Radio, but the compatible versions of the libraries to interface with hardware like the RTL-SDR and Ettus USRP SDRs as well.

Keep in mind that if the Radioconda installer is not used, then the OsmoSDR and UHD libraries for the RTL-SDR and Ettus USRPs respectively must be installed separately on the host system.

For Mac OS, I found that the current versions of GNU Radio in both the Macports repository and Homebrew repository are out-of-date and are not compatible with the OsmoSDR and UHD libraries in those same repositories.

Every time I would install either the OsmoSDR or UHD libraries, the gr-digital library would be deleted from the GNU Radio installation. Which is arguably the most necessary library in GNU Radio since it contains all of the digital modulation blocks.

See my previous post here for installation on Mac OS 14.

Test Connection to B205mini

Before getting into the design of the flowgraph in GNU Radio, I wanted to make sure that the UHD drivers were able to properly connect to the B205mini USRP.

The UHD device driver library has some helpful commands that can be utilized from the command line/terminal of the host PC. The first of which being the uhd_find_devices command. This will prompt any USRP connected to the host to respond back with an identifier name (ie - B205mini) and the connection address of the USRP whether it be a serial or network connection.

I found that with the Radioconda installation, the UHD bitfiles were not included, which results in the following error when attempting to use uhd commands such as uhd_find_devices:

~ % uhd_find_devices
[ERROR] [UHD] Device discovery error: EnvironmentError: IOError: Could not load firmware:
EnvironmentError: IOError: ihex_reader::read(): No EOF record found.

This is a simple fix however, as the latest bitfiles can always be downloaded with the uhd_images_downloader command:

~ % uhd_images_downloader
[INFO] Using base URL: https://files.ettus.com/binaries/cache/
[INFO] Images destination: /Users/whitneyknitter/radioconda/share/uhd/images
[INFO] No inventory file found at /Users/whitneyknitter/radioconda/share/uhd/images/inventory.json. Creating an empty one.
32419 kB / 32419 kB (100%) x4xx_x410_fpga_default-ge547a6b.zip
53458 kB / 53458 kB (100%) x4xx_x440_fpga_default-ge547a6b.zip
21602 kB / 21602 kB (100%) x3xx_x310_fpga_default-g6a990d9.zip
19738 kB / 19738 kB (100%) x3xx_x300_fpga_default-g6a990d9.zip
01126 kB / 01126 kB (100%) e3xx_e310_sg1_fpga_default-g6a990d9.zip
01118 kB / 01118 kB (100%) e3xx_e310_sg3_fpga_default-g6a990d9.zip
10196 kB / 10196 kB (100%) e3xx_e320_fpga_default-g6a990d9.zip
20842 kB / 20842 kB (100%) n3xx_n310_fpga_default-gd6608fc.zip
14257 kB / 14257 kB (100%) n3xx_n300_fpga_default-gd6608fc.zip
27244 kB / 27244 kB (100%) n3xx_n320_fpga_default-gd6608fc.zip
00481 kB / 00481 kB (100%) b2xx_b200_fpga_default-g92c09f7.zip
00464 kB / 00464 kB (100%) b2xx_b200mini_fpga_default-g92c09f7.zip
00883 kB / 00883 kB (100%) b2xx_b210_fpga_default-g92c09f7.zip
00511 kB / 00511 kB (100%) b2xx_b205mini_fpga_default-g92c09f7.zip
00167 kB / 00167 kB (100%) b2xx_common_fw_default-g7f7d016.zip
00007 kB / 00007 kB (100%) usrp2_usrp2_fw_default-g6bea23d.zip
00450 kB / 00450 kB (100%) usrp2_usrp2_fpga_default-g6bea23d.zip
02415 kB / 02415 kB (100%) usrp2_n200_fpga_default-g6bea23d.zip
00009 kB / 00009 kB (100%) usrp2_n200_fw_default-g6bea23d.zip
02757 kB / 02757 kB (100%) usrp2_n210_fpga_default-g6bea23d.zip
00009 kB / 00009 kB (100%) usrp2_n210_fw_default-g6bea23d.zip
00319 kB / 00319 kB (100%) usrp1_usrp1_fpga_default-g6bea23d.zip
00522 kB / 00522 kB (100%) usrp1_b100_fpga_default-g6bea23d.zip
00006 kB / 00006 kB (100%) usrp1_b100_fw_default-g6bea23d.zip
00017 kB / 00017 kB (100%) octoclock_octoclock_fw_default-g14000041.zip
04839 kB / 04839 kB (100%) usb_common_windrv_default-g14000041.zip
[INFO] Images download complete.

This is also a good first troubleshooting step to redownload the latest bitfiles for any issues with interfacing with a USRP device.

As mentioned above, any UHD devices connected to the host will respond with an identifier name and its connection address.

~ % uhd_find_devices
--------------------------------------------------
-- UHD Device 2
--------------------------------------------------
Device Address:
serial: 31DDAD8
name: B205i
product: B205mini
type: b200

It's worth noting that there isn't a need to pay attention to how each UHD device is indexed in the system (my B205mini was indexed as "UHD Device 2" on my system) because that index isn't a dependency to connect/interface to the UHD device. The value listed under Device Address: is what is used in GNU Radio to target a USRP device.

Interfacing with B205mini in GNU Radio

Since I have my B205mini connected to my Mac via USB, it uses the static serial address of the USB PHY chip on the B205mini. It is a 7 character hex address that has to be specified in the UHD: USRP Source and UHD: USRP Sink blocks in GNU Radio to stream IQ data samples in from or out to the AD9364 transceiver chip.

Since UHD devices can be connected via a serial connection or network connection, the device address has to be passed as a string including that specification.

In the case of a serial USB connection, the device address string is passed into the flowgraph blocks as "serial=XXXXXXX".

I personally like to create a variable for the USRP address so that if I switch between USRPs using the same flowgraph, then I only have to update the address in the one location.

In the UHD: USRP Source and UHD: USRP Sink blocks, the Device Address variable is under the General tab:

As an initial sanity check, I copy+pasted the FM radio receiver design from my last RTL-SDR project post to verify I had the settings on the receive chain of the B205 mini correct.

Using the same antenna as I did with my RTL-SDR (selected based on the reasoning I described in that tutorial post), I tuned into the same local radio station I had with my RTL-SDR:

Something that I had not noticed was that the default gain setting in the RTL-SDR Source block is 20dB, while the default gain setting in the UHD: USRP Source block is 0 dB.

Aside from the audio being nothing but low static, the gain setting being too low was immediately obvious in the waterfall graph in that the power level of the received signal was very low:

The AD9364 transceiver chip on the B205mini has a maximum gain setting for the receive side of 65 dB - 70 dB.

So I started with the same gain value the the RTL-SDR had been set to (20 dB) and slowly increased it until I reached a received signal power level that gave me a clean audio signal (which ended up being 50 dB).

B205mini FM Loopback

After proving-in the receive chain of my B205mini with the FM radio receiver flowgraph, I wanted to take the next step of proving-in in the transmit chain since the ability to transmit is something that the RTL-SDR doesn't have.

The receive side is designed to demodulate an FM signal of an audio source and play it back through my computer's speakers, so I decided to design the transmit side to do the reverse and take audio from my computer's microphone then apply the same FM modulation scheme to send to the B205mini through the UHD: USRP Sink block.

Like I mentioned in my previous post explaining the digital signal processing (DSP) behind the FM receiver flowgraph, the transmit side is the same game of matching data rates and sample rates, as well as filtering around the specified target signal.

I experimented with a couple of different options of using rational resamples before and after the WBFM Transmit block (this block applies the FM modulation) to upsample to a higher data rate going into the USRP Sink block.

I also used a low pass filter before and after the WBFM Transmit block to make sure nothing was being transmitted in the signal aside from what I was expecting.

The default data rate for audio is 48kHz, which is how fast the microphone is sampling audio:

In the case that I'm sending the audio straight to the WBFM Transmit block, the audio rate is 48kHz. Setting the quadrature rate will upsample the signal to the specified value.

However, the specified quadrature rate must be a multiple of the audio rate. So quadrature rate % audio rate == 0.

As a quick option to guarantee only the target signal was sent to the sink block, I added a low pass filter after the WBFM transmit block.

However, this actually needs to be a matched filter to better isolate the target audio from any noise also picked up from the microphone and improve its SNR. I am saving that for the next write-up though as it deserves a bit of extra detail.

The sample rate of the LPF is whatever the quadrature rate was set to in the WBFM transit block (480kHz in my case), and the cutoff is 48kHz of the original audio signal.

Finally, feeding the signal into the UHD: USRP Sink block the sample rate is the same as the LPF and the sync clock should be set to the PC clock which is the host computer's clock.

Under RF Options, set the Center Frequency to the desired output frequency for the B205mini to transmit at (which needs to match the USRP Source block is set to since this is a loopback test).

I'm using a 30 dB attenuator on the transmit port so I set the TX gain to 30 dB so that the receiver would see 0 dB (the max RF input power the AD9364 can handle is 2.5 dB).

Setting up the loopback on the B205mini consisted of connecting the transmit port back to the receive port with the aforementioned 30 dB attenuator on the transmit port.

I discovered a few interesting things to note when running the flowgraph, some things were obvious.

Like the fact that I needed to use headphones so that the microphone source of my computer didn't pick up what was being output from the speakers and cause a feedback loop.

As well as the fact that my quick (and dirty) use of a low pass filter instead of the proper match filter on the transmit side resulted in strong side lobes on the received signal adding a layer of static/distortion over the audio.

The last interesting thing I found however seems to be more of an oddity with the Radioconda installation on Mac OS. Something about the Python driver seemed to fight with the Bluetooth drivers. I was originally using my bluetooth headphones, but found that my computer would lock up and freeze after the flowgraph had been running for a couple of minutes. Turning off bluetooth and switching to wired headphones resolved this particular issue.

There also seemed to be an issue with the UHD: USRP Sink block not being able to stream enough data out to the B205mini consistently so I got constant underflow issues. Upsampling to a higher sampling rate didn't seem to have any affect, so it seems like I might need to rebuild GNU Radio from source on my Mac. However, that's a different problem for a different day for now.