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.
I’ll be on the Black Hills InfoSec webcast tomorrow talking about all the things you need to know to get started with SDR. You can register for the webcast at the link below:
Please bring your questions on SDR hardware, software, installation issues or anything else you can think of. See you there!
The LimeSDR Mini is a great combination of things: affordable, full-duplex and incredibly configurable. Until recently, though, it wasn’t the easiest thing to get running. Scanning the forums at MyriadRF (the folks who make the Lime products) shows that a number of people have been able to get the Mini working but also that a number have not had so much success.
I was a pre-production supporter of the CrowdSupply campaign and had my LimeSDR Mini delivered in March. At first it was rough going, but after numerous attempts, I’ve been able to get a repeatable installation flow that works on Ubuntu 16.04 and supports UHD and HackRF hardware as well (it may support BladeRF, but I don’t have the hardware to test it).
You can grab the install script from my GitHub at:
The git bundle also contains a number of simple grc files to validate your installation versus each of the three hardware platforms. After installation, my advice is that you test things with:
(make sure to tune to one of your local stations)
Next, if you’ve got a second SDR (and computer) you can use the GFSK transmit and receive flowgraphs to send simple digital data back and forth between them. You should be able to send and receive from any combination of the three SDR platforms, though you will likely need to adjust the squelch levels depending on the physical distance between your SDRs. If a HackRF is involved, you’ll also need to fine tune the receiver flowgraph to compensate for their frequency error.
One thing to note about this install flow: you get version 3.7.10 of gnuradio-companion, not the latest as you’d get with a PyBOMBS installation.
Hope this helps!
Addendum: This flow will work for Ubuntu 18.04, but you’ll need to go into the install script and tweak one line per the commented instructions. You’ll also need to adjust the device args for the hackrf transmit flowgraphs to “driver=hackrf,soapy=0” (but do NOT type a space between the comma and “soapy”). A bonus to using 18.04 is that you’ll get a slightly newer version of gnuradio companion (3.7.11).