Carriers Everywhere

I love Spacemacs. It’s by far the most awesome editor I’ve ever used. Strictly speaking, it’s Emacs, but considering their modifications, Emacs is more the run-time environment.

Spacemacs bundles Emacs plugins to so called layers that come with a sane and consistent configuration including mnemonic key bindings. A central layer is Evil, it brings Vim’s modal editing to Emacs. With Evil, large parts of Spacemacs just feel like Vim, but with the extensiblity of Lisp under the hood. (I used Vim over the last, maybe, 15 years and was super happy. But what I loved is the editing concept, not the binary.)

I tried Emacs several times in the past, but never got the hang of it. With Spacemacs, it’s really easy to get started since it provides a complete, nicely configured environment by default. For me, it was much easier and much more motivating to start from there than to start from scratch. Spacemacs is really worth giving it a try. Let alone because of Org mode, a fantastic todo list and outlining tool.

GNU Radio Configuration

When I don’t have to write stuff, I spent most of my time working with GNU Radio. This post will be a walk-through of my configurations to make Spacemacs a nice environment to work on GNU Radio.


As I already mentioned, Spacemacs bundles plugins in layers that serve a specific purpose. I have lots of them installed, but for C++ development the most essential are:

  (c-c++ :variables
         c-c++-enable-clang-support t
         c-c++-default-mode-for-headers 'c++-mode)
  (syntax-checking :variables syntax-checking-enable-by-default nil)
  (version-control :variables
                  version-control-diff-tool 'diff-hl
                  version-control-global-margin t))

Projectile Other File

Projectile is a plugin that brings the notion of projects to Emacs. It will look for a .git folder (or any other version control folder) in the parent directories and, if one is found, use that as the project root.

One feature of projectile is to open other files. The corresponding header to a C++ file, for example. We just have to tell projectile, how alternate files look.

