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

I just came back from some very nice days in Brussels. On Thursday and Friday, I joined the DARPA SDR Hackfest, which was all about characterization and detection of incidental interference sources. Unfortunately, I was one day late and missed the discussion and teaming phase. I, therefore, did not contribute to the actual hacking, but, nevertheless, had some very nice days.

It was a great get-together and DARPA was an fantastic host. For the hackfest, they booked the top floor of The Hotel, where we had an awesome view over Brussels.

On Saturday, there was a very dense and interesting program in the SDR DevRoom of FOSDEM 2017. During the whole day, people were queuing in front of the door. I also gave a short talk about me playing around with mobile wireless traffic lights.

Apart from that, I was very proud to be invited to the SDR panel on Which are the top 3 challenges for free software radio?. I don’t know if I had much to contribute, since the other panelists were so much more experienced than me. They were Francois Quitin (Prof. in Brussels), Ben Hilburn (Head of GNU Radio), and Tom Rondeau (DARPA Program Manager). Anyhow, I’m very grateful for this awesome experience.

Recently, I came across Mathy Vanhoef’s amazing work on advanced WiFi attacks. He modified the firmware of off-the-shell WiFi cards from Atheros to implement constant and reactive jamming.

Fortunately, Mathy released the code under an Open Source license and even prepared a VM with everything pre-installed. The firmware modifications are compatible with three different types of WiFi cards, two out of which are available on Amazon and Ebay. Of all things, the only card that supports both the 2.4GHz band and the 5GHz band seems to be very hard to get.

To implement reactive jamming he had to use a little trick: The WiFi card consists of a transceiver chip and micro controller. When the transceiver receives a frame it writes it to memory that is shared with the micro controller. For reactive jamming, firmware of the micro controller is changed to busy wait for decoded data from the transceiver.

Once the first bytes are decoded, the firmware matches fields like the frame type or the MAC address to predefined patterns. If the frame is supposed to be jammed, the firmware aborts reception and triggers transmission of an interfering frame, jamming the signal.

Of course, there is some delay between detection of the frame to sending the jam signal. And, in fact, it turns out to be too high to jam, for example, acknowledgment frames (ACKs). Anyhow, I found it pretty amazing that it is possible in the first place. Furthermore, if you have fixed sized frames, it is possible to work around the limitation by detecting the data frame and delaying the jam signal until the ACK is sent. That worked surprisingly well.

• Mathy Vanhoef and Frank Piessens, “Advanced Wi-Fi Attacks Using Commodity Hardware,” Proceedings of 30th Annual Computer Security Applications Conference (ACSAC 2014), New Orleans, LA, December 2014, pp. 256-265. [DOI, BibTeX, PDF and Details…]