Plagiarism 2.0

Looks like the new metric to measure the impact of a scientist is no longer the h-index or something, but the number of plagiarized papers. In a sense it’s the ultimate endorsement if someone puts his name on your work :-)

Yesterday, I found my second case and, therefore, have a p-value of 2! (I think p-value is a good name; it’s not used for anything important, right?) I also blogged about the prior case.

The current paper is again in an Indian journal. I immediately recognized our TikZ figure, which they even messed when rescaling. (Poor figure!)

Also the text is—let’s say—inspired by our work.

If you want to have a look, our masterpiece of science is available here, while the Indian paper is available here.

GQRX for Digital Signals

Last weekend, I talked briefly about using GQRX as a graphical frontend for digital modes at the Software Defined Radio Academy held in conjunction with HAMRADIO.

The idea was to show how GQRX can be combined with other software to (re)use it’s nice GUI. With some plumbing, that’s easily possible. In the talk, I showed how this can be done for Multimon, Inspectrum, and custom GNU Radio receivers. I didn’t talk about Audacity and Baudline, since, I think, they are made obsolete by Inspectrum; but more later.

To record WAV files, one has to press the Rec button, while UDP starts streaming the audio signal through a network socket. The IP address and the port can be configured as shown in the picture.

Mutlimon

Multimon is a command line tool to decode various digital modes, like AFSK, DTFS, and POCSAG. POCSAG is a pager technology, which is often used by ambulance and firefighters in Germany and, therefore, maybe the most interesting.

Using SoX, the Swiss Army Knife of audio conversion, the output of GQRX can be easily fed into Multimon. On my systems the commands differ a bit for MAC and Linux since they come with different versions of netcat.

On Linux

nc -l -u -p 7355 |
sox -t raw -esigned-integer -b 16 -r 48000 -
    -t raw -esigned-integer -b 16 -r 22050 - |
multimon-ng -t raw -a POCSAG512 -a POCSAG1200 -f alpha -

On MAC

ncat -l -u -p 7355 |
sox -t raw -esigned-integer -b 16 -r 48000 -
    -t raw -esigned-integer -b 16 -r 22050 - |
multimon-ng -t raw -a POCSAG512 -a POCSAG1200 -f alpha -

Using the system, in that case for AFSK, looks like this.

read more

GRC Updates with VIM

Today, I noticed that with recent GNU Radio Companion updates, all my OOT modules are listed under the unmaintained-crap category.

If you hover over the top-level category, the tooltip says something like please contact the maintainers of these modules.

I couldn’t find any announcement or documentation, but I think the idea is to change the XML files that describe the blocks from something like

<category>IEEE802.11</category>

to

<category>[IEEE802.11]</category>
read more

GNU Radio WiFi Updates

I worked quite a lot on my GNU Radio WiFi transceiver and have some new stuff that I wanted to share.

The features introduced in this post are currently available in the development branch, as I plan further tests before merging them into master. If there are any problems with the development branch, I’m very happy to help.

Apart from testing, I’m still waiting for some fixes to the GNU Radio scheduler to get merged. Currently, GNU Radio does not allow to properly shut down some run to completion flow graphs that I use in simulations.

Sampling Offset Estimation

The frequency offset and sampling clock offset estimation was improved. The Sync Short and Sync Long blocks, which perform synchronization based on the short and long training sequence, now annotate the estimated frequency offsets. Later in the signal processing chain, this information is extracted and used to also estimate and correct sampling clock offsets.

The algorithms follow the paper “Frequency Offset Estimation and Correction in the IEEE 802.11a WLAN”, by Essam Sourour, Hussein El-Ghoroury and Dale McNeill.

Restructuring

One of my goals was to support more complex state-of-the-art channel estimation algorithms. Such algorithms are often decision-directed, i.e., they use the distance of data symbols to their ideal constellations point to adapt and improve the channel estimate over time.

Decision-directed equalizers have to know about the encoding of the current frame and the demapping decision. I, therefore, combined channel estimation, signal field decoding, and demapping of constellation points in one block.

