I’ve been working quite a while on a piece to hang up on my wall that displays – in real time – which spacecraft are communicating with NASA’s Deep Space Network. I finally got the prototype working and am excited to share the build process.

Background

It is amazing that we humans can communicate with our robotic explorers across distances greater than the solar system itself. Voyager 1, now in interstellar space, is so far away that radio signals – traveling at the speed of light – take 22 hours to reach the probe and its responses a further 22 hours to return to us. As part of my job in the space communications field, I sometimes interact with NASA’s Deep Space Network (DSN). Headquartered at NASA’s Jet Propulsion Lab in California with major ground station sites in Spain and Australia, the DSN is responsible for communication with dozens of spacecraft across the solar system and (in the case of the Voyagers) beyond. This year I had the chance to see their impressive operations center.

DSN also operates a very neat website which displays spacecraft that are communicating with each antenna – all in real-time. The display differentiates between carrier versus modulated data for both uplink and downlink.

What if, I thought, the information driving the website could be used to power a physical display to show the status of my favorite spacecraft in real-time? I would use LEDs to light up an image of each spacecraft while it was currently communicating. This could be hung on a wall and constantly run in the background as a neat reminder of our amazing capability to communicate across vast distances.

Hardware

After the adventure of wiring 26 individual LEDs for my Stranger Things Halloween costume I knew I wanted to make things simpler with addressable LEDs. A strip of Adafruit’s NeoPixels were great for this. The strip has only three pins to wire: 5V, ground, and data. The data line connects to the controller chip inside each LED to command brightness and color.

I also decided to try a RasPi-based solution this time instead of using a microcontroller. The hardware timing wasn’t critical (plus Adafruit supplies a great Python library for NeoPixels that is Pi-compatible) and I’d benefit from having a full operating system to retrieve and parse data from the DSN. I went with the RasPi Zero W, a cheap model with a full WiFi stack built in. I also grabbed a GPIO breadboard breakout from Adafruit to help with prototyping.

Rather than antenna-centric as the website, my build would pick several spacecraft and light up their silhouettes when active. After some quick prototyping, I landed on cutting the silhouette out of opaque material and using frosted vinyl (the kind you get to turn normal glass into a privacy window) to diffuse light from the individual LEDs. I found a good ratio was to have three LEDs illuminating a spacecraft image about 2″ wide.

Though the Pi is doing most of the heavy lifting, there are a few housekeeping items to take care of in the circuit:

• I will be powering the strip and Pi with a 5V wall wart, but the Pi GPIO logic level is 3.3V. I’m using a Sparkfun logic level converter in the breadboard to step up the Pi’s 3.3V logic to the 5V which the NeoPixels expect.
• The manufacturer recommends a large (1000μF) capacitor across the power supply and a 300-500Ώ resistor inline with the data pin.

With the circuit working on a breadboard I created a PCB design which includes these components plus some screw terminals to connect the NeoPixel strip and a barrel plug for power. I implemented the same circuit as the Sparkfun logic level converter directly on the board with its component parts (a BSS123 MOSFET and some resistors).

The board is shaped to be the same size as the Pi and connect through the 40-pin GPIO header. These application-specific boards that nest on top of a Pi are commonly called HATs. I sent the build to JLCPCB, who spun five boards for about $6 with shipping.

Building The Frame

For the frame itself I got a shadowbox off Amazon. These are typically used for displaying items but I would use some foamboard to build up individual sections for each spacecraft’s LEDs. I started off by drilling a wide hole in the bottom of the frame to mount a barrel jack for power. A sheet of frosted vinyl was cut to cover the pane of clear glass for light dispersion.

I cut some foam board into strips and notched it to build up a 3×4 grid to hold twelve spacecraft. Having a thick material as a divider was a must so light didn’t bleed over and illuminate adjacent spacecraft boxes.

Unfortunately I had to give up two squares so I could mount the Pi in the frame. If I did this again I’d probably resize the grid to leave a more narrow space to fit the computer. I sunk some standoffs into the thick cardboard backside of the shadowbox. This gave the Pi a very secure mounting.

Now it was time to mount the LEDs on the backing. I didn’t do a great job taking into account the spacing between LEDs when designing the grid. This required some bends and jumper wires to fit exactly three LEDs in each space while still tracing out the grid. The layout is basically the polar opposite of Design for Manufacturing, but it gets the job done. My glue gun was acting up when I went to tack down the LED strips so I went for the nuclear option of JB Weld epoxy. Those strips will be attached to this thing forever.

