Some Quick History
The last time we demoed bringing the B205mini into REDHAWK, it was again using Docker to containerize an environment conducive for a more recent version of UHD. Back then, we were working in different constraints:
- REDHAWK 2.0.2
- CentOS 6.7 64-bit
One constraint required the other, and the other required an older version of Boost than the RPM installation of REDHAWK was compiled against. If you wanted to run a USRP like the B205mini, it meant first uninstalling the YUM-based Boost, then re-installing Boost from source, then upgrading UHD. And because you upgraded Boost, so too did you have to compile REDHAWK from source. It was a real bummer of a process that had all manner of repercussions if you did this to your host OS. Wrapping it in a container pulled some of the sting out in favor of repeatability, but the point was made: bummer.
Current State
Starting with the most recent versions of REDHAWK, CentOS 7 has been added as an openly-supported OS. This one change gave us all a recent-enough version of Boost that we can support a more recent version of UHD, and therefore newer hardware.
…Except that the RPM -based installation of REDHAWK still includes an older version of UHD than we need, which means that the USRP_UHD REDHAWK Device from the YUM repo also could use a rebuild.
Around the same time of the transition to CentOS 7, a subscriber to our YouTube channel, 0xBAADF00D, pointed this version issue out and asked about our old, docker-usrp image — if it would help in this situation. Since it was out of date (2.0.2 vs. 2.0.5) and planned for this, now present, upgrade, we worked through the process of removing both of those packages and recompiling them from source to basically upgrade an YUM-based installation of REDHAWK 2.0.5 to include UHD 3.10 (and new hardware support) on the host OS.
While not nearly as rough as the CentOS 6 -based issue, you still have to be mindful of installing any packages that might also re-install the old UHD. And we’re back: bummer.
Naturally then when it came to Docker-REDHAWK: we knew a USRP image, wrapping the above, would be useful to someone. So we made it along with one for the BU353S4 GPS Receiver and the RTL2832U USB dongle. So with that one stack of images, you can actually stand up a great deal of functionality, which is the point of this post: How easy is it to do …X?
The USRP Image
Let’s start with what’s in it.
It’s a YUM-based REDHAWK installation with the UHD and USRP_UHD packages removed. We then compiled UHD 3.010.001 from source followed by the USRP_UHD from RedhawkSDR’s repository. Then to facilitate running nodeBooter, we have supervisord installed with a configuration for it.
That’s basically it. As with all of the images, we tried to whittle each down to just the essentials for easier network -based distribution, so that this can scale without needing FTMD (fiber to my desk).
Startup Design
The USRP image, like our GPP and other Device images provide you with environment variables that map to arguments on the Device’s nodeconfig.py script — the script that can easily wrap the Device in a Node definition. If you’re familiar with that script, this will seem natural:
| Variable | Purpose |
|---|---|
| DOMAINNAME | The REDHAWK Domain Name |
| NODENAME | The name of the resulting Device Manager instance |
| USRP_IP_ADDRESS | For networked USRPs, this is how to set the IP |
| USRP_TYPE | The enumeration for --usrptype such as b200 for the B205mini |
| USRP_NAME | The name of the device (as seen in various UHD utilities) |
| USRP_SERIAL | The serial number of the device |
These options are in addition to the OMNISERVICEIP, which is used to reconfigure the /etc/omniORB.cfg settings so that the container can join a remote OmniORB server.
Note: If you’re using the helper script,
usrp, it exposes all of these options as well.
Also as in the other Device-wrapping images, each of these actions — configuring OmniORB and creating the customized Node definition — occur as part of the bashrc and profile so that with a login shell, the container auto-configures to the environment variables including the Node definition. With a non-login shell, it only configures OmniORB. The default container command then is to supervisord, which runs nodeBooter -d for the given Node name. Simple.
Demo
Our demo of the USRP image is straight-forward, starting first with pulling the images from DockerHub. We need the OmniORB services, so that container is started. We also need a Domain, so we launch one. Then we can launch our USRP… However we have no way to use it other than to setup allocations through the python shell or the IDE. So we start a container instance of the IDE with our SDRROOT and workspace volumes mounted (in case we want to do some development later). And finally, we tune into the FM radio band.
So to recap: we went from no trace of REDHAWK installed on Ubuntu 14.04 to a fully functional REDHAWK system in about 5 minutes, if you neglect the download time. And that system:
- Is compatible with other CentOS 7 YUM-based REDHAWK installations: you can run their Components, they can run yours
- Can host OmniORB and/or Domain services for other REDHAWK entities (containerized or not)
- Ran the REDHAWK IDE in a container with a development workspace
- Tuned RF with an Ettus B205mini attached to the host
And because someone would probably ask: Yes, it comes in Ubuntu Flavor, if you’re into that sort of thing.
Enjoy the video!
