 | | | | | |
Hi I've got two RCX: a 1.5 and 2.0 version.
I' ve got a problem with IR emiter/reicever.
The 1.5 version seems to be more sensitive to reflected infrared and its
good to use !
But the 2.0 RCX is less sensitive and for example doesn't receive reflected
message from my remote control or 1.5 RCX.It has to be exactly in the axle
to receive IR.
Does anybody know about it?
CHRISMAKER
| | | | | | | | | | | | | | | |
I don't know anything about this because mine work properly.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.471 / Virus Database: 269 - Release Date: 10/04/2003
| | | | | | | | | | | | | | | | |
In lugnet.robotics.rcx, Chris Masclet wrote:
> Hi I've got two RCX: a 1.5 and 2.0 version.
> I' ve got a problem with IR emiter/reicever.
> The 1.5 version seems to be more sensitive to reflected infrared and its
> good to use !
> But the 2.0 RCX is less sensitive and for example doesn't receive reflected
> message from my remote control or 1.5 RCX.It has to be exactly in the axle
> to receive IR.
> Does anybody know about it?
>
> CHRISMAKER
we ' ve told about this thing with Philo few days ago cause he had the same
problem.
So I' ve made several tests with 4 RCX: 2 RCXv1.0 and 2 RCXv2.0 .
It seems RCX emitter is the same in 1.0 and 2.0 versions.
But 2.0 receiver is less sensitive than 1.0's one..........
This is a weird thing!!!
Chris.
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.rcx, Chris Masclet wrote:
> In lugnet.robotics.rcx, Chris Masclet wrote:
> > Hi I've got two RCX: a 1.5 and 2.0 version.
> > I' ve got a problem with IR emiter/reicever.
> > The 1.5 version seems to be more sensitive to reflected infrared and its
> > good to use !
> > But the 2.0 RCX is less sensitive and for example doesn't receive reflected
> > message from my remote control or 1.5 RCX.It has to be exactly in the axle
> > to receive IR.
> > Does anybody know about it?
> >
> > CHRISMAKER
>
> we ' ve told about this thing with Philo few days ago cause he had the same
> problem.
>
> So I' ve made several tests with 4 RCX: 2 RCXv1.0 and 2 RCXv2.0 .
>
> It seems RCX emitter is the same in 1.0 and 2.0 versions.
> But 2.0 receiver is less sensitive than 1.0's one..........
>
> This is a weird thing!!!
I think there might be an explanation for this and I've been meaning to post on
this topic, but never seem to have gotten around to it! :-)
I've opened up my RCX 1.0 and the IR receiver has the markings "TSOP 1138" on
it. After looking this part number up, it appears it is an IR receiver
sensitive to a 38KHz IR carrier. This is the "normal" carrier for RCX messages.
However, my RCX 2.0 has an IR receiver with "TSOP 1176" markings. I couldn't
find any info on this part, but knowing that a TSOP-1140 is an IR receiver for a
40KHz carrier leads me to extrapolate that the IR receiver in my RCX 2.0 is
sensitive to a 76KHz carrier (double the 38KHz carrier).
Now, as has been mentioned here before, the Spybot and Manas remotes send IR
messages using a 76KHz IR carrier. My RCX 2.0 can receive these messages just
fine, while my RCX 1.0 struggles to receive these messages even with the remote
a few inches from the RCX.
While the TSOP-1176 is also apparently sensitive to a 38KHz carrier (otherwise
it couldn't receive normal RCX messages), it may be with less sensitivity than
the native TSOP-1138. This could be the reason for the observed differences in
IR reception between the different RCX versions.
Mark
BTW, the TSOP-1176 part is also used as the receiver in Spybots and Manas motor
units.
| | | | | | | | | | | | | | | | | | |
| |
|
chip 1138 / chip 1176
Strange... 38 + 38 = 76
What does that mean?
Rob
"Mark Riley" <markril@hotmail.com> wrote in message
news:Hn6xKJ.1o68@lugnet.com...
> In lugnet.robotics.rcx, Chris Masclet wrote:
> > In lugnet.robotics.rcx, Chris Masclet wrote:
> > > Hi I've got two RCX: a 1.5 and 2.0 version.
> > > I' ve got a problem with IR emiter/reicever.
> > > The 1.5 version seems to be more sensitive to reflected infrared and • its
> > > good to use !
> > > But the 2.0 RCX is less sensitive and for example doesn't receive • reflected
> > > message from my remote control or 1.5 RCX.It has to be exactly in the • axle
> > > to receive IR.
> > > Does anybody know about it?
> > >
> > > CHRISMAKER
> >
> > we ' ve told about this thing with Philo few days ago cause he had the • same
> > problem.
> >
> > So I' ve made several tests with 4 RCX: 2 RCXv1.0 and 2 RCXv2.0 .
> >
> > It seems RCX emitter is the same in 1.0 and 2.0 versions.
> > But 2.0 receiver is less sensitive than 1.0's one..........
> >
> > This is a weird thing!!!
>
> I think there might be an explanation for this and I've been meaning to • post on
> this topic, but never seem to have gotten around to it! :-)
>
> I've opened up my RCX 1.0 and the IR receiver has the markings "TSOP 1138" • on
> it. After looking this part number up, it appears it is an IR receiver
> sensitive to a 38KHz IR carrier. This is the "normal" carrier for RCX • messages.
>
> However, my RCX 2.0 has an IR receiver with "TSOP 1176" markings. I • couldn't
> find any info on this part, but knowing that a TSOP-1140 is an IR receiver • for a
> 40KHz carrier leads me to extrapolate that the IR receiver in my RCX 2.0 • is
> sensitive to a 76KHz carrier (double the 38KHz carrier).
>
> Now, as has been mentioned here before, the Spybot and Manas remotes send • IR
> messages using a 76KHz IR carrier. My RCX 2.0 can receive these messages • just
> fine, while my RCX 1.0 struggles to receive these messages even with the • remote
> a few inches from the RCX.
>
> While the TSOP-1176 is also apparently sensitive to a 38KHz carrier • (otherwise
> it couldn't receive normal RCX messages), it may be with less sensitivity • than
> the native TSOP-1138. This could be the reason for the observed • differences in
> IR reception between the different RCX versions.
>
> Mark
>
> BTW, the TSOP-1176 part is also used as the receiver in Spybots and Manas • motor
> units.
| | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.rcx, Mark Riley wrote:
> In lugnet.robotics.rcx, Chris Masclet wrote:
> > In lugnet.robotics.rcx, Chris Masclet wrote:
> > > Hi I've got two RCX: a 1.5 and 2.0 version.
> > > I' ve got a problem with IR emiter/reicever.
> > > The 1.5 version seems to be more sensitive to reflected infrared and its
> > > good to use !
> > > But the 2.0 RCX is less sensitive and for example doesn't receive reflected
> > > message from my remote control or 1.5 RCX.It has to be exactly in the axle
> > > to receive IR.
> While the TSOP-1176 is also apparently sensitive to a 38KHz carrier (otherwise
> it couldn't receive normal RCX messages), it may be with less sensitivity than
> the native TSOP-1138. This could be the reason for the observed differences in
> IR reception between the different RCX versions.
>
> Mark
>
> BTW, the TSOP-1176 part is also used as the receiver in Spybots and Manas motor
> units.
OK thanks for your reply!
But the bad thing is that two RCX2.0 could not communicate properly....Am I
wrong??
Chris.
| | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.rcx, Mark Riley wrote:
> I've opened up my RCX 1.0 and the IR receiver has the markings "TSOP 1138" on
> it. After looking this part number up, it appears it is an IR receiver
> sensitive to a 38KHz IR carrier. This is the "normal" carrier for RCX messages.
>
> However, my RCX 2.0 has an IR receiver with "TSOP 1176" markings. I couldn't
> find any info on this part, but knowing that a TSOP-1140 is an IR receiver for a
> 40KHz carrier leads me to extrapolate that the IR receiver in my RCX 2.0 is
> sensitive to a 76KHz carrier (double the 38KHz carrier).
>
> Now, as has been mentioned here before, the Spybot and Manas remotes send IR
> messages using a 76KHz IR carrier. My RCX 2.0 can receive these messages just
> fine, while my RCX 1.0 struggles to receive these messages even with the remote
> a few inches from the RCX.
>
> While the TSOP-1176 is also apparently sensitive to a 38KHz carrier (otherwise
> it couldn't receive normal RCX messages), it may be with less sensitivity than
> the native TSOP-1138. This could be the reason for the observed differences in
> IR reception between the different RCX versions.
>
> Mark
>
> BTW, the TSOP-1176 part is also used as the receiver in Spybots and Manas motor
> units.
Hello Mark,
Thanks for your answer, this will keep me from dismantling once again my RCXs !
So it seems that LEGO modified RCX2.0 to get better compatibility with
Spybots/Manas. Now a question remains, why did they increased carrier frequency
on new products? Better remote sensitivity? (I find that the remote control of
these devices do work remarquably well). Or increased communication speed?
IMHO, the choice of 76KHz carrier enables some sensitivity to older 38KHz
frequency, there is probably enough second harmonic to get through receiver
bandpass filter. Interestingly enough, 76 KHz is not an IR standard frequency,
and Vishay who manufactures TSOP1138 makes receiver only in 30 to 56 KHz range.
See documentation / tutorial here: http://www.vishay.com/docs/80069/80069.pdf
Now we should probably get better RCX2 to RCX2 transmission performance by
switching communication carrier to 76KHz as is done to speak to manas:
"SetSerialComm(SERIAL_COMM_4800|SERIAL_COMM_DUTY25|SERIAL_COMM_76KHZ);"
To be tested...
Philo
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.rcx, Philippe Hurbain wrote:
> Thanks for your answer, this will keep me from dismantling once again my RCXs !
Mine have been apart more often than I'd like, too! :-)
> So it seems that LEGO modified RCX2.0 to get better compatibility with
> Spybots/Manas. Now a question remains, why did they increased carrier frequency
> on new products? Better remote sensitivity? (I find that the remote control of
> these devices do work remarquably well). Or increased communication speed?
My guess would be mostly for increased communication speed. With the higher
baud rate, the duration of the 2-byte Spybot/Manas packets is halved. This
allows for fewer collisions from remotes on different channels and hence a
higher update rate for the motor commands being sent (i.e. the motors will
appear more responsive).
> IMHO, the choice of 76KHz carrier enables some sensitivity to older 38KHz
> frequency, there is probably enough second harmonic to get through receiver
> bandpass filter. Interestingly enough, 76 KHz is not an IR standard frequency,
> and Vishay who manufactures TSOP1138 makes receiver only in 30 to 56 KHz range.
> See documentation / tutorial here: http://www.vishay.com/docs/80069/80069.pdf
It's interesting, the responsivity chart in the above document only covers 0.7
to 1.3 the designed carrier frequency... I wonder what the relative response is
for half the carrier frequency - at least this would give us a ballpark figure
at what reduction in sensitivity we're experiencing at 38 KHz.
Might the TSOP-1176 parts have started appearing in RCXs prior to RCX 2.0?
Could there be any RCX "1.5" units with this new receiver?
Mark
| | | | | | | | | | | | | | | | | | |
In lugnet.robotics.rcx, Mark Riley wrote:
> Now, as has been mentioned here before, the Spybot and Manas remotes send IR
> messages using a 76KHz IR carrier. My RCX 2.0 can receive these messages just
> fine, while my RCX 1.0 struggles to receive these messages even with the remote
> a few inches from the RCX.
Hello Mark,
How did you managed to receive Spybot remotes messages with your RCX? I tried
several settings, no luck :-(
Philo
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.rcx, Philippe Hurbain wrote:
> In lugnet.robotics.rcx, Mark Riley wrote:
> > Now, as has been mentioned here before, the Spybot and Manas remotes send IR
> > messages using a 76KHz IR carrier. My RCX 2.0 can receive these messages just
> > fine, while my RCX 1.0 struggles to receive these messages even with the remote
> > a few inches from the RCX.
>
> Hello Mark,
>
> How did you managed to receive Spybot remotes messages with your RCX? I tried
> several settings, no luck :-(
>
> Philo
Hi Philippe,
I've been adding support for the Spybot and Manas remotes to my custom firmware
LDCC. The idea is to allow 3 people to each control a seperate train using
these remotes. This is how I discovered the problem with RCX 1.0 not receiving
the packets from the remotes very well.
Unfortunately, I don't think there is a way to receive the remote packets using
Lego's standard firmware, though it's easy enough to send the packets for
controlling Spybots or Manas motor units.
However, I put together a fun little program for BrickOS that turns the RCX into
a Manas motor unit. I've run an RCX 2.0 and a Spybot around the room using the
Spybot remotes and they both respond wonderfully.
Have fun,
Mark
// rspybot.c - 11/02/03 - Mark Riley
// This is an example program for BrickOS 0.2.6.10 that
// enables the RCX to detect packets sent by the Spybot or
// Manas remote controls. Motors A and C are activated in
// response to the left/right motor commands from the remote.
// With the Spybot remote, pressing the fire button will
// activate output B.
// By default, the program listens to channel 1, however, you
// can reprogram the channel using the same technique used by
// the Spybot remote to reprogram a Spybot.
// This program is intended for use on an RCX 2.0. It doesn't
// work well with RCX 1.0 since the IR receiver isn't sensitive
// enough at the 76 KHz carrier frequency used by the Spybot
// and Manas remotes.
#include <unistd.h>
#include <conio.h>
#include <time.h>
#include <dmotor.h>
#include <persistent.h>
#include <sys/h8.h>
// returns received IR byte (-1 if no byte available)
int get_ir_byte()
{
// byte ready?
if (S_SR & SSR_RECV_FULL)
{
// yes, clear ready bit and return the byte
S_SR &= ~SSR_RECV_FULL;
return S_RDR;
}
// clear any errors encountered
if (S_SR & SSR_ERRORS)
S_SR &= ~SSR_ERRORS;
// no byte received
return -1;
}
unsigned char spy_packet[2];
unsigned char spy_count;
int spy_timeout;
// returns non-zero result when valid packet received
unsigned char get_spy_packet()
{
int b = get_ir_byte();
if (b >= 0)
{
spy_packet[spy_count++] = b;
switch (spy_count)
{
case 1:
// set timeout for second byte
spy_timeout = (int)get_system_up_time() + 4;
break;
case 2:
spy_count = 0;
// verify checksum
if ( ( ( spy_packet[0] + (spy_packet[0] >> 4) +
spy_packet[1] + (spy_packet[1] >> 4) ) & 0x0F ) == 0 )
return 1; // good, packet ready!
break;
}
}
// reset if next byte not received in timely fashion
if ((int)get_system_up_time() - spy_timeout >= 0)
spy_count = 0;
// packet not ready
return 0;
}
unsigned char channel __persistent = 1;
int motor_timeout;
int fire_timeout;
int main()
{
// disable serial receive IRQ handler
S_CR &= ~SCR_RX_IRQ;
// switch to 4800 baud
S_BRR = B4800;
motor_a_speed(MAX_SPEED);
motor_b_speed(MAX_SPEED);
motor_c_speed(MAX_SPEED);
while (!shutdown_requested())
{
// packet ready?
if (get_spy_packet())
{
// yes, display received packet
cputw((spy_packet[0] << 8) | spy_packet[1]);
// check for left/right motor packet
// format: 01CCRRRR LLLLSSSS
// C = channel number (1 to 3)
// R = right motor
// L = left motor
// S = checksum
if ((spy_packet[0] & 0xC0) == 0x40)
if (((spy_packet[0] & 0x30) >> 4) == channel)
{
// left motor
switch (spy_packet[1] & 0xF0)
{
case 0x70: motor_a_dir(fwd); break;
case 0xF0: motor_a_dir(rev); break;
default: motor_a_dir(off); break;
}
// right motor
switch (spy_packet[0] & 0x0F)
{
case 0x07: motor_c_dir(fwd); break;
case 0x0F: motor_c_dir(rev); break;
default: motor_c_dir(off); break;
}
// set timeout for motor packets
motor_timeout = (int)get_system_up_time() + 200;
}
// check for fire button packet
// format: 00CC0001 0001SSSS
// C = channel number (1 to 3)
// S = checksum
if ( (spy_packet[0] & 0xCF) == 0x01 &&
(spy_packet[1] & 0xF0) == 0x10 )
if (((spy_packet[0] & 0x30) >> 4) == channel)
{
motor_b_dir(fwd);
// set timeout for fire button packet
fire_timeout = (int)get_system_up_time() + 250;
}
// check for channel assignment packet
// format: 100100CC 1111SSSS
// C = channel number (1 to 3)
// S = checksum
if ( (spy_packet[0] & 0xFC) == 0x90 &&
(spy_packet[1] & 0xF0) == 0xF0 )
channel = spy_packet[0] & 0x03;
}
// turn off motors A & C if no motor packet received in a while
if ((int)get_system_up_time() - motor_timeout >= 0)
{
motor_a_dir(off);
motor_c_dir(off);
}
// turn off output B if no fire button packet received in a while
if ((int)get_system_up_time() - fire_timeout >= 0)
motor_b_dir(off);
msleep(1);
}
// restore original IR settings
S_BRR = B2400;
S_CR |= SCR_RX_IRQ;
return 0;
}
// EOF
| | | | | | | | | | | | | | | | | |
In lugnet.robotics.rcx, Mark Riley wrote:
> Unfortunately, I don't think there is a way to receive the remote packets using
> Lego's standard firmware, though it's easy enough to send the packets for
> controlling Spybots or Manas motor units.
Thanks, Mark, I was indeed using standard firmware through NQC...
Philo
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.rcx, Mark Riley wrote:
> I've been adding support for the Spybot and Manas remotes to my custom firmware
>
> I put together a fun little program for BrickOS that turns the RCX into
> a Manas motor unit. I've run an RCX 2.0 and a Spybot around the room using the
> Spybot remotes and they both respond wonderfully.
Mark,
Thanks for posting this. I've been trying to figure out how to do that, but I
don't know enough about the IR messages and baud control of BrickOS to do it
myself.
>
> // check for channel assignment packet
> // format: 100100CC 1111SSSS
> // C = channel number (1 to 3)
> // S = checksum
> if ( (spy_packet[0] & 0xFC) == 0x90 &&
> (spy_packet[1] & 0xF0) == 0xF0 )
> channel = spy_packet[0] & 0x03;
> }
I don't know if this is printed anywhere, but here's some more info about the
Spybot remotes:
"in addition to the channels 1, 2 and 3, there are
three more channels 4, 5 and 6 (which you select in Setup mode by holding
down the lower left buttion (SHIFT) when pressing the normal channel buttons"
so, you can have SIX people running trains at the same time.
You may want to make the changes, and try this out to see if it works with your
stuff.
Thanks again for posting it.
Steve
| | | | | | | | | | | | | | | | |
In lugnet.robotics.rcx, Steve Hassenplug wrote:
>
> Thanks for posting this. I've been trying to figure out how to do that, but I
> don't know enough about the IR messages and baud control of BrickOS to do it
> myself.
>
> >
> > // check for channel assignment packet
> > // format: 100100CC 1111SSSS
> > // C = channel number (1 to 3)
> > // S = checksum
> > if ( (spy_packet[0] & 0xFC) == 0x90 &&
> > (spy_packet[1] & 0xF0) == 0xF0 )
> > channel = spy_packet[0] & 0x03;
> > }
>
> I don't know if this is printed anywhere, but here's some more info about the
> Spybot remotes:
>
> "in addition to the channels 1, 2 and 3, there are
> three more channels 4, 5 and 6 (which you select in Setup mode by holding
> down the lower left buttion (SHIFT) when pressing the normal channel buttons"
As cool as this sounds, it's not right. :( Sorry about that.
There are just the two bits (like Mark said above).
See, this is why I haven't been able to get my Spybot remote to work with my
RCX. :)
Steve
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.rcx, Steve Hassenplug wrote:
> In lugnet.robotics.rcx, Steve Hassenplug wrote:
> >
> > Thanks for posting this. I've been trying to figure out how to do that, but I
> > don't know enough about the IR messages and baud control of BrickOS to do it
> > myself.
You're welcome!
> > >
> > > // check for channel assignment packet
> > > // format: 100100CC 1111SSSS
> > > // C = channel number (1 to 3)
> > > // S = checksum
> > > if ( (spy_packet[0] & 0xFC) == 0x90 &&
> > > (spy_packet[1] & 0xF0) == 0xF0 )
> > > channel = spy_packet[0] & 0x03;
> > > }
> >
> > I don't know if this is printed anywhere, but here's some more info about the
> > Spybot remotes:
> >
> > "in addition to the channels 1, 2 and 3, there are
> > three more channels 4, 5 and 6 (which you select in Setup mode by holding
> > down the lower left buttion (SHIFT) when pressing the normal channel buttons"
>
>
> As cool as this sounds, it's not right. :( Sorry about that.
>
> There are just the two bits (like Mark said above).
>
> See, this is why I haven't been able to get my Spybot remote to work with my
> RCX. :)
Well, I did try it out and it does work... somewhat. For example, when you set
the channel to 5 using the technique mentioned above, only some of the remote
packets reflect 5 as the channel number, while others still indicate a channel
of 2. Unfortunately, in the main operating mode (mode lever flipped all the way
to the left) the channel # in the packets for the motor and fire* buttons is 2,
not 5. So this leaves us with only 3 channels for controlling the drive motors.
The buttons that send packets in the setup and ping modes *do* indicate channel
5, however.
I modified my program like this to take into account the possibility of getting
a channel assignment packet in the range 4 to 6:
// check for channel assignment packet
// format: 10010CCC 1111SSSS
// C = channel number (1 to 6)
// S = checksum
if ( (spy_packet[0] & 0xF8) == 0x90 &&
(spy_packet[1] & 0xF0) == 0xF0 )
{
channel = spy_packet[0] & 0x07;
if (channel > 3) channel -= 3; // reduce to 1-3 range
}
I'm curious, Steve, where did you get the information about channels 4-6?
(Thanks, BTW!) It always bothered me that the lower left button didn't appear
to do anything in setup mode.
So, here's a brief summary of the Spybot remote packets (AFAIK):
Operating Mode
01CCRRRR LLLLSSSS Motor drive buttons (repeats when buttons held down)
10010CCC 0010SSSS Fire button (once when button pressed)
00CC0001 0001SSSS Fire button (repeats when button held down)
Setup Mode
10010CCC 1111SSSS Channel assignment (lower right button)
Ping Mode
10010CCC 0000SSSS Ping (repeats continuously)
10010CCC 0001SSSS Upper left button (once when button pressed)
10010CCC 0010SSSS Fire button (once when button pressed)
10010CCC 0011SSSS Upper right button (once when button pressed)
10010CCC 0100SSSS Lower left button (once when button pressed)
10010CCC 0101SSSS Lower right button (once when button pressed)
Legend
CC = Channel number (1 to 3)
CCC = Channel number (1 to 6)
SSSS = Checksum (chosen so sum of all nibbles is zero)
RRRR = Right motor buttons
0000 - No button pressed
0111 - Foward pressed
1111 - Reverse pressed
LLLL = Left motor buttons
0000 - No button pressed
0111 - Foward pressed
1111 - Reverse pressed
Anyway, I can only imagine the chaos that would ensue if six people could each
control a train on the layout. Three people is more than enough for some
spectacular derailments - just ask my kids! :-)
Mark
* The first packet issued with the fire button in operating mode does indicate
channel 5. The following packets all are channel 2.
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.rcx, Mark Riley wrote:
> So, here's a brief summary of the Spybot remote packets (AFAIK):
>
> Operating Mode
>
> 01CCRRRR LLLLSSSS Motor drive buttons (repeats when buttons held down)
> 10010CCC 0010SSSS Fire button (once when button pressed)
> 00CC0001 0001SSSS Fire button (repeats when button held down)
>
> Setup Mode
>
> 10010CCC 1111SSSS Channel assignment (lower right button)
>
> Ping Mode
>
> 10010CCC 0000SSSS Ping (repeats continuously)
> 10010CCC 0001SSSS Upper left button (once when button pressed)
> 10010CCC 0010SSSS Fire button (once when button pressed)
> 10010CCC 0011SSSS Upper right button (once when button pressed)
> 10010CCC 0100SSSS Lower left button (once when button pressed)
> 10010CCC 0101SSSS Lower right button (once when button pressed)
>
> Legend
>
> CC = Channel number (1 to 3)
> CCC = Channel number (1 to 6)
> SSSS = Checksum (chosen so sum of all nibbles is zero)
> RRRR = Right motor buttons
> 0000 - No button pressed
> 0111 - Foward pressed
> 1111 - Reverse pressed
> LLLL = Left motor buttons
> 0000 - No button pressed
> 0111 - Foward pressed
> 1111 - Reverse pressed
Thanks a lot for posting this very useful information, Mark! I don't know how
long I've been beating my head against the brick trying to make heads or tails
out of the values I calculated for the various possible combinations of button
presses. The Spybot remotes can also transmit on channel zero, I believe.
Also, it seems to me that it would be better to document the Spybot remote by
button number rather than RRRR/LLLL either forward or reverse.
Here's the table of hex numbers I've been using:
CHANNEL
Btn 0 1 2 3
1 0x4075 0x5074 0x6073 0x7072
2 0x9025 0x9124 0x9223 0x9322
3 0x4705 0x5704 0x6703 0x7702
4 0x40fd 0x50fc 0x60fb 0x70fa
5 0x5f0d 0x5f0c 0x6f0b 0x7f0a
3/4 0x47f6 0x57f5 0x67f4 0x77f3
1/5 0x4f76 0x5f75 0x6f74 0x7f73
1/3 0x477e 0x577d 0x677c 0x777b
4/5 0x4ffe 0x5ffd 0x6ffc 0x7ffb
Probably not very helpful. On second thought, maybe it's better to not think
about button numbers. :-) How on earth did you figure this all out?
John Hansen
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.robotics.rcx, John Hansen wrote:
> In lugnet.robotics.rcx, Mark Riley wrote:
> > So, here's a brief summary of the Spybot remote packets (AFAIK):
[snippage]
> Thanks a lot for posting this very useful information, Mark! I don't know how
> long I've been beating my head against the brick trying to make heads or tails
> out of the values I calculated for the various possible combinations of button
> presses. The Spybot remotes can also transmit on channel zero, I believe.
> Also, it seems to me that it would be better to document the Spybot remote by
> button number rather than RRRR/LLLL either forward or reverse.
>
> Here's the table of hex numbers I've been using:
[more snippage]
> Probably not very helpful. On second thought, maybe it's better to not think
> about button numbers. :-) How on earth did you figure this all out?
Glad you like the chart. Trying to find a way to present the information in a
useful manner was the trick for me, too. :-) I'll have to throw up a web page
or something.
As to figuring it out, credit has to first go to John Barnes for figuring out
the Manas protocol as mentioned in this post:
http://news.lugnet.com/robotics/?n=15809
The Spybot packets are just more of the same, although with some interesting
dynamics. Like, some buttons repeat the packet while the button is held down,
and others only send the packet once, the fire button actually sends two types
of packets in operating mode, etc... You can use the Monitor IR menu command in
ScriptEd (I know... boo, hiss... :-) to observe the packet order and repeat
rates. Also, the BrickOS program I posted in this thread will display the
remote packets on the RCX display.
I know the Manas remotes can send on channel "0" (same as "all channels"), but I
don't think I've seen my Spybot remotes do that. Is there some trick I'm
missing?
I agree, I should probably specify the button instead of using something like
"forward" like so:
RRRR = Right motor buttons
0000 - No button pressed
0111 - Foward pressed (upper right button)
1111 - Reverse pressed (lower right button)
LLLL = Left motor buttons
0000 - No button pressed
0111 - Foward pressed (upper left button)
1111 - Reverse pressed (lower left button)
Cheers,
Mark
| | | | | | | | | | | | | | | | | | |
In lugnet.robotics.rcx, Mark Riley wrote:
> In lugnet.robotics.rcx, Steve Hassenplug wrote:
> > > > // check for channel assignment packet
> > > > // format: 100100CC 1111SSSS
> > > > // C = channel number (1 to 3)
> > >
> > > in addition to the channels 1, 2 and 3, there are
> > > three more channels 4, 5 and 6 • ...
> Well, I did try it out and it does work... somewhat. • ...
> The buttons that send packets in the setup and ping modes *do* indicate channel
> 5, however.
Yes. The extra channels are for non-repeating stuff. Like you said.
> I'm curious, Steve, where did you get the information about channels 4-6?
> (Thanks, BTW!)
Well, I've discovered (while working on a Spybot project) that if you ask just
the right question, the people at LEGO may reply to it.
They are listening... :)
Steve
| | | | | | |