Finally I needed the silhouettes themselves. I grabbed images from NASA looking for spacecraft that will be flying for a while and had an outline that looked easy to cut out. These were printed on a large sheet of paper at the proper scale. I taped the stencil to a sheet of black posterboard and cut out each spacecraft shape. In the future I’d like to experiment with a CNC for this portion, but an X-Acto knife did the job pretty well. This sheet was layered behind the glass and vinyl. I printed some clear labels to identify each spacecraft.

Software

Step one for the code was to parse data on the DSN website. A super helpful start was Russ Garrett’s GitHub repo which powered the @dsn_status Twitter bot before some API changes broke it a while ago. With only a few changes, I used a version of the module to parse the site’s XML into a nested dict.

Data on the DSN site is organized by antenna. Each antenna has status on its uplink, downlink, and the target spacecraft (in some cases a single antenna can receive signals simultaneously from multiple spacecraft within view). Each time the main loop runs, I iterate through the antennas and find the antennas which are communicating with the 10 spacecraft on the board. From that antenna I pull its uplink/downlink status.

 # Init a dictionary from our spacecraft list to hold parsed status.
 sc_update = dict.fromkeys(hardware.spacecraft, Status.OFF)

for ant in data.keys():
    # Get targets (can be multiple). Filter out 
    # any targets that aren't on the board
    targets_raw = list(data[ant]["targets"].keys())
    targets_low = [x.lower() for x in targets_raw]
    filt_targets = [x for x in targets_low if x in hardware.spacecraft]
        
    for spacecraft in filt_targets:
        status = calc_status(data[ant])
        sc_update[spacecraft] = status

I defined a set of colors for each possible status. The both options are set if both the uplink and downlink are in the same mode (e.g. carrier or data). Each tuple is a red, green, blue (RGB) triplet that defines the intensity of each primary color in the LED. If the spacecraft is not found on the active list, the default status is off. I went for a blue/purple color scheme, but this can be easily reconfigured if I want to switch it up.

class Status(Enum):
    """RGB triplet for each type of spacecraft status."""
    OFF = (0, 0, 0)
    UP_DATA = (0, 235, 145)
    DOWN_DATA = (0, 130, 235)
    BOTH_DATA = (225, 0, 235)
    UP_CARRIER = (0, 0, 235)
    DOWN_CARRIER = (0, 0, 235)
    BOTH_CARRIER = (0, 0, 235)

The final step is to update the LEDs. I defined a hardware mapping dict which specifies which LEDs correspond to each spacecraft silhouette. Using this I can set the LEDs for a spacecraft to the RGB value set by the current status. I wrap this in a helper class, but the NeoPixel library does the heavy lifting to communicate with the LED controller chips.

class Leds:
    """Manipulate LEDs."""
    
    def __init__(self):
        self._pixels = neopixel.NeoPixel(board.D18, 30)

    def set_group(self, pins, status):
        """Set each pin in the list pins to the
        RGB triplet contained in status."""
        for pin in pins:
            self._pixels[pin] = status.value
            logger.debug(f"LED #{pin} to {status.value}")

Finally, a few housekeeping things. Execution of the loop only takes tens of milliseconds so a sleep every loop prevents me from hammering NASA’s website. Contacts are tens of minutes, so this can be a fairly lengthy sleep and not miss much updating. I also don’t need the LEDs on all the time, especially when I’m sleeping. This was the first time I exercised argparse’s ability to accept a custom function as a type argument. Here I’m having it convert a string time window into a pair of datetimes. When the RasPi’s system time is outside this window I turn off the LEDs.

  def main():
    # Set up argument parser
    parser = argparse.ArgumentParser() 

    # Allow operation within a time window.
    default_window = parse_time_window("08:00-22:00")
    parser.add_argument("--window", type=parse_time_window,
    default = default_window,
    help = "Time window to display LEDS in 24 hour HH:MM-HH:MM format.")

def parse_time_window(input_str):
    try:
        start_str, end_str = input_str.split('-')
        start_time = datetime.strptime(start_str, "%H:%M")
        end_time = datetime.strptime(end_str, "%H:%M")
        return start_time, end_time
    except ValueError:
        raise argparse.ArgumentTypeError("Invalid time window format.")

Testing & Mounting

And it looks pretty good mounted on the wall!

This Halloween, I went as the wall from Season 1 of Stranger Things!

Working on a writeup for this project. For now, check out an album of the build on Imgur. Design files (Arduino code and Eagle PCB layout) are available on GitHub.

