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.

9 thoughts on “Reverse Engineering the Propel ExecuHeli IR Protocol

  1. Pingback: Communication protocol for an indoor helicopter

  2. Pingback: Communication protocol for an indoor helicopter | Cool Internet Projects

  3. Jim

    Hey man – this is a really cool write-up, congratulations on your first reverse-engineering hack! I’m glad my write up was helpful to you, it was my first reverse-engineering project too.

    What you found about how the channels work is fascinating – I wonder just how clumsy the heli’s get when all 3 channels are in use. I’m sure there’s some math you could do to figure out how frequently there will be a collision, but that’s a bit beyond me.

    It’s also super interesting to me that the Syma choppers seem to have much longer control packets (24 or 32 bits, which I guess translates to more precision in their control?) – using just 13 bits seems pretty efficient for a 3-channel RC heli, especially given some of the trick videos I’ve seen of this model on Youtube.

    Take care,


  4. Pingback: Reverse Engineering the Propel ExecuHeli IR Protocol « adafruit industries blog

  5. h

    Just got one of these for Christmas. Absolutely blown away with the amount of tech you can get for £20 these days – looking forward to hacking the thing, thanks for the excellent analysis :)

    (I do have a horrible feeling this may lead to bigger helicopters. Even this tiny one’s pretty addictive)

  6. Mehdi

    I found your post on Hackaday and it is exactly what I’m trying to do. But for now, it seems to be more complicated.
    I’m working on arduino with the IRemote library to get IR trames, but everything seems to be mixed. I mean, when I move only one axis, there is no only 1 byte which is changing as follow:

    Do you think I shouldn’t not use the IRemote library because it could (maybe) filter over standard ir protocol frequencies (38kHz)?
    I tried to exploit these data with weka but i couldn’t get any useful information…
    Do you have any advice which could help me?




Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>