Download & Requirements

Get the SymaLib library (v0.1) here. The library was written for the Arduino IDE v1.1 and is designed for use with a sketch similar to Adafruit’s IR Commander sketch (reference, github).

Details

I started with the excellent Adafruit Industries IR Commander sketch as it is easy to understand and takes care of populating an array with the on/off pulse lengths for me. With this raw material, all the SymaLib library has to take care of is parse the received pulse lengths into their respective bit-wise values and provide a series of methods to get the parsed values of the handset’s controls.

Version 0.1 currently allows you to parse the 32-bit control packets from the S107T2 controller (described in my protocol spec: here) and return each control value as an integer.

Example

/*
SymaLib Library Example v0.1 by Jim Hung (www.jimhung.com)

 This example code is designed to demonstrate the usage of the SymaLib
 to decode control signals from a S107T2 RC helicopter controller.

 Based on 'Raw IR commander' by Ladyada:

   "This sketch/program uses the Arduno and a PNA4602 to
   decode IR received.  It then attempts to match it to a previously
   recorded IR signal

   Code is public domain, check out www.ladyada.net and adafruit.com
   for more tutorials!"
*/

#include  // include the SymaLib library

#define IRpin_PIN      PIND
#define IRpin          2

#define MAXPULSE 2000
#define NUMPULSES 50

#define RESOLUTION 20
#define FUZZINESS 30

uint16_t pulses[NUMPULSES][2];  // pair is high and low pulse
uint8_t currentpulse = 0; // index for pulses we're storing

SymaLib protocolparser; // declare our SymaLib object

void setup(void) {

  Serial.begin(9600);
  Serial.println("Ready to decode IR!");
}

void loop(void) {

  int numberpulses;
  String ctrldata = "";

  // Listen for IR signals and populate the array of pulse lengths

  numberpulses = listenForIR();

  // Give the SymaLib object the pulse array to parse. If it's a valid Syma107
  // control packet, SymaLib returns boolean True.

  boolean result = protocolparser.setPulseListParse(pulses,numberpulses,RESOLUTION,FUZZINESS);

  if (result) {

	// Read the controller values and do whatever you need to with them.

	  // This example prints out the integer values for each control:

    Serial.print(" Yaw: ");
    Serial.print(protocolparser.getYawDec());
    Serial.print("\tPitch: ");
    Serial.print(protocolparser.getPitchDec());
    Serial.print("\tChannel: ");
    Serial.print(protocolparser.getChanDec());
    Serial.print("\tThrottle: ");
    Serial.print(protocolparser.getThrottleDec());
    Serial.print("\tTrim: ");
    Serial.print(protocolparser.getTrimDec());
    Serial.print("\n");

	  // This example prints out the binary values for the 32-bit control packet:

    Serial.println(protocolparser.getCtrlPacketBin());

  }
  delay(100);
}

int listenForIR(void) {
  currentpulse = 0;

  while (1) {
    uint16_t highpulse, lowpulse;
    highpulse = lowpulse = 0;

    while (IRpin_PIN & _BV(IRpin)) {

       highpulse++;
       delayMicroseconds(RESOLUTION);

       if (((highpulse >= MAXPULSE) && (currentpulse != 0))|| currentpulse == NUMPULSES) {
         return currentpulse;
       }
    }

    pulses[currentpulse][0] = highpulse;

    while (! (IRpin_PIN & _BV(IRpin))) {

       lowpulse++;
       delayMicroseconds(RESOLUTION);

        if (((lowpulse >= MAXPULSE)  && (currentpulse != 0))|| currentpulse == NUMPULSES) {
         return currentpulse;
       }
    }
    pulses[currentpulse][1] = lowpulse;

    currentpulse++;
  }
}

Library Reference

Here are the methods provided by the SymaLib library:

SymaLib()

Constructor. No arguments — initializes control byte array.

setPulseListParse()

Returns: Boolean

Arguments:

uint16_t pulses[][2] — The pulse array populated by the ‘listenForIR’-like method.

int& numpulses — The number of pulses heard by the ‘listenForIR’-like method.

int resolution — The RESOLUTION constant used to calibrate the IR listener.

int fuzziness — The FUZZINESS constant used to calibrate the IR listener.

Description:

This method parses the pulse-array and stores it as an array of integers, either 1 or 0. This array is the basis of the object’s Get methods.

getYawDec()

Returns: Int