Many of the blocks in GNU Radio allow the user to select what data type (complex, float, int, byte, etc.) the block operates on. Writing a new block to handle each data type would be tedious, so the framework includes a utility to generate a number of different blocks from template files. I’ve used this to handle different data types in my message utility blocks and some research projects. While useful, I haven’t seen a lot of out-of-tree projects use it so I thought I’d add a step-by-step guide to using the utility for your own out-of-tree blocks.

Background

One may notice that many of the blocks in GNU Radio Companion include an option to configure the data type (complex, float, int, byte, etc.) that the block uses, often with a parameter called “IO Type”:

The Add Const block supports several data types

Looking at the relevant parts in the block’s XML definition file we see that the option is used to call a different block for each data type

blocks.add_const_v$(type.fcn)($const)
...
 <param>
   <name>IO Type</name>
   <key>type</key>
   <type>enum</type>
   <option>
     <name>Complex</name>
     <key>complex</key>
     <opt>const_type:complex_vector</opt>
     <opt>fcn:cc</opt>
   </option>
   <option>
     <name>Float</name>
     <key>float</key>
     <opt>const_type:real_vector</opt>
     <opt>fcn:ff</opt>
   </option>
...

For example, selecting the complex option causes GNU Radio to call blocks.add_const_vcc whereas the float option will call blocks.add_const_vff. So where are those defined?

Though they are separate blocks in the view of GNU Radio, each was generated from a common file. Looking in the gnuradio/gr-blocks/lib directory we see the files add_const_vXX_impl.cc.t and add_const_vXX_impl.h.t which are the template files for each block. There is a similar add_const_vXX.h.t in the gnuradio/gr-blocks/include/gnuradio/blocks directory. Taking a look at the CMakeLists.txt shows the commands to generate the blocks.

include(GrMiscUtils)
GR_EXPAND_X_H(blocks add_const_vXX bb ss ii ff cc)

At compile time, the appropriate files will be generated from the templates and compiled. After that, they can be called from a Python or GNU Radio companion like any other block.

Let’s Build Our Own

There are a few steps to using the utility in your own out-of-tree projects, so let’s go through them step-by-step. Following the steps of the GNU Radio tutorial for writing out-of-tree modules we’ll create a block that performs a simple squaring operation. We’ll go through the process step-by-step, but the end result can be downloaded from GitHub to save some typing.

The new module was created using gr_modtool newmod howtogen. After that, the template files square_XX.h.t, square_XX_impl.cc.t, and square_XX_impl.h.t were added. Let’s take a look at those, beginning with square_XX.h.t:

#ifndef @GUARD_NAME@
#define @GUARD_NAME@
#include <howtogen/api.h>
#include <gnuradio/sync_block.h>

namespace gr {
  namespace howtogen {

    class HOWTOGEN_API @NAME@ : virtual public gr::sync_block
    {
     public:
      typedef boost::shared_ptr<@NAME@> sptr;
      static sptr make();
    };

  } // namespace howtogen
} // namespace gr

#endif /* @GUARD_NAME@ */

When generating files, the utility will replace @NAME@ with the appropriate class name: square_ff for the float case, square_cc for the complex, and so on. Looking in the work function of square_XX_impl.cc.t we see similar variables:

int
@NAME_IMPL@::work(int noutput_items,
          gr_vector_const_void_star &input_items,
          gr_vector_void_star &output_items)
{
    @I_TYPE@ *in = (@I_TYPE@ *) input_items[0];
    @O_TYPE@ *out = (@O_TYPE@ *) output_items[0];
    for(int ii=0;ii<noutput_items;ii++)
    {
      out[ii] = in[ii]*in[ii];
    }
    return noutput_items;
}

The utility will replace @I_TYPE@ and @O_TYPE@ with the correct data types: byte, int, float, etc. @NAME_IMPL@ will be the same as @NAME@ but with _impl at the end, as in square_ff_impl. To summarize, here is a list of the macros when translated for the float case:

An XML file is created that allows the user to call the appropriate block from a user-selectable parameter in GNU Radio. A part of that is shown below:

<make>howtogen.square_$(type.fcn)()</make>
<param>
    <name>IO Type</name>
    <key>type</key>
    <type>enum</type>
    <option>
        <name>Complex</name>
        <key>complex</key>
        <opt>fcn:cc</opt>
    </option>
    ...

That gets all our files in place. What’s left to do is instruct the compiler how to expand and install the generated blocks. We’ll edit include/howtogen/CMakeLists.txt:

