I always wanted to try some alternative approaches to make the spectrum visible and audible. In the last days, I was playing a bit around; not with the whole spectrum, but, at least, with WiFi channel 1.

SpectroPhone -- Channel 1 in C Major

What happens here?

The canvas on the right is a live representation of the WiFi traffic on channel 1. Of course, I cannot see the content of the (mostly) encrypted signals. But I can record the signal strength, the size, and the hardware address of the sender.

The hardware addresses are not assigned randomly. Each manufacturer gets a certain range allocated by IEEE. A list of these address ranges is available on their website.

With this list, I can map each WiFi signal to the manufacturer of the chip that sent it.

What can I see?

For each signal that I overhear, I place a circle randomly on the canvas. I use the following mapping to represent the WiFi traffic:

• Color: manufacturer
• Radius: amount of data
• Fade duration: signal strength

Radius and fade duration are straight forward. To map the manufacturer, I hashed the name to an RGB color. (That’s the same thing as picking a random color for the first signal and sticking to the choice for the following.) I took some screenshots in different environments.

Left: Dublin’s buses use Realtek chips (yellow). Right: Apple is green. Here, my mobile phone was uploading something when I came in range of the university network.

Left: The “green college” uses infrastructure from Dell and D-Link, which were (by chance) both mapped to greenish colors. Right: The “pink streets” around the parliament.

Overall, the number and the size of frames indicate spectrum utilization, while the colors show the diversity of the hardware.

What can I hear?

To create an audio representation of the WiFi spectrum, I hash each manufacturer to a note in the c major scale. The WiFi signals then play the note. That means each WiFi signal increases the volume of the note proportional to the amount of data that it transmits. After that, the volume decays exponentially.

If there many signals from a manufacturer, the note will stay active as each signal pushes the volume up. If there are no signals, the volume goes down.

In the video, you might have noticed a constant beat from the small dark green circles. They are beacons from Virgin Media routers that are deployed everywhere in my neighborhood.

Update: Wi-Field

I took another walk through the spectrum. This time I created a starfield-like animation to visualize the frames. It doesn’t always render at full frame rate. So no happy eyeballs yet :-)

In addition, I down-scaled the volume a bit. The idea was to not clip at maximum volume if there are only beacon frames. That way, actual data transmissions would increase the volume, which was not always the case before. It didn’t work too well though.

Apart from that, I found it a bit unintuitive that frames that had very similar colors could produced totally different tones. Therefore, I mapped the colors first to their hue and used the hue to map to notes on the tone scale. This is a bit like mapping the spectrum of the rainbow to the scale.

Update: Star-Fi

I’m really excited to join SRS (www.softwareradiosystems.com) to work on srsLTE, their Open Source LTE implementation.

So it really happened; I moved to Ireland. To be honest, I didn’t think much before I actually went there. It was more like: what can possibly go wrong.

My plan was to throw everything in my car and just go there by ferry. That worked out pretty good and also the trip on the ferry was a cool experience.

I didn’t have a flat when I went there but had to spent the first days in a hostel. As it turns out, the housing market in Dublin is plain crazy. I took me about two weeks to find something that I could afford and that was not totally run-down. Now I pay absurd amounts for a tiny studio.

Unfortunately, my car, with all my stuff in it, was broken and everything that had some value was stolen. My mountain bike, my PC, my cloth, etc… all gone.

Now my possessions align pretty well with the space in my flat :-/

Some first impressions from around Dublin.

Christ Church Cathetral (left) and Trinity College Dublin (right).

Howth, a small fisher village at the cost north of Dublin.

The cliff walk between Bray and Graystone is beautiful.

Since the single-threaded scheduler was recently deleted in GNU Radio’s next branch, we’re left with the multi-threaded version. I guess this change doesn’t hurt too much. The multi-threaded scheduler is the default and, therefore, already used by the vast majority of users.

This scheduler starts one thread per block to distribute the load and parallelize processing to benefit from modern multi-core CPUs.

To understand how GNU Radio works under the hood, I wanted to see how these threads are created. What I expected to find were threads that run a static function that takes a block as parameter and handle its execution. What I found was a bit more complicated.

The scheduler maintains a thread pool. During startup it creates one thread_body_wrapper per block. This wrapper mainly masks signals like SIGINT.

Inside the wrapper, there is a tpb_container. Actually, this should be the function, but the tpb_container is a copy-able object that overwrites the operator() to appear like a function. Inside this overloaded operator, it instantiates a tpb_thread_body, which isn’t a function, but a class that implements the actual functionality in its constructor.

But even tpb_thread_body doesn’t actually execute the block. It has a member of type block_executor, which takes care of running work().