Arguments: None.

Description:

Returns an integer of the decimal value of the Yaw control.

getPitchDec()

Returns: Int

Arguments: None.

Description:

Returns an integer of the decimal value of the Pitch control.

getChanDec()

Returns: Int

Arguments: None.

Description:

Returns an integer of the decimal value of the channel switch.

getThrottleDec()

Returns: Int

Arguments: None.

Description:

Returns an integer of the decimal value of the Throttle control.

getTrimDec()

Returns: Int

Arguments: None.

Description:

Returns an integer of the decimal value of the Trim control.

getCtrlPacketBin()

Returns: String

Arguments: None.

Description:

Returns a String of ‘1’ and ‘0’s representing the 32-bit control packet. Useful for debugging.

Conclusion

This is the first Arduino library I’ve ever written (hopefully not the last!) and I hope it is useful for other hackers. [Maksim]‘s idea was cool and I’d love to see any projects that end up using it. Let me know in the comments!

Take care,

Jim

** 1-26-2013 UPDATE — I’ve written up a full protocol specification for the Syma 107G — If you are here looking for a purely technical description of the protocol, look here** 

I first discovered a series of articles about this RC Heli on Hackaday, where a number of people had developed proof-of-concept controllers or jammers based on a decoded IR protocol for controlling the chopper. As it happened, these Heli’s were a bit of a fad in our lab and we had a number of them lying around (both alive and dead) so naturally I decided to have a go myself. I initially created a prototype Arduino IR controller that uses Processing to provide a front-end for one helicopter, then expanded it to control two similtaneously by switching the channel bits rapidly. I won’t go on too much about this here because what I actually want to talk about is a quirk in the protocol I decoded.

So there’s a decent body of work in the hacker and RC communities to decode the protocol used by the Syma 107 — here are a couple:

This post [Kerry Wong] is a really great read and a study in methodical analysis in reverse engineering.

This site [Hamsterworks] is also a great practical guide to reverse engineering the protocol and I actually used these timings for my own controller a while back.

One thing these projects both have in common is that they arrived at a protocol specification that uses 32-bits (4 bytes).

Reverse-Engineering the controller

So enter my new Saleae Logic Analyser . I’ve never used a logic analyser or oscilloscope before, so I wanted to start with a project that I knew was possible and would have an output that I already understood (or so I thought…).

As an aside, the Saleae Logic is really an excellent tool — I had read a lot about it and there are any number of superlatives floating around, but I must say it is EXACTLY what I was looking for. Great price-point, loads of features and the software is superb. If you are curious about logic analysers and don’t want to spend too much, I really recommend the Logic — it’s been great for me so far.

I noticed immediately that the board in my controller was markedly different than the ones pictured on either the above links. Mine has way more components for a start:

I began by using a multimeter to ensure that the unlabelled IC wasn’t operating at a voltage higher than 5v and wouldn’t accidentally damage the Logic analyser. Everything was fine so I began probing the pins. Here is a rough guess at the pinout (note: I only really care about the pin that drives the IR LED transmitter circuit so I never looked into confirming how the control input works, etc…):

Now that I know which pin the transmission signal is output on (pin 8), I can sniff it and see the 32-bit control protocol right? Well, almost. I should explain a little about the protocol for those who are unfamiliar.

Decoding the Physical Packet format

The following timings are based on observations I’ve made on a sample of control packets captured with the logic analyser. Here’s a picture of the full packet:

Carrier Modulation

Modulation Freq: 38khz (50% duty cycle, 26us period, so 13us high/13us low)

38khz is a common carrier frequency for consumer Infrared communications. For the uninitiated, the white blocks in the main image above are made up of the high-frequency oscillations you can see on the left. This is usually done so that various transmitters that use the same medium (in this case the Infrared light spectrum — probably around the 940nm wavelength) can transmit on a different carrier modulation frequency and not interfere with the others’ transmissions (this is called Frequency Division Multiplexing).

Symbols

There are 4 types of symbol in the packet format: Preamble, Zero (“0”), One (“1”), and a footer:

Preamble:

High: 2ms (2000us) / Low: 2ms (2000us) / Period: 4ms (2000us)

Zero:

High: 0.3ms (300us) / Low: 0.3 (300us) / Period: 0.6ms (600us)

One:

High: 0.3ms (300us) / Low: 0.7ms (700ms) / Period: 1ms (1000us)