include(GrMiscUtils)
GR_EXPAND_X_H(howtogen square_XX             ss ii ff cc bb)

add_custom_target(howtogen_generated_includes DEPENDS
    ${generated_includes}
)

install(FILES
    api.h
    ${generated_includes}
    DESTINATION include/howtogen
)

GrMiscUtils is included in the make file and the GR_EXPAND_X_H macro tells the module name, the header file template name, and then lists what data types to expand with. These files will be generated as ${generated_includes} so we’ll need to tell CMake to install those. Similar instructions are added to lib/CMakeLists.txt:

include(GrPlatform) #define LIB_SUFFIX

include(GrMiscUtils)
GR_EXPAND_X_CC_H_IMPL(howtogen square_XX ss ii ff cc bb)

include_directories(${Boost_INCLUDE_DIR})
link_directories(${Boost_LIBRARY_DIRS})

list(APPEND howtogen_sources
    ${generated_sources}
)

set(howtogen_sources "${howtogen_sources}" PARENT_SCOPE)
if(NOT howtogen_sources)
    MESSAGE(STATUS "No C++ sources... skipping lib/")
    return()
endif(NOT howtogen_sources)

add_library(gnuradio-howtogen SHARED ${howtogen_sources})
add_dependencies(gnuradio-howtogen howtogen_generated_includes howtogen_generated_swigs)
target_link_libraries(gnuradio-howtogen ${Boost_LIBRARIES} ${GNURADIO_ALL_LIBRARIES})
set_target_properties(gnuradio-howtogen PROPERTIES DEFINE_SYMBOL "gnuradio_howtogen_EXPORTS")

We’ll again include GrMiscUtils and use the GR_EXPAND_X_CC_H_IMPL macro to generate the appropriate files. We’ll need to add {$generated_sources}to the sources and finally add howtogen_generated_inlcudes and howtogen_generated_swigs as dependencies using add_depedencies.

The next step is to add the files to howtogen_swig.i. There’s no macro to expand these, so we’ll type in each filename manually.

#define HOWTOGEN_API
%include "gnuradio.i"            // the common stuff
%include "howtogen_swig_doc.i"
%{
#include "howtogen/square_bb.h"
#include "howtogen/square_ss.h"
#include "howtogen/square_ii.h"
#include "howtogen/square_ff.h"
#include "howtogen/square_cc.h"
%}

%include "howtogen/square_bb.h"
%include "howtogen/square_ss.h"
%include "howtogen/square_ii.h"
%include "howtogen/square_ff.h"
%include "howtogen/square_cc.h"

GR_SWIG_BLOCK_MAGIC2(howtogen, square_bb);
GR_SWIG_BLOCK_MAGIC2(howtogen, square_ss);
GR_SWIG_BLOCK_MAGIC2(howtogen, square_ii);
GR_SWIG_BLOCK_MAGIC2(howtogen, square_ff);
GR_SWIG_BLOCK_MAGIC2(howtogen, square_cc);

Lastly, we’ll edit the howtogen_swig.i file to include the following lines:

file(GLOB xml_files "*.xml")

install(FILES
    ${xml_files} DESTINATION share/gnuradio/grc/blocks
)

Now everything should be in place to build. The Git repo contains some unit tests to ensure the square operation performs correctly. There is also a GNU Radio Companion flow graph to test if the XML generation worked correctly.

Like other Reddit users, I have been keeping an eye on the “action” over at r/TheButton during the past month. I write action in quotation marks since the webpage only involves watching a clock count down from 60 seconds to 0.

To summarize the concept, on April 1st (April Fools’ Day) the admins of Reddit created a page featuring a clock counting down from 60 seconds with no indication of what would happen when it reached zero. Next to the clock was a button (The Button) which, when pressed, would reset the counter back to 60 seconds. The catch is each user account (and only those created before April 1st) can only press The Button once.

On April 1st, there were approximately 3.5 million user accounts, which could theoretically keep The Button going for 3.5 million minutes (6 years). Of course, only a fraction of those accounts are active, and as of this post, the counter has not hit 1 second without being reset. There have been several predictions on when The Button will hit zero, and even an extensive collection of statistical data on the button pushes that have happened so far.

Reddit records the time when each user pushes The Button and assigns each user a certain color of flair to display next to their username. A certain number of Reddit users, looking for bragging rights on having the lowest recorded number, are waiting for The Button to almost hit zero before they press. The only downside is this requires constant monitoring of r/TheButton to see when the counter is getting close to zero. Unfortunately, this makes being productive in other things rather difficult, so there have been several solutions to monitor The Button’s status including several users modifying LED lights controlled by Wifi or Bluetooth.

