Using Arduino and Python to Monitor #TheButton

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.

Decoding Your Keyless Entry Remote with Software-Defined Radio

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.

Keyless Flowgraph

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.

Raw Samples

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.

Energy Detection

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

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

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.

Detection With Threshold

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.

Raw Packet

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')
    raw = cat(1,raw,in_buff);

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.

First 250 Samples of Raw Packet

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

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))

start_ind = x_ind(1);
x_dec = x_dec(start_ind:end);
Data after threshold, zoomed in on the first 250 samples

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;
        if (counter>16)
            bit(bit_ind) = x_dec(ii);

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 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)
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')
if (~pkt_good)

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.

Keyless Demo Display

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.