New GRC Block for Reversing Simple Protocols

Hello SDR fans. A long-standing wish of mine is to have a grc block that detects a preamble on an incoming byte stream and tags it with a fixed length. There has been a block in grc for a long time called the Correlate Access Code – Tag Stream (kind of a mouthful, I know) which almost does this but not quite. This original block scans the 32 samples after the preamble and tries to extract a frame length field, which it will then use for the tag value. That function is kind of neat if you’re building your own transmitter/receiver pair, but it doesn’t help when you’ve got a mystery signal on your hands that won’t have that header in place.

So for a while a worked around the issue. On short projects, I’d use the now-deprecated Correlate Access Code block, dump the data to a file and whip up a quick Python script to handle things (you can see some examples of this in Volume 3 of our book series). For more complex situations, I employ WaveConverter,  which I built to extract and analyze large amount of payload data. Despite these options, I always wanted a simple grc-only method of quickly looking at payload data.

All of which brings me to the block I built, Correlate Access Code – Tagged Stream – Fixed Length (yeah, I didn’t really reduce the mouthful any). I simply created a new module and block with the gr_modtool utility and copied over the *.cc, *.h and *.xml files from the original block. I then cut out the header parsing and added a property for you to set the Packet Length. After a bit of debug and cleanup, I had a useable block, which you can grab from:

The example flowgraph below shows how easy it is to use:

The new block allows you to detect the preamble and tag it such that the subsequent Tagged Stream to PDU block can convert the payload (and only the payload) to a Message PDU, which you can then print out with a Message Debug sink. The PDUs simply appear in the console window as you run your flowgraph.(I’m using the print input of the Message Debug block because I have ASCII data, but if you have binary data, you should use the print_pdu input instead.)

Note that you can also dump the message PDUs to a File Sink, which gives you a nice file containing only payload data, none of the preamble or inter-frame dead air. A couple lines of Python can read this file and extract each payload into a list, from which you can do all sorts of fun stuff.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.