Footer:

High: 0.3ms (300us)

I almost missed this, but there is in fact a footer pulse at the end of the packet 300 microseconds long followed by a long period of low signal until the next packet header.

Channels

The Syma 107G controller appears to support 2 “channels” so that two pilots can fly their heli’s at the same time without interfering with each other. Examining the behaviour of the transmitter when switching channels indicated that the only differences between the two is a) the packet transmission interval and b) a special bit in the control packet is flipped (more on this later). The image below shows the differences in packet Tx intervals when the channel select slider is flipped (channel 1 of the Logic analyser):

The transmit interval for Channel A is 120ms (start of a packet header to the start of the next packet), or 8.33 packets per second. The transmit interval for Channel B is 180ms, or 5.55 packets per second.

So surprisingly, the carrier modulation frequency remains the same on both channels — not the most robust design, huh? I suspect the reason the transmit interval is increased is to reduce the likelihood of a collision of control packets from two controllers — if a packet collision does occur, the next control frames from each controller will almost definitely be out of phase with each other, so the chopper shouldn’t just fall out of the air (though in my experience, they do get a bit clumsy when you have two going at once…).

The Control Packet Structure

So now that we understand what a packet looks like, let’s decode one and have a look at it at a higher level:

(Click for a better look)

 And here it is again:

         |     byte 0    |     byte 1    |     byte 2    |
          0 0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 0 1 0 1 0 0 1 0
         |  Decimal: 63  |  Decimal: 63  |  Decimal: 82  |

So we have a header, followed by 3 bytes (24 bits) of information, plus a footer pulse that makes up a control packet. Now lets figure out what the data means by trying various permutations of the controls (zero throttle, full throttle, 100% left turn, 100% right turn, etc…) and see how the data changes:

