Reverse Engineering the Propel ExecuHeli IR Protocol

After seeing all of the Syma 107′s hacked I thought I would try to decode the IR protocol on my Propel ExecuHeli.  Here are my findings.

For accuracy purposes I decided to find the signal on the controller board.  I traced the IR LEDs through a transistor to pin 6 of the micro.

MicroUnfortunately, there are no markings of any kind on the micro.  It looks like it was manufactured without them.

Before digging into the protocol I thought I would have a look at what frequency the data is modulated at for the three different channels.

ModulationTo my surprise, A, B, and C channels were modulated at about 42 kHz.  This immediately raised the question: How do the helicopters not interfere if all of the channels are modulated at the same frequency?  More on this later.

Packet Header

It looks like the header is 4 milliseconds long.

High Bit

A high bit looks to be around 2.3 milliseconds long.

Low Bit

A low bit is 1 millisecond long.


All of the spaces are about 1 millisecond long as well.

Full Packet

A packet consists of a header plus 13 control bits.

Image courtsey of

As far as I can tell the protocol uses pulse length coding.

The “tactic” I read about for decoding protocols like this one consists of making different control changes and comparing it to a “hands off” packet like the one above.  Taking that there are only 13 bits saving all of the waveforms would take too long and it would be overkill.  So, I decided this would be a great opportunity to break out the graph paper.  With this particular controller, it doesn’t send anything until you raise the throttle, however, after you lower the throttle to nothing it sends a few more packets giving me just enough time to hit the stop button on the scope.

The first control change I made was the direction.  It was obvious that bits 9, 10, and 11 were responsible. Here’s what I found:

Bit 9 Bit 10 Bit 11 Outcome
High High Low Right
Low Low Low Left
Low High High Center

Next was the throttle.  Bits 3 – 7 take care of that:

Bit 3 Bit 4 Bit 5 Bit 6 Bit 7 Outcome
Low Low Low Low Low 0%
Low Low Low High Low About 25%
High Low High Low High 50%
High High Low High High About 75%
High High High High High 100%

The only controls left are the two trim buttons and the three position channel switch.  At first I didn’t know if the trim was handled inside the controller or helicopter but it became obvious that it was handled inside the helicopter when I discovered the steering is only three bits:

Bit 12 Bit 13 Outcome
Low Low No Trim Buttons Depressed
Low High Right Trim Button Depressed
High Low Left Trim Button Depressed

For interference purposes I thought the the channels would be at different modulation rates rather than in the packet, but, I was wrong:

Bit 1 Bit 2 Outcome
Low High Channel A
High Low Channel B
Low Low Channel C

The only bit unaccounted for is bit 11.  I still have not figured out what it is, if anything.


Here’s what my notes ended up looking like.

There is still one question that lingers in my mind: How do the helicopters avoid interfering?  At the current state there would be a lot of packet collisions which would lead to the helicopter falling out of air or other strange things.  Well, after reading this I compared how often a packet was sent on the three different channels.  That is how it avoids collisions:

Channel A

On channel A there is a packet sent about every 265 milliseconds.

Channel B

On Channel B there is a packet about every 220 milliseconds.

Channel C

On channel C there is a packet about every 175 milliseconds.

Taking that this is the first time I have done anything like this it is very possible I overlooked something or did something wrong.  If I did please let me know and I will do my best to investigate/fix it.

Logging A Davis Weather Station With Linux

Thanks to Vproweather I am now able to log the data from my weather station with Linux.  This program when executed will retrive the current data from the weather station.  This program will also interrogate as well set time on the envoy which is very nice.  This program is written in such a way so that the output can be directly dumped into a file.  To make it log hourly (probably over kill) I created this shell script which I dropped into /etc/cron.hourly.

dateTime=$(date +%m-%d-%Y_%H:%M)
/home/weather/vproweather --get-realtime /dev/ttyS0 >> /home/weatherData/logs/$dateTime
/home/weather/vproweather -l /dev/ttyS0 >> /home/weatherData/HighsLows/$dateTime
cp /home/weatherData/logs/$dateTime /var/www/weather/logs/
cp /home/weatherData/HighsLows/$dateTime /var/www/weather/HighsLows/
chmod 777 /home/weatherData/logs/$dateTime
chmod 777 /home/weatherData/HighsLows/$dateTime
chmod 777 /var/www/weather/logs/$dateTime
chmod 777 /var/www/weather/HighsLows/$dateTime

Hourly it logs the current conditions and the highs and lows.  I calculated yearly it will cost me about 16 Megabytes, not bad at all.  I want to make a fancy HTML page that will be updated with the current conditions every time the server runs the script.

ShiftBrite on BoArduino


ShiftBrite on Boarduino

I found this library quite useful.  To use it wire:
DI – Digital 10
LI – Digital 11
EI – Digital 12
CI – Digital 13
or configurable by firmware, as well as power and ground.  I had problems with the blue flickering when I tried the fader example.  There would be no difference if you were to use this on an Arduino.