Tag Archives: hackrf

Setting up GNURadio for Raspberry Pi 2

ACTUALLY just download this Raspbian image which comes with gnuradio + hackrf + all the good stuff already (magnet link, direct link).

Another possibility is to use the regular Raspbian image and add the appropriate ppa with a prebuilt gnuradio in it. See this link for more information about that. In short:

Edit /etc/apt/sources.list and add the following line:

deb http://archive.raspbian.org/raspbian jessie main

Then update apt and install gnuradio and gnuradio-dev:

sudo apt-get update && sudo apt-get install gnuradio gnuradio-dev

Installing gqrx + osmocom + related stuff is also recommended:

sudo apt-get install gr-osmosdr libosmosdr-dev gqrx-sdr

That should get you set up for developing with gnuradio, grc and related python things :)

So far I’ve found 500 ksps is about the maximum samplerate the RPi2 can handle when running gnuradio via Python. It might be possible to go faster, since hackrf_transfer claims a transfer speed of 20 MiB/s is possible (corresponding to 10 Msps).

I’m leaving the compilation guide I already started as-is, despite not getting it to do what I wanted. Perhaps it’ll be useful to someone:

This post is an attempt at document my getting hackRF One + GNURadio running on Raspberry Pi 2.

gnuradio requires CMake>=2.8.10 for NEON support, raspbian ships with cmake 2.8.9. Grrmblr. So install that first:

git clone https://cmake.org/cmake.git
cd cmake
git checkout v2.8.10
./configure && make -j3 && sudo make install

Three cores are used for make to speed things up (-j3). Four would cause X to hang. Configuring and compiling cmake will take a while, so go grab a coffee, do laundry or somesuch.

Next set up hackrf. I didn’t record this step, but if I recall correctly you need to download, compile and install gr-osmosdr. Something like this:

git clone git://git.osmocom.org/gr-osmosdr
cd gr-osmosdr
mkdir build
cd build
cmake ..
make -j3
sudo make install

You can check that you got it right by running hackrf_info, then hackrf_transfer -c 127 -f 433960000 to check that the transmit functionality works (remember to attach an antenna).

Finally it is time to install gnuradio itself. A small note on boost here, since it always tends to be a problem for people stumbling upon guides like this: I’m using version 1.49. At the time of writing the latest version available via apt was 1.50. The latest official version (outside Debian) was 1.60.0.

sudo apt-get install libboost-dev libboost-filesystem-dev \
    libboost-system-dev libboost-test-dev \
    libboost-program-options-dev python-pip libcppunit-dev \
    libfftw3-dev   #TODO: gr-fft doesn't build, figure out why
sudo pip install cheetah
git clone https://github.com/gnuradio/gnuradio.gitcd gnuradio
git checkout 72dcbdb  #optional, master as of writing
git submodule init
git submodule update
mkdir build
cd build
cmake ..
# For some reason NEON doesn't work, so disable it by in CMakeCache.txt changing the line
# to
nano CMakeCache.txt  #do the thing
sudo make install

This will build and install.. some parts of gnuradio. Not the Python stuff though, which is what I need. Fffffff-

On hackrf_transfer -c

Just a quick post on hackrf_transfer’s CW mode (-c). I’ve recently taken a HackRF One to a signal analyzer in order to make sense of how its DAC and gain values correspond to output power. In order to make use of this in GNU Radio one needs to know what byte sequence going into the DAC this corresponds to. Luckily this was easy to find out

hackrf_transfer.c has a line that reads “transfer->buffer[i] = amplitude;”, which implies the I/Q values sent are {amplitude,amplitude}. This means the actual samples have values of amplitude*(1+i), which is 40% larger or twice the amount of power than what you’d expect if say all the Qs were zero. You can see something similar to this in GNURadio if you feed a rectangular windowed FFT with “1″ vs “1+1j” constant sources (throttled). The former will have a 0 dBFS power while the latter will have +3 dBFS. Sort of a “turning it up to eleven” kind of thing :)

A recent commit to the git repository I have for this thing addresses this, such that you can use the same parameters for my CW transmitter as hackrf_transfer uses in its CW mode. Hopefully convenient!

Quick and dirty NFM transmitter in GNU Radio

Since getting my amateur radio license a while back I haven’t made much use of it, so yesterday I decided to try and do something about that. Unfortunately the handheld Yaesu VX-6E I ordered four weeks ago hasn’t arrived yet, so I decided to go an alternate route: figure out how to transmit narrowband FM using the HackRF One. The goal of the evening would be to get a conversation (QSO) going via the local VHF repeater on 145.650 MHz.

Some digging around on the Web showed that this is possible, but only as a transmit-only thing. Two-way communication is still tricky. GRC might not be a good enough tool for switching between TX and RX on a simplex device like the HackRF.

I eventually managed to cobble together a reasonable GNU Radio flow graph. After some poking around, with SA2KNG listening for my attempts at reaching the outside world, we figured the transmit power was too low, since even something very narrow like CW (Morse) was barely making it through the ~5 km distance from my location to Umedalen.

More digging around revealed that the RF amplifier on the HackRF may have some issues, and that there is an IF amplifier as well. Changing the IF amplifier setting from the default of +20 dB to the maximum of +47 dB made my signals go through quite well. It was time for the next part of my plan: activating the local repeater.

Activating the repeater simply means transmitting a 1750 Hz tone, which was relatively simple to extend the flow graph to do. The result was people on IRC noting that there’s a hell of a lot of beeping going on on the repeater. But I wasn’t hearing it. Why?

The answer turned out to be that the RTLSDR USB stick I was using for listening (via gqrx) was not picking up the repeater, but only my outgoing signal. A quickly constructed antenna (from a piece of TV coax) fixed that problem, and I was now able to repeat the experiment. I also added some courtesy features to the flow graph (push-to-talk, tone generator on/off). The end result was a successful (if noisy) QSO with SA2KNG. Success!

Picture time:

Transmitting antenna: 2 m/70 cm dipole

Receiving antenna: a 2 m dipole made from a piece of TV coax

Receiving antenna: 2 m dipole made from a piece of TV coax

SDRs. HackRF One and ezcap DVB-T FM DAB (RTLSDR)

SDRs. HackRF One and ezcap DVB-T FM DAB (RTLSDR)

GNU Radio notes

Some random notes about GNU Radio while I’m at it:

There doesn’t seem to be an easy way to implement a push-to-talk feature. For now I have hacked one together using a GUI slider that controls a “multiply const” box. The slider can only have the values “0″ or “1″, so it can be moved by tabbing to it in the UI and pressing the left/right arrow keys. I implemented a similar slider hack for enabling the 1750 Hz tone generator. Another problem is having to use an RTLSDR dongle for RX. I suspect this may be possible to fix by setting up a flow graph with both an RX and TX part, then enabling/disabling the relevant parts using some python code. The same python code could also read the keyboard, and maybe switch channels.

Here’s my code here in case someone else finds this interesting: nbfm-tx.grc. I’ve also attached a picture of the flow graph below:

GRC flow graph in picture form

GRC flow graph in picture form