USRP E310 Update

The recent USRP E310 image update (e310-release-002) seems to have resolved all of the out-of-the-box issues that I mentioned in the previous post. Only two minor issues came up:

1. My device shipped with a 4GB memory card while the new images require an 8GB card. Luckily I had an 8GB card in my phone that I swapped for the card in the USRP.
2. I was running UHD from the master branch on my host computer, while the image uses UHD release 003_008_004. It seems important to use the same version of UHD on the host computer if you want to use usrp_e3x0_network_mode, as uhd_usrp_probe could not find the device. I had a similar issue in the previous post. Once I downgraded to the same version I was able to find the device. I had to relink GNURadio to get the UHD: USRP Sink to run without throwing a seg fault.

Overall Ettus has done a great job on this product and I am looking forward to more experimentation.

Unpacking the USRP E310

The Ettus Research RF Network on Chip (RFNoC) demonstration that I watched at the beginning of December had me very excited about the technology as a low resistance path to doing an FPGA-based implementation of TC-OLA. The RFNoC technology gives the user the tools to create FPGA-based processing blocks without worrying about the details of data transport and the various layers of software hacking to make these blocks usable from GNURadio. I highly recommend watching the demonstration video.

After some discussion with my supervisor, we decided that the Ettus E310 was the best compromise in terms of features and cost to gain access to the RFNoC technology. Although the bandwidth is much less than what is possible with the X Series devices, there are several advantages:

• No host computer required to operate – has dual ARM processor cores.
• No 10GE interfaces and cabling required – uses standard GE interface.
• No additional front end card required – has integrated front end covering enough of the spectrum to be useful.
• Can build FPGA image with free version of Xilinx tools.
• Familiar with the Zynq 7020 from working with the ZedBoard.
• FPGA implementation of TC-OLA should be generic enough to be easily ported to the X Series if necessary.

The E310 has arrived today so I thought I would make some notes on unpacking and setting up the device. Here is the box which was carefully packed inside a much larger FedEx box:

The E310 is quite small, here it is on top of two of the USRP N210 devices. The E310 has more functionality than these two boxes combined:

For those not familiar with the size of a USRP N210, here it is alongside a 12oz coffee cup:

As far as setup is concerned, I skipped over connecting via USB serial console directly to network connection via SSH. It was straightforward and everything worked as written in the “Getting Started Guide” that was packed in the box.

I then attempted to use the “Network Mode” application which allows the E310 to be used from a host computer similar to the previous generation devices. I started the application but was not able to probe the E310 from my host computer. I then found that the version of UHD I had installed on the host computer did not have E310 support compiled in. I updated my UHD source tree on the host computer and rebuilt with E310 support. Trying to probe the E310 resulted in the message:

Error: RuntimeError: Expected FPGA compatibility number 5.x, but got 4.0:
The FPGA build is not compatible with the host code build.
Please run:

/usr/local/lib/uhd/utils/uhd_images_downloader.py


I ran this program on the host computer, but my situation did not improve. I ran it on the E310, and the situation got worse. Apparently the version of UHD installed on the E310 does not actually download the E310 bit file? After running this program I no longer have a bit file for the E310 under /usr/share/uhd/images. I poked around on the host computer side and saw that the UHD version there does indeed download the E310 bit file so all is not lost. I wondered if I could update the version of UHD running on the E310 such that it would be compatible with the host computer *and* also be able to download the correct FPGA image. I used git to checkout the code on the E310 and ran cmake, this time being sure to enable E310 support (cmake option: -DENABLE_E300=YES). While this was taking an extraordinarily long time to build, I transferred the E310 bit file from my host computer to the E310 using scp and now the network mode application will start but I have the same issue as before.

During the build I noticed that there were many “clock skew detected” warnings. Possibly the time on the E310 needs to be synced to network time for make to work properly. After waiting approximately forever for UHD to build, I was able to start the network mode application, successfully probe it from the host machine and use it as a USRP source in GRC flowgraphs. I made a simple FM tuner and was able to receive several stations. Our local emergency services radio network is also received clearly.

Although the out-of-the-box experience could have been smoother, I am looking forward to working with this device.

Publication: Time Compression Overlap Add

It has been a busy year. We recently published a paper in the IEEE Access special section on 5G Wireless Technologies: Novel UWB and Spread Spectrum System Using Time Compression and Overlap-Add Techniques. IEEE Access is an open-access peer-reviewed journal so you will be able to view the article and the attached video without a subscription.

The technique evolved out of a discussion I had with my supervisor about how we could create an ultra-wideband (UWB) signal that was distinctly different from UWB pulse radios and UWB OFDM variants. The bandwidth is spread by playing the samples into the transmit DAC at a much higher rate than they were recorded. This is referred to as time compression in the literature because the time it takes to play back these samples is much shorter than the time it took to record them. It should be obvious that this results in an expansion in frequency, hence the wide bandwidth.

It should also be obvious that you cannot transmit continuously because you consume samples faster than they are produced. To solve this issue we borrow the overlap-add technique from audio processing, which is typically used to perform some sort of analysis/synthesis operation. Instead we use it to add redundancy to the signal in a way that can benefit the receive process. What is interesting is that the redundancy is not added to the bits as in a linear code, but directly to the modulated waveform.

If you watch the video attached to the paper, you will see the receiver that was used to implement this process. It is a ZedBoard-based SDR receiver but uses a high speed dual 1.8GHz ADC with interleaving capability that allows it to act as a single 3.6GHz ADC. With this device we have been able to receive standard narrowband signals such as FM broadcast continuously. The wideband functionality that can be performed in software is limited to buffer captures up to 2M samples at sample rates up to 450MHz. However, using a hardware timer to trigger a buffer capture at a fixed interval (typically around 250ms) can be useful for producing wideband waterfall displays. This is also the mode we use to implement the TC-OLA receiver. Wideband functionality in the FPGA is only limited by the device’s gate count, and so we intend to implement an FPGA-based wideband TC-OLA receiver in the future.

I hope to write a series of posts describing the design of this SDR for anyone who is interested. I received a lot of help from Jon Pendlum, who has done some excellent work on using FPGA-based accelerators in GNURadio using the Xilinx Zynq device.

Journey to the center of OS X, and a morse keyer.

Going on six years ago, I had a job working on drivers for pro audio gear under Windows (it was XP back then) and Mac OS X. After thinking about this one-sample delay problem, I vaguely remembered that Apple provides a way to plug in DSP code for a USB audio device based on the ProductID and VendorID. It would be trivial to write code to do the delay compensation. After jogging my memory for an hour or so I finally stumbled upon the SampleUSBAudioPlugin project which is exactly the thing I was vaguely remembering. This sample project illustrates how to perform low-pass filtering on an input and output stream of a USB audio device.

I dusted off Xcode and walked myself through how to build and load an OS X kernel extension again (six years is a long time to forget) and compiled it up. For some reason I have a linker issue when trying to compile for the 64-bit kernel, but it works just fine for the 32-bit kernel. Once I was satisfied that it was working, I made some very simple modifications to remove the low-pass filtering code and do the delay compensation.

I’ll have to figure out how to get it working for the 64-bit kernel, but overall it was a productive morning. I can now use the Samson G-Track with any software on OS X since the one-sample delay is compensated by the plug-in kernel extension.

As a side note, I’ve been fascinated by the morse code that I’ve been hearing and have been working on learning it. I spent a lot of time thinking about whether to order a nice paddle, or if I built one what would be the best design. One day I realized that thinking about the best design was not going to get a paddle in my hands any sooner, so after finding some inspiration I put this together in a couple of hours. Hey, it works.