The Bluetooth light project, created by Reddit and Github user ALP_Squid uses the WebSocket client module for Python to get the current value of the countdown timer from r/TheButton. It then updates the color of a Playbulb Candle using Bluetooth. As a result, the light displays the current color of flair you would get if you pressed The Button at that moment.

I loved the idea of this project, but I didn’t have a Playbulb to use. However, I did have an Arduino and a bunch of assorted LEDs from building my Xbox 360 Halloween Costume. I made a simple circuit and Ardunio script to display the current status of The Button with one LED for each color flair.

Each LED was connected through a current limiting resistor to an Arduino GPIO pin staring with 2 for purple and ending with 7 for red. The Arduino script is very simple. A byte of data containing a number (2 through 7) is sent to the Arduino over the serial port. The byte is read, converted into an integer, and the digital pin corresponding to that integer is set HIGH lighting the LED.

To handle communication with the Arduino on the PC side I use the Python library pySerial. I modified the original button script to return an integer value (2 through 7) rather than a hexadecimal color to indicate the current color of the button. The top level python file simply converts that value to a string and passes it to the Ardunio over the serial port. The result is a simple LED bar that changes colors according to the current time allowing you monitor The Button without the need to continuously stare at a screen!

All code is available on GitHub.

In a previous post I talked about the process of using both MATLAB and GNU Radio to process data in real time. I recently used this process to put together a demonstration on how you could use an RTL-SDR to sense and decode the information your Keyless Entry remote sends to your car. This is a pretty popular demonstration of software-defined radio, Adam Laurie and Balint Seeber have put together similar demos.

Eventually I want to get the entire thing working with just GNU Radio but the hybrid approach is working well for now. It also shows how such a hybrid approach might be useful for other software-defined radio applications.

The Background

Keyless remote entry systems have been around for a while and likely aren’t going away any time soon. Your remote can send commands to your car wirelessly using a small radio transmitter to tell your car to unlock, lock, etc.

These remotes vary between auto manufacturers but for the most part they transmit at 315MHz and use On-Off Keying (OOK), a very simple form of digital modulation. OOK sends an RF signal of a certain length to represent a ‘1’ and stays silent to represent a ‘0’.

For security reasons the remote doesn’t send the same signal each time. The remote encrypts its commands using a rolling key so the bits representing each command are different each time. Your car and remote share the same private key which makes it so only your car can decode the encrypted transmission.

This begs the question, what happens when I press a button when I’m out of range of my car? Doesn’t that get the two rolling keys out of sync? Your car actually calculates the rolling key for the next transmission it expects as well as the next 256 transmissions (that number may vary between manufacturers). If any of the 256 match the received signal from your remote, the car will unlock and resynchronize. Of course, if you use your remote more than 256 times while out of range of your car the two will get out of sync. In that case there is usually a procedure in the owner’s manual to get them synced up again.

The Setup

To receive the signal I’ll use an RTL-SDR dongle tuned to 315MHz and running at the default sample rate of 2Msps. In GNU Radio I’ll decimate and lowpass filter the received signal. Since the modulation is OOK, I will just take the magnitude of the received signals.

That data will be written into a FIFO as previously discussed. I will continue the rest of the processing in MATLAB.

Getting The Bits 

In MATLAB I will begin by opening and reading samples from the FIFO. As per the previous post, I’ll make sure that I start the flow graph running before trying to read samples from the FIFO, or MATLAB will lock up.

fi = fopen('data/keyless_mag_fifo','rb');
raw = fread(fi, buffer_len, 'float');

This will give a chunk of floating point samples of length buffer_len (in this case 50,000) containing transmissions and silence. I’ll use a simple energy detection to figure out the start of the frame.

50,000 samples captured from the RTL-SDR, showing two transmissions.

eng_mat = vec2mat(raw,10);
x_mag = abs(eng_mat).^2;
x_sum = sum(x_mag,2);

b = x_sum(2:end);
a = x_sum(1:end-1);

x_diff = b./a;
x_norm = x_diff./max(x_diff);

The stream is broken up into chunks of ten samples. The energy of each chunk is calculated by taking the sum of the magnitude squared. Two vectors containing the calculated energies are created with the vector a lagging one chunk behind the vector b. If I divide b by a the resulting vector x_diff will contain peaks when the transmissions begin.

Result of energy detection run on the 50,000 samples.

x_ind = find(x_norm>threshold);
if (isempty(x_ind))
    x_ind = 1;