Using WiFi constellation objects this was not as painful as it sounds. The new block, called Frame Equalizer provides also a very easy to use interface to plug in different channel estimation algorithms.

Channel Estimation

I used the new interface to implement some baseline and state-of-the-art algorithms. Currently, one can choose between LS, LMS, linear interpolation with the comb pilots, and Spectral Temporal Averaging (STA). The algorithms can even be changed during runtime.

read more

Not in Love with the GNU Radio Scheduler (Part 2)

This is the second post about my current work on the GNU Radio scheduler. The first post was mainly about shutting down run to completion flow graphs, often used in simulations and unit tests. The patch set, which also includes the changes proposed in this post, is still under review.

Blocking Wait is Always Bad

The most important change is the removal of the delete_head_blocking() function that could be used to block while waiting for messages. At least since the introduction of the system port, blocking wait is always a bad idea. If a block is waiting for a message on one port, it is deaf to any other notifications and it’s not possible to, for example, shut it down by sending a done message to its system port.

The only reason this function was introduced, was to work around shortcomings of the scheduler. The problem is that the scheduler does not support blocks with message inputs and stream outputs. Currently, it’s not possible to schedule these blocks only when a message has arrived.

Instead, busy-waiting has to be applied, wasting one CPU core for every block that has to check for messages in the work function; like PDU to Tagged Stream block, for example. See also this discussion on the GNU Radio mailing list from 2013.

To minimize the effects of busy-waiting, delete_head_blocking() was extended with a timeout. It doesn’t solve the problem, but allowed something like throttled busy-waiting.

Also the code acknowledges the problem in the pdu_to_tagged_stream block, for example.

/* FIXME: This blocking call is far from ideal but is the best we
 *        can do at the moment
 */
pmt::pmt_t msg(delete_head_blocking(PDU_PORT_ID, 100));
  if (msg.get() == NULL) {
    return 0;
}

This problem is what is supposed to be addressed by the current patch set. It removes the delete_head_blocking() function and extends the scheduler to call blocks only if samples or messages are available. That means that the block’s work function checks for messages and either processes them directly or returns immediately without blocking.

The only place to block is the scheduler, since it allows to wait for samples, output buffer space, and messages all at once.

read more

Blogging with Gulp

Static site generators are great for blogging. They allow working offline, using a real editor to write posts and produce HTML sites that can be hosted easily.

I’m not a big fan of web applications with crappy WYSIWYG editors that cannot be used offline in combination with Markdown and git. To make things worse, webapps are often slow, inject tons of unneeded stuff in websites, and open up a large attack surface. Therefore, I never really considered using Wordpress, for example.

Over the last years, I tried several blogging frameworks, migrating from Octopress, to Pelican, to Hexo. While they seem great on a first look, I always had problems in the long run. With Python, the dependencies are a mess (also with pip and virtualenv). And Hexo—I tried really hard to love it, but the code is just not intuitive to me and the code quality (especially of the plugins) is not too good.

Last week I was annoyed enough to rework my blog and, finally, got rid of blogging frameworks all together. I migrated to using Gulp with Nunjucks templates, Markdown, and some custom functions. In other words, I programmed a minimal blog with Gulp, using about 550 lines of code.

The code to create posts, for example, looks like this:

gulp.task('posts', function() {
    return gulp.src('content/_posts/*.md')
        .pipe(frontmatter({property: 'frontmatter',
                           remove: true}))
        .pipe(extractMetadata())
        .pipe(renderPage())
        .pipe(extractOpenGraph())
        .pipe(renderTemplate('post'))
        .pipe(gulp.dest('dist'));
});

It searches for all files in the posts directory, parses their front matter (which includes title and tags), and extracts metadata like the URL and the date from the file name. The resulting buffers are rendered in two steps; first the post’s content, then the whole HTML file.

The process is split, since the post’s content has to be rendered in multiple contexts, like in the page of the post and the blog index.

