Before we start, please note that the canonical driver installation instructions can be found on GitHub and if you run into any issues consult these in case something has recently changed.
Much of the software that we need is available in the form of packages that can be installed from the Debian Jessie repositories via the magic of apt-get.
$ sudo apt-get install gnuradio gnuradio-dev uhd-host libuhd-dev cmake g++ libpython-dev python-numpy swig libboost-all-dev libusb-1.0.0-dev
At the time of writing this will give us GNU Radio 3.7.5 and UHD 3.7.3, with the development files for both, plus their dependencies and those of software we will later build from source.
Note that we do not install the Debian gr-osmosdr package, as we’ll be building a more recent version of the GrOsmoSDR software that includes support for the Novena-RF hardware.
Setting up the driver
The Novena-RF driver is built on the vendor and platform neutral SDR support library, SoapySDR. For info on this and the driver architecture, see the previous blog post from Josh Blum.
First grab the SoapySDR sources:
$ git clone https://github.com/pothosware/SoapySDR.git $ cd SoapySDR $ git submodule init $ git submodule update
To build and install:
$ mkdir build $ cd build $ cmake .. $ make -j4 $ sudo make install $ sudo ldconfig
With SoapySDR installed we can now get the sources for the host driver, build and install this:
$ git clone https://github.com/myriadrf/Novena-RF.git $ cd Novena-RF/driver/host $ mkdir build $ cd build $ cmake ../ $ make $ sudo make install $ sudo ldconfig
Next we need to load the FPGA and kernel module, and set device permissions. Note that at the time of writing the pre-built novena_rf.ko module is for the 3.17.0-rc5-00238-gfb115dd kernel. A module for 3.17.0-rc5-00217-gfd79638 is also provided and to use this it must be renamed to novena_rf.ko. If you are running another kernel you will need to build it from source.
Assuming that we are running the gfb115dd kernel we just need to:
$ cd Novena-RF/driver/binary $ sudo ./prepare_novena_rf.sh
At the present time this script must be run after each reboot. However, this could be improved upon via the creation of udev rules and contributions are welcomed!
If upon running the script you get an error with “could not insert module novena_rf.ko: Invalid module format”, this means you need to rename the gfd79638 module or build a new one from source. If you have recently installed or upgraded your system it will almost certainly be the latter.
At this point we should have a functioning driver and can confirm this with:
$ SoapySDRUtil –make="driver=novena"
If everything has gone according to plan you should get an output similar to that shown below.
We can now run up the ASCII art FFT plotter example that is provided with GNU Radio:
$ /usr/lib/uhd/examples/rx_ascii_art_dft --rate=1e6 --freq=1.8e9 --gain=30 –ref-lvl=-60
This should provide an output similar to the one shown at the top of this post.
At the time of writing we are seeing a spike at the centre frequency, which we suspect is due to some tweaking that needs to be done to the LMS6002D transceiver programming or calibration. However, we are looking into this and hope to have a fix relatively soon.
SoapySDR provides a module that adds support to the UHD driver that was developed for the USRP devices from Ettus Research. This means that it should be possible to run many applications that were developed against its API with little or no modification, such as the ASCII art FFT plotter.
However, SoapySDR provides its own API also and GrOsmoSDR adds support for this from within GNU Radio.
To install GrOsmoSDR:
$ git clone git://git.osmocom.org/gr-osmosdr $ cd gr-osmosdr/ $ mkdir build $ cd build/ $ cmake ../ $ make $ sudo make install $ sudo ldconfig
Since the blocks get installed to /usr/local and GNU Radio has been installed via packages to /usr, you will need to tell GNU Radio Companion where to look for them before starting it:
$ export GRC_BLOCKS_PATH=$GRC_BLOCKS_PATH:/usr/local/share/gnuradio/grc
Note that in testing we found that GUI apps built with WX can easily consume a lot of CPU cycles and as a result their controls become frozen. The same is true if we use a software signal source and sink connected together, which rules out the SDR hardware and associated I/O. It could be that the GNU Radio and friends packages available via the repositories are not fully optimized, or the cause could be something else altogether. Further investigation is required.
We’d encourage people to test the driver and use with GNU Radio applications and others that use the UHD and/or SoapySDR APIs. A number of proposed enhancements have already been posted to the issue tracker and contributions are very much welcomed. As are reports of any issues encountered, along with successes running up your SDR application of choice.
Finally, I’d just like to take this opportunity to thank Josh Blum for all the amazing work he’s done!