(with-eval-after-load "projectile"
  (push '("cc" "h") projectile-other-file-alist)
  (push '("c" "h") projectile-other-file-alist)
  (push '("h" "cc" "c") projectile-other-file-alist))

From there on, we can use ",ga" to jump to alternate files in the same buffer or ",gA" to open it in a new window.

read more

So much spectrum – so few networks. The 5GHz WiFi band is in many areas not really utilized. OK, it doesn’t penetrate walls as nicely as the 2.4GHz band, but that’s not always a drawback.

One reason why the 5GHz band is not as crowded as it should be, might be the fact that WiFi is only a secondary user on many channels. These channels are allocated primarily to radars. Maybe you already came across the term Dynamic Frequency Selection, the feature that allows a WiFi device to detect radars. Without DFS, a device is not allow to open an access point on those channels.

The WiFi standard, however, only defines routines to migrate a network to another channel, once a radar has been detected. The actual radar patterns are defined by a regional regulatory body.

On Linux, you can check your DFS region with:

$ iw reg get
country DE: DFS-ETSI
    (2400 - 2483 @ 40), (N/A, 20), (N/A)
    (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
    (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
    (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
    (57000 - 66000 @ 2160), (N/A, 40), (N/A)

For Europe, the ETSI EN 301 893 Draft defines the actual radar patterns (see Annex D for the definition). Once a radar is detected, an access point has to blacklist the corresponding channel for 30 minutes.

Of course, I wanted to emulate a radar and see whether the APs move away. “Implementing” these radar patterns in GNU Radio is as simple as it can be. A flow graph like this is already enough.

The vector source can be used to create the radar pulses with something like:

[1]*5 + [0]*10

I tried the above flow graph with a B210 and a 6dBi dipole in the hall way of our institute. Worked pretty well, i.e., I managed to push away many networks from DFS channels.

By the way, macOS comes with a pretty nice tool to scan for WiFi networks. You can access it by alt-clicking the WiFi symbol in the task bar. This will open an extended menu, where you can click on Open Wireless Diagnostics. Then, WindowScan will open the tool.

You can see the tool in a brief video, where I’m poking some University networks around.

Recently, they placed a pair of wireless traffic lights right in front of our university. Today, I had the time to have a brief look. Very convenient to put them close to eduroam and coffee :-)

Turns out, they use the same frequency band as the traffic lights that I studied earlier (around 170MHz), but use a different modulation and frame format.

Recording the signal with GQRX and loading it in Inspectrum, revealed a kind of FM in FM modulation, similar to AFSK. The inner FM signal is 1200 baud, altering between 1200Hz and 1800Hz.

Extracting the preamble is straightforward thanks to Inspectrum. Once the preamble is known, GNU Radio will help us to demodulate the data. This time, I though I do a quick recording, showing how I use vim to reverse the frame format.

The work flow, described in a previous post, allows me to easily switch between offline signal processing and a live receiver. So creating a web GUI with live updates was basically no effort.

The light was pretty bad this morning, so I couldn’t record a nice video. Here is the one from the last year in case you are interested; it’s the very same setup.


A (shaky) video of the new traffic light.

Recently, I had a hard time compiling the GNU Radio next branch on macOS. The main problem is that next switched to QT5, which uses QWT6 for plotting. Unfortunately, QWT6 is not yet available in Homebrew, but has to be installed manually.

Compillation is rather straight forward, but there are several pitfalls:

  • GNU Radio searches for a package config file for QWT6. This is not created by default and has to be configured in qwtconfig.pri.
  • QWT installs itself as a framework, which is a special type of shared library on macOS. This doesn’t work for GNU Radio as it uses the QWT_LIBRARIES variable in cmake, which is not set for a framework. That means you will have to edit the package config file and replace the framework config with a corresponding shared library configuration. (This also requires adapting libdir and includedir.)
# old
Libs: -F${libdir} -framework qwt
# new
Libs: -L${libdir} -lqwt
  • GNU Radios cmake config does not support setting the library with -lqwt and adding its path to the shared library search path with the -L switch. Instead, I had to add the full path to the library with
Libs: -L${libdir} -l${libdir}/qwt
  • The last problem was that QWT did not set its install name to its full path. While there is a configuration option especially for that, it did not work for me. I had to manually change the library name with
install_name_tool -id '/Users/basti/usr/.../qwt' qwt

Hope it helps.

…aaand it’s gone. The WX GUI was recently deleted in GNU Radio’s next branch.

I just finished porting all my modules to QT. For the weather balloon receiver and the RDS transceiver, it was a bit tricky since I use custom panels.

They now look like this:

Please let me know if there are problems.

I just wanted to give a brief update of my key fob project. Maybe you remember that, following a recent paper, it seems as if the firmware of VW ECUs contains a master key that can be used to clone arbitrary keys by overhearing a single transmission. I already blogged about that earlier.

In the meantime, my Comfort Control Unit arrived. I’m pretty confident that this is the ECU in question since it’s also made by Hella, the company that sells the keys. Here are some photos from the board.

read more

Today, I was happy to merge pull-request from Jonathan Brucker that added RFtap support to some of my OOT modules. RFtap bridges the gap between SDR transceivers and network monitors like Wireshark.

In a nutshell, it reads metadata (like encoding, SNR, or frequency offset) from the receiver and makes it available to the monitoring software. What’s really great is that RFtap can be extended with custom dissectors. In this blog post, Jonathan describes how he connect my gr-rds transceiver to Wireshark.

Note that while there is something very similar available for WiFi (the Radiotap header), RFtap is more flexible and allows adding more fine-grained information.

I’ve recently seen a great video where a student gave a brief overview of his paper. I think it’s very nice to have this executive summary as an ad for the paper. So, of course, I wanted to give it a try.

Strangely, I found it way, way harder than expected. Looks like giving a monologue to myself is something I am not used to.

So here is what I came up with. Good thing is, it leaves much room for improvements :-)

Bastian Bloessl, Mario Gerla and Falko Dressler, “IEEE 802.11p in Fast Fading Scenarios: From Traces to Comparative Studies of Receive Algorithms,” Proceedings of 22nd ACM International Conference on Mobile Computing and Networking (MobiCom 2016), 1st ACM International Workshop on Smart, Autonomous, and Connected Vehicular Systems and Services (CarSys 2016), New York, NY, October 2016. (to appear) [BibTeX, PDF and Details…]