Subject:
|
[OT] decoding the LEGO #9738 IR Remote Control
|
Newsgroups:
|
lugnet.robotics.handyboard
|
Date:
|
Sun, 19 Sep 1999 23:58:17 GMT
|
Viewed:
|
980 times
|
| |
|
|
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
|
|
|
|
