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:

Photo0212

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:

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

Photo0215As 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.

4 thoughts on “Unpacking the USRP E310

  1. Thank you for posting this write-up. The E310 is very new, and we’re in the process of trying to fine-tune the out-of-the-box experience to make it seamless. Your blog entry is great feedback. Please let us know if you have any questions, or if there is anything that we can do to help as you use the E310. Please contact us at “support@ettus.com” anytime.

  2. So I have the same error as you GRC is expecting 6.x and it find 4.0… and while it was nice to see someone say they have my issue boy it would have been nice if you had laid out a more clear path to the solution 😀 to say the least I am not clear what the fix was, nor what I should be avoiding if I aim to follow your path.

    • Hey, Sorry I missed your comment until now.

      The solution that worked for me was:
      – Update to the latest image for E310 (see files.ettus.com)
      – Make sure UHD versions on the host and the E310 match
      – Re-link GNURadio to the new UHD version if necessary (easiest thing may just be to rebuild it).

  3. Hello,
    Its really good post for beginners who is new to Ettus E310. I’m new at that.

    Just want to know flow of making sample application.Means what things are required for running demo application with Ettus E310.
    Need help.

Leave a comment