So to execute work() one just uses the block_executor which is a member of tpb_thread_body, which is inside a tpb_container, which is inside a thread_body_wrapper, which is a boost::thread, collected in a thread_pool. Easy as that…

I think this part of the code is not really accessible to potential contributors. In my opinion, we should try to reduce complexity as good as we can. Some initial thoughts:

• The scheduler is overly generic since it still contains code to select different schedulers. I think we should delete all unnecessary complexity and merge scheduler with scheduler_tpb.
• We could transform tpb_thread_body into what it actually is, a static function run by the thread.
• When tpb_thread_body becomes a function, it can be directly used by thread_body_wrapper and tpb_container can go.
• It would be strange to have one file and one class only for a single static function. This function could, for example, be added to block_executor, having something like static void block_executor::run().

We’d end up with something like:

auto f = boost::bind(&block_executor::run, blocks[i], block_max_noutput_items);
d_threads.create_thread(gr::thread::thread_body_wrapper<decltype(f)>(f, name.str()));

If you are interested, join the discussion.

Awesomely awesome! I won a Marie Skłodowska-Curie Post-Doc Fellowship, which funds me for the next two years. During the time I will work at CONNECT, Ireland’s Research Centre for Future Networks and Communications. CONNECT is spread across many institutions. I’ll be located at Trinity College Dublin and work in Prof. Linda Doyle’s research group.

For the fellowship, I had to come up with a project proposal that was peer reviewed. The review was positive and I was invited to an interview where I gave a short presentation and was asked (quite detailed) about the project.

I’m very happy that all went well. Especially, since the proposal was one of the first things I made on my own. (And the ability to conduct more self-guided research is the goal of doing a PhD.)

Overall, I was ranked second of 41 submission in my category, where 59% percent of the applicants had over four years of post-doc experience.

Recently, I visited the Mobile World Congress in Barcelona. Knowing only academic conferences, it was very interesting to attend an industry exhibition.

MWC was huge. Much bigger than I expected. In December I visited 33c3 and thought that this was already incredibly big with about 13k visitors. MWC had about 108k.

I found it most interesting to see what industry is currently up to. And compare it to what academia is currently up to. I know it shouldn’t be compared. The self-perception of most academics might be that they are working on stuff that will be at MWC 2020. Still interesting to see the different trends.

With regard to my dissertation topic (Vehciular Ad Hoc Networks), for example, I had the impression that academia is going for IEEE 802.11p, while industry seems to be all in on LTE for V2X.

I somehow seem to receive more and more emails. Would be great if they were part of interesting conversations, but that’s, unfortunately, not the case. Most emails are about my Open Source work and, in particular, about my GNU Radio IEEE 802.15.4 and IEEE 802.11 modules. As you might have guessed, most emails are not from users who are so super happy with my software that they just have to tell me.

That itself wouldn’t be a problem. But people spam me with very low-quality help requests. Most email would need a lot of back and forth until we arrive at a question that could actually be answered.

When I talk about this with friends, they think that I might just be too critic. But if I show them my inbox, they usually change their mind. The problem is that this is not only annoying, but I find it very stressful to deal with such non-sense on a daily basis.

Since it’s unlikely that people will change, I had to adapt my work flow.

I’m very proud to join the GNU Radio core developers to work mainly on runtime related issues.

Looks like, with this, I have unlocked several new buttons on GitHub. I will try to use them with care :-) And, of course, give my best to make GNU Radio even better than it is today.

I just received the reviews of my application for the EDGE Fellowship, which would allow me to spend two years at Linda Doyle’s research group at the CONNECT centre, associated with Trinity College Dublin.

The peer-reviews of my proposal were quite positive and I made it to the final round. The next step is a 30 minutes interview in person or via Skype.

Keep your fingers crossed :-)

When playing around with wireless mobile traffic lights, I also thought about options to transmit on the VHF and UHF bands. I remembered that I bought a Baofeng that I never actually used. Turns out, this radio is exactly what I was looking for, as it

• supports RX/TX on 136-174MHz and 400-520MHz
• is cheap (25 EUR)
• is portable

Furthermore, it has a line-in for an external microphone, which allows connecting the radio to the PC. There is quite some information available on how to do that properly. (I plugged it directly into the PC and it worked, but maybe it was plain luck that I didn’t fry my sound card. Most people recommend decoupling the circuits.)

To disable push-to-talk and automatically transmit when a signal is sent from the PC, you have to enable the VOX option.

As a proof-of-concept, I created a web GUI that allowed me to toggle the traffic lights in the browser. In response, the web server sent UDP frames to a GNU Radio flow graph, which created an audio signal.

Overall, the process looked as follows:
Browser → Web Server → UDP → GNU Radio → Audio Sink → Line-out → Baofeng