Using MATLAB and SDR to Reverse Engineer 433MHz Messages

Hackers everywhere are having a lot of fun with SDR – as is obvious from the amount of related posts here on Hackaday. And why not, the hardware is cheap and easily available. There are all kinds of software tools you can use to dig in and explore, such as SDR# , Audacity, HDSDR and so on. [illias] has been following SDR projects for a while, which piqued his interest enough for him to start playing with it. He didn’t have any real project in mind so he focused on studying the methodology and the tools available for analyzing 433MHz RF transmission. He describes the process of using MATLAB to recover the transmissions being received by the SDR

He started off by studying the existing tools available to uncover the details of the protocol. The test rig uses an Arduino UNO with the rc-switch library to transmit via a common and inexpensive 433MHz module. SDR# is used to record the transmissions and Audacity allows [illias] to visualize the resulting .wav files. But the really interesting part is where he documents the signal analysis using MATLAB.

He used the RTL-SDR package in conjunction with the Communications System Toolbox to perform spectrum analysis, noise filtering and envelope extraction. MATLAB may not be the easiest to work with, nor the cheapest, but its powerful features and the fact that it can easily read data coming from the SDR makes it an interesting tool. For the full skinny on what this SDR thing is all about, check out Why you should care about Software Defined Radio.

27 thoughts on “Using MATLAB and SDR to Reverse Engineer 433MHz Messages

    1. Octave even has a MatLAB lib to make the code almost the same.
      Use can even script it:
      #!/usr/bin/octave -q
      printf(“\nswoon… <3 we don't want to pay $12k per cluster node for FATlab");

  1. There is a slight development on the RTL-SDR which you can buy in kit-form or pre-assembled:
    http://www.aliexpress.com/item/DIY-KIT-100-KHZ-to-1-7-GHz-all-band-radio-RTL-SDR-receiver-RTL2832-R820T/32272386214.html
    (There’s a comment that no manual is supplied. For me the seller sent a link per AliExpress’ internal messaging system with assembly instructions. It has not yet arrived in the mail for me but I’ll surely post something of a verdict the next time SDR is mentioned on HaD.)

    The RTL2838 only uses one half of its I/Q input, so this hack involves soldering a bit of wire to the unused port. This way you get all the ham bands without an up-converter. Since these are sub-VHF frequencies going over the bodged wire there are in fact not great difficulties to overcome with this approach.

    There are by the way good reason to use GNU Radio for this kind of thing. It behaves very much like a visual programming language so it can be used to both learn about DSP and rapidly develop new things. Gnuradio uses FFTW, so the performance is pretty much guaranteed to be top-notch outside of hardware accelerators.

  2. He did some cool work, but if the protocol was the target, then why not tap the base band before it modulates the transmitter.

    Speaking of SDR with TV tuners…. is there a transmitter equivalent of the TV tuner?

    1. If you mean comparable in frequency ranges and such, HackRF and BladeRF are pretty much it.

      If by “equivalent” you mean a dirt-cheap, mass-market device for another purpose which happens to be repurposable as a generic SDR with a little hacking, then I suppose a video card would count: AM, FM, or even DVB-T/NTSC/PAL.

      (I wrote a long-winded ramble about VGA-based SDR, but realised I was drifting pretty far from a simple answer to your simple question, so I’m breaking it out into a reply to this post….)

      1. I’ve actually given considerable thought, and a little experimentation, to the idea of using a VGA output for SDR. You get decent bandwidth (0 to pixelclock/2), which easily covers everything from DC to 6m (for cards that can drive 1920×1080@60Hz) or even 2m (for cards that can drive 2560×1600@60Hz) directly. For VHF/UHF and beyond, of course, you can use an upconverter — and the ridiculous bandwidth means you can completely cover 2m+1.25m, 70cm, 33cm, and 23cm, each with a single, fixed-offset upconverter. You may or may not be able to cover 2.3-2.31GHz and 2.39-2.45GHz with a single upconverter (you’d need a good video card and good filtering), and all bands above 13cm are definitely too wide.

        Anyway, the bandwidth’s great, the resolution’s not bad (only 8 bits, but you can combine two channels for more dynamic range, either by attenuating and summing e.g. R+B/256, or simply multiply e.g. R*B), but the one big problem, as I see it, is the blanking. IIRC, when I did some experiments, I was able to get several video cards to run with 1 pixel of horizontal blanking and 1 line of vertical blanking, which is very good compared to real video timings, but not good enough to completely ignore.

        One obvious solution is to pick timings such that these correspond to nulls in the signal — for instance, I was contemplating hellschreiber modes, and for ordinary feld-hell, the rule is 17.5 columns per second; thus one selects timings to generate 17.5 frames per second, and the vertical blanking lies within the feld-hell intercolumn blanking. (This also means we can use more lines of vertical blanking, if needed…) For the horizontal blanking, we can line it up with zero-crossings of the carrier, so we need only make the carrier frequency an integer (or even semi-integer) multiple of the horizontal frequency. Since the vertical timing requirement is generally stated to be +/- 0.1%, a good strategy is to first select a dot-clock and horizontal resolution to generate a horizontal frequency that is (1) a factor of the desired carrier and (2) greater than 17.5kHz, then choose the nearest vertical resolution (since we have at least 1000 lines, we’ll be no worse than +/-0.05%).

        But there’s still a slight problem — VGA outputs range from 0 to 700mV, and blanking forces it to 0; we could generate an offset waveform centered about 350mV, but then the blanking becomes a glitch to -1 instead of 0! Every solution I could come up with either poses unreasonable requirements on the signal to be transmitted, or requires external hardware.

        The solution I was pursuing at the time is to use 2 of VGA’s 3 channels as a differential output, giving us effectively 9 bits and 1.4V peak-to-peak, and blanking is now properly centered. (Of course the third channel may be attenuated and summed on either side of the differential output, to expand dynamic range.) This should work great if you can arrange your horizontal blanking to coincide with zero-crossings, which is straightforward for OOK or AM modes, and even some wierder things like MT-Hell, but it’s not clear to me that such an arrangement is even possible for FM/FSK/PSK or SSB modes, much less how to do it.

        The other attractive option is to rig up a sample-and-hold circuit gated off the Hsync signal, so that the analog output remains unchanged during blanking — while this removes the requirement that blanking to coincide with zero-crossings, it does halve available bandwidth for a given pixel clock (from pixelclock/2 to pixelclock/4). Or better yet, but also more complicated, to sample and hold a separate channel, and substitute that channel during blanking — so the last pixel in each row might hold the current value in R, and the value to be output during blanking in G. (Extending this, one could replace the sample-and-hold with a delay line, and cover arbitrary blanking, if there was some reason not to reduce blanking to 1px.)

        1. I though about it lately too just after reading about Raspee VGA666 module and new firmware enabling (hidden to that point, yay for broadcom closed source secret juices …) parallel video interface (raw RGB + H/V). So far there is no way to control timings of this interface, there is special parameters for custom HDMI timings
          http://www.raspberrypi.org/forums/viewtopic.php?f=29&t=24679

          hdmi_timings= <h_sync_polarity

          , but there is a chance that:
          1 Rpee foundation adds custom timing to this interface too, LadyAda from adafruit was very interested in it, maybe to sell cheap LVDS LCD screens for pee, (just need cheap serializer chip to mate ordinary laptop lcd with this interface)
          2 Broadcom video rasterizer can be coerced into zero blanking

  3. So he has the analytic signal (I&Q), then he throws away the quadrature part, only to re-create it with a Hilbert Transform to get the envelope.

    He’s downconverted to DC already, so why not just get the “modulus” directly from I&Q via Pythagoras? Seems like extra work to me.

  4. Most communications is narrow band. Say 25 kHz. That is plenty for voice and pager signals. Having the signal digitized at baseband is the first step. The using any of your favorite software tools, you can determine the modulation scheme and decode the bits (1’s and 0’s). Once you have the physical layer decoded (i.e. have the 1010100 streams). you can then 1)
    sync up the markers, and 2) decode the bits into symbols (make human readable).
    I think they have FSK decoders already in software. Just a matter of using the right digital filter.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s