GRC2012 - Hackfest

VOLK Profiling

Work by Ben Hilburn, Philip Balister, and Doug Geiger focused on using the ARM cycle counter for profiling VOLK kernels. Ben wrote a patch that lets you use the ARM cycle counter from within the VOLK profiler. This is working, and you can use it immediately using this patch here:

That said, it is not immediately useful because the VOLK profiler runs operations hundreds / thousands of times to amortize overheads. That is great for measuring performance in terms of time, but makes measuring cycles nearly useless. 

Ben will continue developing the VOLK profiler to make the ARM cycle counter more useful. There are a few commits on the plane, but there hasn't been the chance to finish the work up yet. This development is taking place here:

Moer to come once the work is done.



New GNU Radio Companion Features

The two Tim's did some excellent work last week on GRC (GNU Radio Companion) during the conference and Hackfest that deserves being promoted.

1. The ability to reload GRC to update existing blocks or when adding new blocks. You no longer have to shut down and restart to get the new blocks. There is a button with a blue arrow in a circle that has the pop-up text 'Reaload blocks' that you click to get this feature.

2. If a hier_block you are using in a flowgraph was made using GRC, you can now open up the hier_block to see how it's constructed. This doesn't work with hier_blocks created in GNU Radio in Python/C++, though. To use this, you click the button with the orange down arrow (right next to the Reload blocks button) that reads 'Open the source of the hierarchical block.'

3. Automatically create hier_blocks from grouped blocks in a current GRC flowgraph. You highlight a set of blocks and hit 'c' or right-click and 'Create Hier' to automatically build a new hier_block that opens in GRC with the probes in place. Any parameter/variables become parameters in the new graph. You can then save and generate the block. Using the features mentioned above, you can then use the 'Reload Blocks' to get access to new block, which you can now also open up to see what's underneath.

These three features greatly extend GRC's capabilities and ease-of-use and have already been published on the master and next branch of the main GNU Radio source, and so obviously will make their way into the next releases.


I'm also trying to keep track of bugs and small features people are interested in from the Hackfest. I'll try to keep this updated if any new ones come in:

- 'filter' module did not seem to be imported into GRC even after a filter block was dropped in. This was probably my error since I'm sure I've done it before. Will recheck.

- SNR skewness estimator makes sense in simulation, did not produce anything usable with OTA tests.

- QTGUI: allow setting of time sink's y-axis from GRC for easy defaults.

- QTGUI: look into an alpha scale (transparency) in plotted lines (would help with constellations).

- QTGUI: Create a trigger for the time sink.

- Configuration files: I noticed that when installing two versions of GNU Radio, I had /opt/gr3_6 and /opt/gr3_7, but the etc directory was located in /opt/etc.

- Instrument BERT tester with new SNR estimators.


SNR Estimators

Fairly recently, we updated the SNR estimator blocks for M-PSK signals to allow the user to select from four different algorithms. We wanted to test to see how well these performed in over-the-air scenarios. One algorithm, the one based on the skewness estimation, showed not to work at all and needs more study. We will ignore this and focus on the 'Simple,' 'M2M4,' and 'SVR' methods. (you can find more about the different algorithms by looking at the documentation of the SNR estimator blocks, which provide some discussion and references.)

You can find code for this is on my github repo under the 'grcon12_hackfest_qam' branch: git://

Note: this branch will probably be changing some. Many of the bug fixes issued here will make it back into our normal GNU Radio source soon and only the hackfest-specific code (the GRC files, mostly) will be different here.

Also note: this is named '_qam' because we were also able to fix and demonstrate using 16QAM over the air and and 64QAM under simulation.

The GRC files can be found in gr-digital/examples/hackfest.

Visualizing the SNR

We instrumented a couple of blocks and created flowgraphs so that we could visually see the SNR estimates. The transmitter (uhd_psk_transmitter.grc) used a USRP N210:

This shows that we are transmitted a QPSK signal (4 samples/symbol, RRC filter with 0.35 rolloff). We can adjust the frequency, gain, and digital amplitude of the signal.

At the receiver, we can use both an RTL-SDR (rtlsdr_snr_receiver.grc) or a UHD device (uhd_snr_receiver.grc). A snapshot of the RTL-SDR with high SNR looks like:

