Subject:
|
Re: [OT] decoding the LEGO #9738 IR Remote Control
|
Newsgroups:
|
lugnet.robotics.handyboard
|
Date:
|
Mon, 20 Sep 1999 21:13:29 GMT
|
Original-From:
|
Nick Taylor <ntaylor@iname.com>
|
Viewed:
|
998 times
|
| |
|
|
Matt - -
Downloaded Max Davies' files, ran them on my HandyBoard ... decoded
the IR signal from both RCA and GE TV/VCR remotes with no problem,
but with the LEGO remote it says "RC-5 NOT SUPPORTED". I guess that
RC-5 is an IR encoding protocol ... now it's time to UTFSE (start
using the search engine).
Thanks for the help,
- NIck -
Nick Taylor wrote:
>
> Thanks Matt, I'm going to go take a look right now.
> - Nick -
>
> Matt Austin wrote:
> >
> > Nick,
> > Perhaps this will help, http://www.cam.org/~mdavies/HB/ir.htm The guy has a
> > great C file which you load into the Handyboard, it then decodes the remote
> > and tells you all about it, all the info's in the readme file.
> > Matt
> >
> > -----Original Message-----
> > From: Nick Taylor <ntaylor@iname.com>
> > To: handyboard@media.mit.edu <handyboard@media.mit.edu>
> > Date: 20 September 1999 01:27
> > Subject: [OT] decoding the LEGO #9738 IR Remote Control
> >
> > > Hello All:
> > >
> > > This LEGO IR remote control (#9738) is making me crazy!!!!
> > >
> > > For those of you who haven't been reading this thread, what I want to
> > > do is the following: The LEGO IR remote control is GREAT for use
> > > with 'bots using the LEGO RCX for brains. You can select, start, and
> > > stop programs, control all three motor outputs in forward and reverse
> > > directions, etc. I want to either use the IS1U60 on the HandyBard or
> > > build a module (probably an IR receiver/demodulator such as the GP1U581Y
> > > and a PIC) that will receive the LEGO remote's IR pulse train and output
> > > a digital code representing the command that can then be used by a
> > > non-LEGO 'bot brain such as the HandyBoard or a BASIC Stamp.
> > >
> > > Dave and Kekoa have posted in depth explanations of the remote's coding,
> > > but I must be awfully dense and am missing something somewhere.
> > >
> > > I've tried two approaches:
> > >
> > > First, I used both a GP1U581Y and an LTM-97DS-38 IR receiver/demodulator
> > > to receive the remote's IR pulse train and looked at the demodulated
> > > output. No matter how I looked at it, I couldn't make out any pattern
> > > that would seem to suggest that the packets are framed with "D2" or
> > > with "55 FF 00". To further complicate matters I found that both
> > > the Sharp and the Lite-On receivers inhibit their outputs until 3
> > > IR pulses have been received (78us at 38kHz) and hold the outputs
> > > low for about 190us after the IR has stopped ... this makes it hard
> > > to accurately check the bit times. It appeared that most (but not
> > > all) data bursts started with "D6" EVEN parity. It also appeared
> > > that when a button is held down for a long time, a 9 byte packet is
> > > sent repeatedly until button release, when an 8 byte packet is sent.
> > >
> > > Second, I used the LEGO IR tower to receive the remote's IR pulse
> > > train ... held pin-3 high to keep the tower alive and 'scoped pin-2.
> > > Now the bit timing looked better ... close to 417us bit times ...
> > > good for 2400 baud. But the data packets made no sense at all. It
> > > looks to me as though the tower is NOT just demodulating the IR pulse
> > > train, but is also adding data of its own
> > >
> > > Does anyone have suggestions about how to proceed? My lack of
> > > knowledge and experience with serial communications is keeping me
> > > from going any further
> > >
> > > Thanks for your help,
> > > - Nick -
> > >
> > > Dave Baum posted the remote's encoding:
> > > > >
> > > > > The remote control always sends the same sort of packet:
> > > > >
> > > > > d2 xx yy
> > > > >
> > > > > where xxyy is a sixteen bit bit-field indicating what features should • be
> > > > > activated:
> > > > >
> > > > > xxyy
> > > > > 0001 Message 1
> > > > > 0002 Message 2
> > > > > 0004 Message 3
> > > > > 0008 Motor A Forward
> > > > > 0010 Motor B Forward
> > > > > 0020 Motor C Forward
> > > > > 0040 Motor A Backward
> > > > > 0080 Motor B Backward
> > > > > 0100 Motor C Backward
> > > > > 0200 Run Program 1
> > > > > 0400 Run Program 2
> > > > > 0800 Run Program 3
> > > > > 1000 Run Program 4
> > > > > 2000 Run Program 5
> > > > > 4000 Stop Program
> > > > > 8000 Beep
> > >
> > >
> > >
> > > and Kekoa Proudfoot wrote:
> > > >
> > > > The Lego IR protocol is pretty simple. If you have demodulated output,
> > > > why not dump some samples here so we can see if they make sense?
> > > >
> > > > The encoding is straight serial, but inverted - a pulse of light • indicates
> > > > a zero or a low voltage on a serial line. It runs at 2400 baud, odd
> > > > parity, one start bit, one stop bit.
> > > >
> > > > I believe serial is normally high; the start bit is a drop to zero, the
> > > > first data bit follows one bit time later. After the eighth data bit, a
> > > > ninth bit is added so that the xor of all eight data bits plus the ninth
> > > > bit (the parity bit) is odd. The stop bit follows the parity bit and is
> > > > always high. (I might have the levels of the start/stop bits reversed, • my
> > > > apologies if this is the case; but I think I remembered correctly, since
> > > > the reason that zero/low is transmitted with light is so that the light • is
> > > > normally off when the line is idle.
> > > >
> > > > Okay, so given that description, and the fact that the serial is modulate
> > > > at 38kHz, you can figure out that there are going to be many short pulses
> > > > of light for each serial bit transmitted at 2400 baud. You are probably
> > > > going to need some sort of circit to demodumate this, if the parts you • have
> > > > don't do this already. A capacitor might be all you need, but maybe you
> > > > will also need a diode or two or three or four, I don't know.
> > > >
> > > > So given that the signal is just a serial signal, you should be able to
> > > > convert the IR into a byte stream. But that byte stream does not simply
> > > > store the d2 xx yy bytes that were mentioned earlier. It instead • contains
> > > > a header, the d2 xx yy bytes, some extra complement bytes, and a • checksum.
> > > >
> > > > The exact encoding of Lego messages is:
> > > >
> > > > 55 ff 00 D1 D1' D2 D2' ... Dn Dn' C C'
> > > >
> > > > D1 represents the first data byte; D1' is the complement (logical NOT) of
> > > > the first data byte. D2 through Dn are additional data bytes, and D2'
> > > > through Dn' are additional complement bytes. C is the least significant
> > > > byte of the sum of all data bytes, and C' is the complement of C.
> > > >
> > > > A remote control messsage would then look like this:
> > > >
> > > > 55 ff 00 d2 2d xx xx' yy yy' C C'
> > > >
> > > > Where xx, yy, C, and their complements depend on what button you pressed.
> > > >
> > > > Given a properly demodulated input stream of bytes from the remote • control,
> > > > you should now be able to extract xx and yy and figure out which buttons
> > > > were pressed given the description of the remote control message data
> > > > posted earlier.
> > > >
> > > > P.S. Dave Baum did most of the work on the low-level serial byte encoding
> > > > (buad, parity, etc.); a good amount of this discussion is just a rehash • of
> > > > a post he made a long while back regarding that topic.
> > > >
> > > > -Kekoa
> > >
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
