I just ported my GNU Radio out-of-tree modules to GNU Radio 3.8 and adopted the new proposed development scheme. That means:

• Legacy GNU Radio 3.7 support is provided through the maint-3.7 branch.
• GNU Radio 3.8 support is provided through the maint-3.8 branch.
• Future API-breaking changes towards GNU Radio 3.9 will be in the master branch. For now, master and maint-3.8 are similar.

The modules need some testing. So feel free to try them (and complain :-)):

• gr-ieee802-11
• gr-ieee802-15-4
• gr-foo
• gr-rds
• gr-keyfob
• gr-rstt

If you are also planning to port modules to GNU Radio 3.8, make sure to checkout the guide in the wiki. Overall, the process is rather straightforward. I used gr_modtool to create a module with a similar name and merged the build-related boilerplate code into my actual module.

Finally, some screenshots of the new flow graphs. (I still have to get used to these bezier connections…)

I’m currently looking into WLAN physical layer simulation models of network simulators to figure out how good they are doing. While studying the ns-3 implementation of the PHY error rate model, I noticed that they are using the number of coded bits to calculate the frame error rate. This seams weird, since all papers on the topic consider the number of data bits.

The bug just got confirmed and the issue should be fixed soon.

It means that for the last eight years or so, ns-3 used the wrong number of bits to calculate the error rate for a WLAN transmission. A 500 byte BPSK-1/2 frame, for example, was treated as a 1000 byte frame.

Fortunately, the impact is not too big. It is the shown by the figure below. The bug causes the error curves to shift to the next higher one (i.e., 100 byte → 200 byte, 200 byte → 400 byte etc.).

I also recently published a more comprehensible paper about the Veins PHY implementation.

• Bastian Bloessl and Aisling O’Driscoll, “A Case for Good Defaults: Pitfalls in VANET Physical Layer Simulations,” Proceedings of IFIP Wireless Days Conference 2019, Manchester, UK, April 2019. [DOI, BibTeX, PDF and Details…]

I just reviewed a paper that claimed that reactive jamming of ZigBee would only be possible with sophisticated devices that cost over $3000. There was, however, already a paper in 2011, which implemented a reactive ZigBee jammer by modifying the FPGA of a USRP2 SDR [1]. Furthermore, it was shown that low-cost CC2420-based nodes can be turned into a reactive jammer [2]. Since I recently bought a $40 ATUSB ZigBee USB dongle from Sysmocom, I wanted to give it a try with this device.

(The whole idea is very similar to my blog post about jamming WiFi ACKs with WLAN cards, which was based on Mathy Vanhoef’s work, who modified the Atheros ath9k_htc firmware [3].)

Some weeks ago I attended FOSDEM and was lucky enough to get a free PlutoSDR from Analog Devices. Yay! It’s mainly an SDR, but it’s also the first FPGA board that I got my hands on. Having the board, the motivation to learn more about FPGAs reached a local maximum. However, being an FPGA noob, I found the free-to-use development framework from Xilinx not very educational. I felt like there are many levels of abstraction between me clicking around in the GUI and the actual hardware.

However, I also knew that there was something going on around Clifford Wolf, who is working on Open Source FPGA stuff. So it was a good occasion to catch-up with his work. Long story short, he built a complete Open Source workflow for Lattice iCE40 FPGAs (and others seem to be work in progress). I bet some years ago most people wouldn’t have believed that this was possible and that we have to deal with vendor software for the rest of our days.

While iCE40 FPGAs are not the most capable FPGAs, they are cheap and – together with the Open Source tools – the ideal learning platform. If you are interested in the topic, I’d recommend Clifford’s recent talk at 35C3 about the state of the project. I had to try this out, so I bought a cheap iCEstick for around 25EUR. (I didn’t get the memo that the cool kids are now using the iCEBreaker board.)

I had no idea about FPGAs, but I found an excellent tutorial on GitHub. It is in Spanish but Google Translate can jump in here.

The general workflow of IceStorm, Clifford’s Open Source tools, is to write your design in Verilog and

• synthesize it with Yosys
• place and route with NextPNR
• create the bitstream with icepack
• copy the bitstream on the device with iceprog

…no worries, a Makefile has you covered.

I got a paper accepted at Wireless Days 2019! The paper is about the physical layer simulation model of a popular network simulation framework for vehicular networks.

It shows that (1) the default parameters used in the simulator are highly unrealistic and (2) adopted by many users.

• Bastian Bloessl and Aisling O’Driscoll, “A Case for Good Defaults: Pitfalls in VANET Physical Layer Simulations,” Proceedings of IFIP Wireless Days Conference 2019, Manchester, UK, April 2019. [DOI, BibTeX, PDF and Details…]

I’m a TPC member of IEEE MASS 2019, which will take place in Monterey, CA on 4–7 November 2019.

I’m excited to organize a workshop on Open Radio Platforms for 5G Research and Beyond, which will be held in conjunction with CROWNCOM in Poznan, Poland on 11–13 June 2019. I’m really looking forward to it, since it’s the first academic event that I’m organizing. And, of course, please consider submitting :-) The deadline is 29 January 2019.

I’m part of the TPC for IEEE WCNEE 2019, which will be held in conjunction with IEEE INFOCOM in Paris, France between 29 April and 2 May 2019.

I’m a TPC member of the 89th IEEE Vehicular Technology Conference, which will be held between 28 April and 1 May 2019 in Kuala Lumpur, Malaysia.

I’m a TPC member of VEHTIS 2019, the 5th International Conference on Vehicle Technology and Intelligent Transport Systems, which will take place on 3–5 May in Heraklion, Greece.