read more

GNU Radio Frame Generation for Simulations

When doing simulations with GNU Radio, one can easily run into problems if asynchronous messages are involved. I already wrote about limitations of the scheduler, which, in essence, cause run to completion flow graphs to run forever.

Another problem is the lack of a back-pressure mechanism for aysnchronous messages. Consider the following flow graph, which I used for WiFi simulations over an AWGN channel. It sends 100 frames at a configurable SNR and logs the received ones in a PCAP file.

The problem is the rate at which frames are injected into the WiFi MAC block. There is no way for the message source to know when previous frames were processed. Therefore, messages might pile-up in the input queue of the MAC block and at some point will get dropped, leading to wrong simulation results.

My current workaround is to use a feedback mechanism as shown in this flow graph.

It exploits the fact that once the message is transformed to stream-domain, back-pressure works and no samples are dropped. (Also with normal flow graphs, samples are dropped by SDR hardware blocks when they cannot put the samples into the flow graph fast enough, but not inside the flow graph.) When the flow graph starts, the block generates one initial message to get the simulations started. After that, it waits until the frame is generated by the PHY layer (i.e. the frame is transformed in stream domain) and feed back into the packet generator. The generator uses the feedback as a notification when to inject the next frame; think of a turbocharger.

Unfortunately, that doesn’t solve all problems, as it only works around the back-pressure problem on transmit side. As you can see, the Wireshark Connector also has a message port input, which might still pile-up messages. While this was no problem in practice, it shows that the solution is not perfect if the flow graph has multiple separate parts that use asynchronous messages.

Another option is setting the maximum message queue size through GNU Radio’s preferences. In theory, it is possible to adjust the size according to the number of frames to be sent and push all messages into the queue. But, of course, that doesn’t really scale and, like the other approach, does not solve the underlying problem.

Not in Love with the GNU Radio Scheduler (Part 1)

While I usually try to avoid digging into the GNU Radio scheduler, there’s one problem that buggs me again and again: run to completion all too often does not run to completion but causes the flow graph to hang forever, waiting for someone to CTRL-C. This is especially annoying with unit tests, simulations, and, generally, with flow graphs that are intended to run without user interaction.

The problem with run to completion flow graphs was also reported in GNU Radio Issue #797. This post is supposed to provide some context and a more verbose description of the pull request I made several weeks ago.

With the introduction of asynchronous messages, the scheduler became much more involved. The current implementation is full of reduntant code, (throttled) busy waiting, goto instructions, and synchronization uglynesses. While it could clearly need some cleanup, the code is at the core of GNU Radio, its highly complex, and it seems like nobody wants to touch it.

System Handler

One issue that came up several time is shutting down of flow graphs. At some point, a system port (or system handler) was introduced to simplify the process. The idea is that each block has a system message port, hidden in GNU Radio Companion, that can be used to signal termination. If a special message is received through the handler, it sets the d_finished variable through:

void
block::system_handler(pmt::pmt_t msg)
{
  //std::cout << "system_handler " << msg << "\n";
  pmt::pmt_t op = pmt::car(msg);
  if(pmt::eqv(op, pmt::mp("done"))){
      d_finished = pmt::to_long(pmt::cdr(msg));
      global_block_registry.notify_blk(alias());
  } else {
      std::cout << "WARNING: bad message op on system port!\n";
      pmt::print(msg);
  }
}
read more

Gulasch Programmier Nacht (GPN) 2016

I spent the last weekend at the Gulasch Programmier Nacht (GPN) in Karlsruhe. Organized by the Chaos Computer Club (CCC), the GPN is an annual meeting of hackers and nerds, who meet to hang around, listen to talks, and eat Gulasch (goulash). I already read a lot about CCC events and finally made it to one. The people, the location, and the organization were really great.

The GPN was hosted by the Zentrum für Kunst und Medientechnologie (ZKM), a high school for arts that has a museum attached. Currently, there’s a great exhibition about surveillance.