- Decoding old LEGO infrared protocol
- Decoding RCX IR command protocol
This started most as a curious thing and now I realize it went crazy. But I learned a lot so perhaps other may benefit of it.
On my quest to control all LEGO MINDSTORMS models ever sold from a single “gateway” I started a few weeks ago my work with the Spybotics:
This little fellow has 2 motors and a touch sensor inside, can talk IR and also reacts to VLL. So it’s kind of a Micro Scout on steroids. And, with a little of good will, we can call it the ancestor of the LEGO BOOST, among the Cybermaster.
The Spybotics was programmed with a serial-to-optical cable. I still don’t have one so I tried to program it with a RCX USB IR Tower using NQC (there are some reports that the USB version of the IR Tower can “speak” at 38 and 76 kHz and the later is needed for the Spybotics). But no success yet.
The Spybotics also reacts to a IR Remote Control:
The protocol allows 3 different channels and it’s also possible to send commands to all 3 channels simultaneouslys so I decided to get more information about the protocol.
Turns out that this IR protocol was implemented by LEGO a few years before the Power Functions IR protocol but it never gained momentum and it was quickly abandoned. But a few interesting systems used this protocol:
- the 8539 Bionicle Technic Manas
- the 4589 RC Nitro Flash
- the 7897 9V RC Train
- … and the 2949 DUPLO Remote Control Dozer
The last one surprised me as I have two of these, after a very lucky finding 4 years ago on our summer holidays – our kids love them and we use them at our LUG events with great success among young visitors:
So I picked up my Manas, Spybotics and DUPLO commands… and yes, they are interchangeable!
It would be great if I could control my kids DUPLO Dozer from the computer, side-by-side with the Spybotics and the Manas.
So let’s find more details about this pre-Power Functions IR protocol.
The best I could find were references to a Rob Doucette document where he gathered info collected from several Lugnet posts (mainly contributed by John Barnes). One of those references is Philo’s site, where he shows how he used is RCX to control the RC Nitro Flash).
Unfortunatelly the original document location no longer exists:
“http://www.doucettenet.com/lego/manas.pdf”
but thanks to the Internet Archive Wayback Machine I managed to retrieve the document from a May 2008 snapshot.
The low level details are resumed in 2 sentences:
“The transmitters transmit short messages of two bytes encoded as 8 bit + odd parity. The transmissions use 76kHz modulated IR at a baud rate of 4800, 25% duty cycle.”
Each message contains 4 nibbles (4-bit digits):
Channel + Orange + Yellow + Checkdigit
Channel can be 4/5/6/7 (meaning all, #1, #2 or #3)
Orange and Yellow can be 0/7/8/F (no button, forward button, reverse button and stop or immediate off)
And Checkdigit = 10h – (Channel + Orange + Yellow) AND Fh
The space between each message is different according to the channel used (simillar to PF IR protocol):
Ch. 1 – 19.6 Hz
Ch. 2 – 14.8 Hz
Ch. 3 – 11.6 Hz
‘All’ – 19.6 Hz
The document also has a NQC program demonstrating how to use the RCX to control 3 Manas units (each on its channel)
I tried to replicate the commands with an Arduino and an IR LED but all my attempts failed miserably. After getting tired of it, I decided to analyze the signal, but since I don’t own a scope or a logic analyzer I had to use the only tools I have: an Arduino, a Raspberry Pi, a laptop and Google.
So to “sniff” the IR signal I used an Arduino Uno with a TSOP4856 as an IR decoder and a IR LED for testing my signals back. The setup is pretty much the same as this Adafruit lession:
The TSOP signal is connected to Arduino pin 2 and the IR LEDs are connected to Arduino pin 3 (that’s right, two LED’s in serial, no resistors… might use a transistor later).
The TSOP module has a filter better suited for 56 kHz carrier – not quite the 76 kHz I wanted but it was the higher carrier I could found – just for the record, an IR photodiode and a 1M resistor also works, both devices can detect the 76 kHz signal at short distances.
So I installed cyborg5’s IRLib2 Arduino library on my laptop and tried the rawRecv sketch available on the examples folder. Pressing the Yellow Forward button on the Manas command I got this:
Ready to receive IR signals
Do a cut-and-paste of the following lines into the
designated location in rawSend.ino
#define RAW_DATA_LEN 12
uint16_t rawData[RAW_DATA_LEN]={
1082, 206, 154, 238, 178, 590, 594, 238,
178, 658, 178, 1000};
So I passed those last lines into the rawSend sketch and changed the carrier frequency to 76:
mySender.send(rawData,RAW_DATA_LEN,76);
… and each time I sent a key to the Arduino serial terminal my Manas yellow motor rotated forward.
Wow!
I tried to find some meaning to those values but I was totally lost. Tried to use another skech (Analyze) but the results made no sense… I captured all keys combinations and they worked but I wanted to know the meaning.
So I used the same TSOP4856 on my Raspberry Pi and installed LIRC, so I can use “mode2” command to record a signal. Recent stretch-based versions of Raspbian have some quirks but following this method I had success.
$ mode2 -d /dev/lirc0
space 16777215 pulse 1085 space 179 pulse 239 space 174 pulse 239 space 534 pulse 651 space 175 pulse 190 space 644 pulse 190 space 46681 pulse 1090 space 156 pulse 260 space 183 pulse 235 space 526 pulse 658 space 173 pulse 241 space 576 pulse 259 space 1518 pulse 69 space 45041 pulse 1090 space 156 pulse 211 space 225 pulse 190 space 579 pulse 607 space 226 pulse 189 space 643 pulse 195 space 46689 pulse 1090 space 176 pulse 242 space 175 pulse 241 space 495 pulse 676 space 175 pulse 242 space 572 pulse 274 space 46589 pulse 1041 space 210 pulse 204 space 210 pulse 207 space 578 pulse 607 space 207 pulse 224 space 610 pulse 220 space 46642 pulse 1041 space 214 pulse 200 space 227 pulse 190 space 566 pulse 604 space 230 pulse 187 space 661 pulse 172 space 46683 pulse 1038 space 211 pulse 206 space 210 pulse 206 space 561 pulse 207 space 417 pulse 207 space 210 pulse 1042 space 46445 pulse 1038 space 209 pulse 217 space 201 pulse 204 space 584 pulse 173 space 434 pulse 190 space 227 pulse 1027 space 921 pulse 159 space 45364 pulse 1038 space 213 pulse 201 space 230 pulse 187 space 578 pulse 190 space 437 pulse 187 space 230 pulse 1021
I installed IrScrutinizer on my laptop, imported the above result (“Import signal”) and got a nice signal in the “Scrutinize signal” pane:
A zoom of the first block from the left shows a clear sign:
But how does this relates to “50 74” that, according to the protocol definition, is the 2-byte representation for “Yellow Forward on Channel #1”?
Well, after a few head aches, I got it.
First, I realize that I made a stupid beginner error: like many serial codes, the bits are sent in revere order (least significant bit of each byte first, more significant bit last).
Then I understood the rawRecv format: each value represents the time duration of a continuous mark or space before it “toggles”.
I also got confused with the bits representation (that 25% duty cycle still confuses me). But if I assume a single bit duration to be near 208 µs (for a 4800 bit per second rate), ‘zero’ as the start bit and ‘one’ as the stop bit I can translate this:
uint16_t rawData[12]={
1082, 206, 154, 238, 178, 590, 594, 238,
178, 658, 178, 1000};
5 zeros (1082) = start bit + 0000
1 one (206)
1 zero (154)
1 one (238)
1 zero (178)
3 ones (590) = odd parity bit + stop bit + pause
3 zeros (594) = start bit + 00
1 one (238)
1 zero (178)
3 ones (658)
1 zero (178)
2 or more ones (1000) that must include odd parity bit, stop bit and pause
The last value (1000 µs) is an arbitrary value used by the sketch author to end the signal.
So…
00000101011100010111011
start=0 | 0000 1010 | odd=1 | stop=1
pause=1
start=0 | 0010 1110 | odd=1 | stop=1
The odd parity bits are correct, that’s a good start.
Reverting the order of the data bits, we have:
0101 = 5 | 0000 = 0 | 0111 = 7 | 0100 = 4 => 5074
Yeah!
So the precision isn’t pretty (I got bits with just 154 µs and others with 238 µs when they all should be 208 µs long) but that doesn’t really matter – I can now recreate all signals with theory-perfect values and test if it works.
So I wrote a python script to generate all combinations for all channels and also a RemoteControl sketch – just an extended ‘rawSend’ sketch that sends different signals according to the keys received from the serial port.
This is a sample of the output of my python script:
Command: Ch1_OrangeNop_YellowFwd Msg: 00000101011100010111011 Size: 12 Signal: 1040, 208, 208, 208, 208, 624, 624, 208, 208, 624, 208, 624
And it works!
The serial port can be used directly so we can use our keyboard (in linux, just use screen to connect to the Arduino serial port, i.e. ‘screen /dev/ttyACM0′) or we can write our own programs to automate it.
And yes, we can connect the Arduino to our MINDSTORMS EV3 and use ev3dev to control our old LEGO IR devices 🙂
Even better: we can use the same approach to generate a LIRC configuration file so we don’t even need an Arduino – any IR transmitter supported by LIRC will work… including my FTDI IR emitter. That means we can use the same emitter to control all LEGO IR devices, Power Functions and pre-Power Functions:
(Power Functions LIRC configuration file based on excellent work of Conor Cary and Diomidis Spinellis)
I created a github project for this, you can get the LIRC configuration (or just the generator there).