end

start_ind = x_ind(1)*window_len;

If I then normalize the vector x_diff so that the tallest peak has a value of 1, I can set a threshold (0.2 in this case) that I’ll consider the start of the peak. If I find a peak I can calculate the sample with which to start the packet.

Normalized energy detection with threshold. I’ll detect the two packets, but process one at a time 

I’ll then count out a number of samples after the start index (in this case 6,000) and save that as the packet. I’ll do a quick check that I have at least 6,000 samples left in the vector raw. If not, I’ll check if there are more samples available in the buffer and grab those. I’ll then remove those samples from the vector raw.

The first packet in raw, containing 6,000 samples

if (start_ind+pkt_len)>length(raw)
    in_buff = fread(fi, buffer_len, 'float');
    if (isempty(in_buff))
        %display('Buffer Empty')
        continue
    end
    raw = cat(1,raw,in_buff);
end

x_pkt = raw(start_ind:start_ind+pkt_len);
raw = raw(start_ind+pkt_len+1:end);

After processing these samples I’ll return to read 6,000 more samples from raw until the vector is empty at which point I’ll grab 50,000 more samples from the buffer and store it in raw.

At this point I can take a closer look at the packet extracted from raw. Looking at the first 250 samples I can see the on-off keying more clearly.

Raw packet, zoomed in on the first 250 samples

I’ll then filter the signal with an integrator to smooth out the plateaus and silences that comprise the OOK signal.

x_filt = filter(ones(1,n)/n,1,x_pkt);

Filtered packet, zoomed in on the first 250 samples

Then I’ll use a threshold to filter the further so each sample is either a one or a zero.

x_dec = x_filt;
x_dec(x_dec>0.3) = 1;
x_dec(x_dec~=1) = 0;

In this case the threshold used is 0.3. I’ll then cut the beginning of the packet so that the first sample is the start of the first plateau.

x_ind = find(x_dec);
if (isempty(x_ind))
    continue;
end

start_ind = x_ind(1);
x_dec = x_dec(start_ind:end);

Data after threshold, zoomed in on the first 250 samples

Next I need to convert the OOK pulses into bits. For this I’ll count the duration of the plateaus and silences.

counter =0;
bit_ind = 1;
for ii=2:length(x_dec)-1
    if (x_dec(ii)~=x_dec(ii-1)) % Transition
        counter = 0;
    else
        counter=counter+1;
        if (counter>16)
            counter=0;
            bit(bit_ind) = x_dec(ii);
            bit_ind=bit_ind+1;
        end
    end
end

After a high-low or low-high transition we’ll start a counter. If the counter reaches a value (16 in this case) without another transition occurring I’ll store the bit.

The first 250 samples yield the first 12 bits of the data

The bits can then be converted to bytes using MATLAB’s bi2de function.

bit_group = vec2mat(bit,8);
byte = bi2de(bit_group)';

Decoding The Signal

The last part is to make sense of all the bytes that are being transmitted. In addition to the encryption mentioned above, the format of the packet is almost entirely different for each car manufacturer. The structure below pertains to my Saturn, but your car may be different.

I found the packet starts off with thirteen bytes of value 85 (alternating ones and zeros in binary) to synchronize the transmission. I start by finding these bytes and keeping everything after them as the payload.

known_sync = 85*ones(1,13);
if (length(byte)<14)
    continue
end
sync = byte(1:13);
payload = byte(14:end);

If the sync is found I flag the packet as good and go on to display the results. If the sync wasn’t correctly found I skip this packet and go back to the start of the loop to grab more data.

pkt_good = false;
if (isequal(sync,known_sync))
    display('Received Pkt')
    pkt_good=true;
end
if (~pkt_good)
    continue
end

Unfortunately due to the encryption this is where the decoding stops. What I have next is a sequence of approximately 20 bytes that correspond to a command transmitted to my car. However, due to the encryption I cannot tell what command is being sent. Instead I just display the sync code and the data along with a message that the signal was received. The data stays around for a few seconds and then fades.

Next Steps

While this project shows a good example of using both MATLAB and GNU Radio, for this particular application it would probably be best to use one or the other. I would like to eventually transition all the signal processing over to GNU Radio. My other option would be to interface directly with the RTL-SDR in MATLAB using the Communication Systems Toolbox to control the RTL-SDR. Processing the data using MATLAB’s object-oriented programming features would also improve the efficiency, but that might just have to be a project for another day.

Until then, the code for this project can be found on GitHub.