So the SNR here is just the estimate out of the M2M4 estimator. The bottom graph shows the frequency domain after the signal has been raised to the fourth power. The center spike shows the carrier and the side spikes are at the plus and negative of the symbol rate. This was used so that I could adjust the fine frequency knob to adjust for frequency offsets (the constellation_receiver corrects for fine frequency and phase offsets and tracks changes as well; this was to get us in the ballpark). Also, the red in constellation plot is post equalizer and blue is pre-equalizer.

I just updated these GRC files so that we can view all three SNRs at the same time. The next graph shows all three (blue: simple, red: M2M4, green: SVR) together. Something not obvious here is that the pre-equalizer signal has a huge hole in the center of where the constellation points should be. The two USRPs were not in a line-of-sight path and so apparently had pretty bad multipath effects going on here. The equalizer cleans it up nicely, though.


The question being asked here is whether or not the SNR estimators make sense, which is cataloged in the following tables.

Using the RTL-SDR receiver.

Tx Amp Tx Gain Rx Gain Simple M2M4 SVR
0.15 5 15 20 20 20
0.15 0 15 16 16 16.5
0.075 0 15 10.5 10.5 11.5
0.0375 0 15 10 7 6

Using the USRP N210 as the receiver.

Tx Amp Tx Gain Rx Gain Simple M2M4 SVR
0.05 0 5 22.5 22 23
0.025 0 5 17 17 17
0.0125 0 5 11.5 11.5 11.5
0.00625 0 5 7.5 6.5 7

We can see that the three estimators track each other pretty well and they almost match what we should expect. A drop of the amplitude of the signal by half should produce a decrease by 6 dB in SNR. We see almost that in most of the cases. In my mind, this is a success for the estimators.

What we experience here is that of other issues entering into the system. First, we have multipath, at least in the case of the N210 results. Also, we were too close and so the signal power was difficult to adjust appropriately. With the RTL-SDR, we were actually hitting below the receiver's sensitivity by the end, so the signal became too weak for it to pick up. Similarly, the N210 was acting too well as a receiver, and so we ended up reducing the transmit amplitude below the DAC's quantization levels. In both cases, we were greatly distorting the signal and so the SNR estimation becomes completely wrong.

The next question to answer (later), is how well the estimators work at low SNR. We expect the simple SNR to start performing poorly after somewhere between 7 and 10 dB. The others should track farther towards 0 dB. For this, we need a better experimental setup to keep the transmitter and receiver's both with the quantizer range as well as within the linearity ranges of both transmitter and receiver analog components.

GNU Radio Scheduler Latency

Tim O'Shea worked on improving latency within a GNU Radio flowgraph by being able to adjust the size of the buffers. He worked on looking at two features that will be worked into GNU Radio: the ability to set the maximum noutput_items and the ability to actually control the size of the buffers.

The results are mostly based on the latter and can be found here:


USRP Latency Measurements and Control

Balint Seeber and Matt Ettus worked on analyzing and providing tools to help understand the latency issues involved in USRP hardware over Ethernet. They provided a great demonstration and tools to measure and analyze the problem.

The best place to look up more information on this project and the tools developed for it is on Balint's own webpage:



The HackRF table worked primarily on libopencm3, an open source library for ARM Cortex M-series microcontrollers. We added register data for the LPC43xx to my fork:

It will be pushed upstream eventually.

We also got LPC43xx USB boot working.  This will be scripted and added to libopencm3 as well.

GRCon12 Hackfest Results

For those of you not following or who weren't there, the final day of the GNU Radio Conference 2012 was an open Hackfest. We all got together with our computers, radios, and other hardware, and got to do some hacking. There were a number of interesting projects that were started, continued, and explored. I really hope everyone involved had a good time and learned a lot.

One important thing about a hackfest like this is to make sure the code we worked on doesn't get lost! I'll be using this page to try to disseminate information about the work and where more can be found, including any further projects and, probably more importantly, the code.

Hacking on GNU Radio to improve performance on ARM processors.


These guys helped me out looking over some digital comms hacking.


And here was the HackRF table hard at work.