Type:         Data:                     Decimal Values (byte #):
100% Throttle 001111110011111101111111  (0): 63  (1): 63  (2): 127
50% Throttle  001111110011111100111111  (0): 63  (1): 63  (2): 63
100% Left     011111100011111101000110  (0): 126 (1): 63  (2): 70
100% Right    000001100011111101001011  (0): 6   (1): 63  (2): 75
100% Forward  001111110000000001010100  (0): 63  (1): 0   (2): 84
100% Back     001111110111011101010100  (0): 63  (1): 119 (2): 84
Channel A     001111110011111101010010  (0): 63  (1): 63  (2): 82
Channel B     001111110011111111010010  (0): 63  (1): 63  (2): 210

Note: The controller requires that there be at least some throttle applied before it will send any packets, which is why byte 2 appears to change a little on the other tests.

From this information, we can make the following assumptions:

Byte 0

Byte 1

Byte 2

The Mystery of the Missing Byte

You may remember that I said above that everyone else who has reverse-engineered the protocol arrived at a 4-byte control packet. So where was my 4th byte? Well there’s one more dial on the controller we haven’t discussed — Trim. Trim is used to calibrate the rotor speed balance in order to account for any idiosyncrasies in the helicopter’s build that cause it to have a rotational bias to left or right.

In the other’s work, their controller sent a fourth byte containing information about the Trim dial’s setting. My controller doesn’t have that byte, but I do have Trim control… so what’s the deal? Let’s do a bit more testing:

Type:         Data:                     Decimal Values (byte #):
Trim 100% L   010100000011111101010100  (0): 80  (1): 63  (2): 84
Trim Centre   001111110011111101010100  (0): 63  (1): 63  (2): 84
Trim 100% R   001011100011111101010100  (0): 46  (1): 63  (2): 84

We can see that the only byte that changes is Byte 0, so we can assume that rather than have a whole separate packet for trim control, the controller simply offsets the Yaw by a as much as –17 (right/clockwise compensation) or +17 (left/counter-clockwise compensation).

From a reverse engineering point of view, this is an interesting quirk. I have tried and tested both kinds of remote with the same helicopters and they both work flawlessly. What’s more, before I decoded the protocol myself, I built a whole controller based on the 4-byte protocol and never had any issues. So how does the helicopter know which protocol to use?

I think it might have something to do with the footer. The 3-byte protocol doesn’t require the helicopter to do anything in order to account for trim, while the 4-byte protocol requires the chopper’s on-board controller to offset the Yaw by the Trim value. The footer appears to consist a 300us high pulse then nothing until the next header, and this appears to be the case even on the other chaps’ 4-byte packets too. I suspect that if the helicopter’s on-board controller detects the end of a packet and it has only received 3-bytes of data, it pads the trim register with zeroes (no supplied trim offset) because it can assume trim control has been applied by the handset controller. Just a guess, but it seems logical. In any case, who would have thought the helicopter would be backwards/forwards compatible?

Conclusion

So there you have it — my first foray into hardware hacking and exploration. I think I’ve arrived at a definitive physical protocol definition, with timing values even better, perhaps, than the other projects I’ve mentioned throughout.  I put this down to the use of a logic analyser applied directly to the controller — this was unaffected by delays caused by the rise/fall times of the LEDs, IR detector, etc… that were part of the receiver circuits used by Kerry Wong and Hamsterworks to get around the issue of demodulating the 38khz IR signal. I was able to use Saleae’s excellent software to overcome those issues (albeit a little manually — it won’t demodulate the signal for you to my knowledge). The Saleae Logic also allowed me to sample at 16Mhz, certainly fast enough to get a high-resolution picture of the signals and really get some tight timing values for the transitions.

I hope this helps some new hacker get to grips with some of the ideas at play in reverse-engineering and hardware hacking, it’s certainly been a journey of discovery for me. If anyone has any questions, feel free to get in touch at jimhung [at] gmail [dot] com.

On to the next project!

Jim

 ** UPDATE — 12-8-2012 **

I’ve had a little time this weekend to compare a 4-byte controller with 3-byte controller, so here are my findings.

• The timings for the symbols and transmission intervals are identical between the two controllers, so my timings should work equally well on any revision of the 107G you end up getting.
• One way to distinguish between which protocol version the controller is using may be the silkscreened model number and date on the controller PCB. The 3-byte controller had the model “S107T1” and the date “20090818” printed underneath the yaw/pitch and throttle control, respectively. The 4-byte controller had “s107T2” and “20100308” printed under the yaw/pitch control and on the right of the PCB.
• The fourth byte indeed  communicates the value of the Trim, but I actually identified something really interesting — the offsetting of the Yaw value occurs anyway, regardless of packet type! Take a look at this:

Control:         Control packet (4 byte)           Yaw:    Trim:
Trim 100% Left:  01010000001111111011010001111011   80      123
Trim Centre:     00111101001111111100100100111000   61      56
Trim 100% Right: 00101101001111111100111100000001   45      1

I suspect that the 107G doesn’t actually do anything with the Trim packet (perhaps I’ll test that with my DIY controller sometime soon), which explains how it’s able to handle both packet types — it simply ignores anything after the 3rd byte. I suspect that the 4th byte may be used by other toys using a similar design.

This is what was waiting for me when I got back from China (click to enlarge!):

I’m so impressed by the effort that’s gone into the drawings! It makes me wonder if you could illustrate an entire kids book by asking random on-line stores to draw the scene on packaging..

Thanks again A Whiter Shade Of Pale!

How awesome is that! Thanks to Awhitershadeofpale for taking the time and effort to draw this for me!

Jim

..Although having said that, the place was completely overtaken by the Derby — the hill was provided by South Grand Ave all the way from the Wells Fargo building, round the corner to West 5th to Pershings Square.

The costumes and cars were great, and the crashes even greater (how the Lady Gaga and Jurassic Park drivers didn’t die, I have no idea).

A good day in all, and was very impressed with the Canon 7D — more on that later!

Peace.

A vintage typewriter.

I feel like emails, facebook, IM’s, etc… are a bit boring and disposable; you never really need to put any amount of effort and thought into what you write. Letters are much more interesting and have a greater impact, simply by the virtue of being tangible and the product of some work, skill, thought and heart. The perfect solution: A Royal KVM Magic Margin desk typewriter.

Actually using the typewriter is a lot of fun — you will very quickly appreciate how much of Microsoft Word you take for granted (Margins, tabulation, auto-new line, etc…). Even the act of typing is a learning curve — you need to use the appropriate amount of pressure (too hard and the head with skip and leave ghost letters on the page, too light and the carriage might not advance causing you to over-type the next character). You’d think typing an exclamation mark would be straight forward, right? Wrong. You have to type an apostrophe, then backspace, then a full-stop. Make a typo? Unlucky — you better start from scratch. It sounds like a recipe for misery, but unless you are a bit of an idiot, the challenge is half the fun.

A Ukulele.

In the interests of keeping my moving hassle light, I didn’t ship anything over from the UK when I moved — including my guitar. At first, I didn’t appreciate how much I’d miss it, but when one of our directors brought his Baby Taylor in (which, thinking about it, I could have brought my own B.T as carry-on..), I realised that the simple joy of playing an instrument was missing from my life.

I couldn’t make my mind up whether to splash out big bucks on a new acoustic guitar (probably something in the $2000 dollar range) or try a new instrument out, like a Uke or Mandolin (around the $200 mark). I decided to go for the Uke as it looked like it would be easy to get the hang of and a bit more flexible than a Mandolin. I got a Lanikai CK-C (Curly Koa — Concert size).

Googling good resources for learning to play the thing threw up a great site with what might be the greatest name of all time: here.

-

That’s about it. Tune in next time when the fun buy will be an automobile…

To give a little background, the first time I met Mehreen, we hit it off by somehow getting on to the topic of Garth Merenghi’s Darkplace (long-time readers will know this is my favourite show of all time). From the earliest days of our relationship, we said we would one day have to make Egg in Soup (from the 6th episode, Hell Hath Fury).

So we did.

Note: anyone puzzled, frightened or annoyed about the concept of an Egg in Soup, please see:

So we set out to test this most genius of ideas here in Los Angeles. This was to provide it’s own set of challenges, as there was no chance we were going to get our hands on a Pork Pie or Sausage Roll. Thus, we set out to make our own sausage roll — a lofty mission which was almost scuppered until Trader Joe’s came through for us with puff pastry at the 11th hour:

Mehreen took to the job of making the sausage roll with consummate professionalism:

The choice of soup was a complex one. In the show, the soup pictured is clearly cream of tomato, which gave us the basis for our selection, however the staple Tomato soup — Heinz — was a) difficult to get hold of in L.A. and b) too thick to necessarily poach an egg in or reach the required temperature (without spoiling). We decided that Cambells Condensed Tomato soup would suit us nicely — thin enough (when you add the water) to boil nicely for the poaching:

Not that you can tell, but we actually put a swirl in the soup to try and keep the egg together. As Ben will attest, my poached-egg game is not strong, so getting a decent result from tomato soup was a particularly great win.

The end result was pretty great if I say so myself (it wasn’t as greasy, or as plain disgusting as it might first appear — honestly, it was pretty nice!):

Hope this didn’t weird you out too much,

Jim

P.S. To compliment my Hendersons Relish, I picked up some Lea and Perrins Worcestershire Sauce. What I wasn’t prepared for was the unbelievably over the top packaging for it over here:

 I rather enjoyed the sea air and that.

Almost makes up for the fact that americans don’t get a 4 day weekend for easter :’(

I stopped by the Apple store on the 3rd St Promenade to have a peek at the iPad which went on sale today. The chap in the shop said that they had a queue all the way down the road before the shop opened. I can believe it, the crowd around the iPad tables were ridiculous. In short, to me the iPad was typically Apple-like; slick, good looking, full of little ‘wow, neat’ moments, with just a hint of style over substance. The iBook app was pretty cool, the presentation is very nice and it looks like it could be a real contender for more traditional e-ink readers like the Kindle. I don’t know if I’d consider getting one when they are released in the UK, though.

The trusty Polaroid SE 670 AF has had a workout this trip.

I’m looking forward to trying out my new Olympus OM-10 when I get back.

Lots of other things need posting about, but I’m sure you know that already.

Jim.

I’m off to work for a month in L.A, in just under an hour and a half. I bet I’ve forgotten to pack something important. Like my passport.

I’ll post properly when I’ve got a moment and some photos or something to share, right now I’m struggling enough to stay awake as it is.

Work has been pretty exhausting lately, lots of on-sites and late nights. The overtime is nice though, hopefully it’ll pay off come the summer when we’re planning to visit Reykjavic and NYC, go camping and spend some time doing some proper photo stuff.

I passed my driving test back in January so I’m hoping to get a car and start racking up some road trips, get some use out of my cameras and that. First on the list is the video for Tom V’s latest song Mendocino Sky — we’re planning to shoot a Super8 music video to accompany it. I’ve got my hands on a Canon AutoZoom 814 which should do the job nicely.

I’m not sure it’s fully sunk in that in 24 hours I’m going to be in the states, it’s a long journey…

Post soon.

Jim