Subject:
|
Re: Transmitting a message from the RCX to the PC
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Fri, 23 May 2003 13:28:32 GMT
|
Viewed:
|
3267 times
|
| |
|
|
In lugnet.robotics.rcx, John Donaldson writes:
> Why can't a mode where a two byte sequence is sent. The
> first byte is the bot address and the second byte is the
> data code. That way only the bot whos address was sent
> responds.
> If two bytes are too much, a single byte can be split to
> do the same thing. The upper four bits are the bot
> address and the lower four bits the data code. You could
> even go as far as to say the upper two bits are the bot
> address and the lower six bits is the data. This would
> give you four bots and 63 data codes.
>
> I have done this on other projects where I need to
> address multi systems and only want one system at a time
> to respond.
This is a good technique for addressing messages to an individual RCX, and
I've used it myself on many occasions. In this case, it is your RCX or NQC
program on the 'bot that is "responding" or "not responding" either by
taking action or ignoring certain messages. This is great for sending
information from the PC or an RCX to one or more RCXes.
But the "response" I am talking about, and that is so important to avoid, is
the IR response message sent by the RCX firmware to acknowledge that it
received an IR packet correctly, possibly with a return value being sent
back to the PC. If the PC sends an "interrogate variable" opcode to a
roomful of RCXes, they will all respond at the same time by sending back a
response, and the resulting interference will almost certainly corrupt any
response packet received by the PC. There is no way (short of replacing the
standard firmware with something else) to prevent an RCX from sending a
response when it sees one of these commands.
The one-byte message is the only opcode that does not cause the RCX to send
a response. Instead, every RCX that receives the opcode silently makes note
of the new message byte. This is done precisely to avoid the cacophony
problem that I described in the preceeding paragraph, and is the reason why
this messaging can be used with multiple RCXes in the room. So far, so good.
The problem as I see it is that, using Spirit.ocx, I am not aware of any way
for the PC to see these one-byte messages. (I could be wrong about this,
but this was the case last time I looked.) So one-byte messages cannot be
used to return information to the PC, since it is deaf to these messsages.
But any other opcode (for example, the PC asking an RCX to send the value of
one of its variables) will be answered by every RCX that hears the command,
and the PC will get a corrupted response every time.
Does this make sense?
- Chris.
|
|
Message has 1 Reply:
 | | Re: Transmitting a message from the RCX to the PC
|
| (...) This is what I was wondering about. You have defined the core problem that needs solving (I was going to ask you to do that). So it seems we can have one PC to RCX link or multiple RCX's but not both, darn! (...) My initial idea/solution would (...) (22 years ago, 23-May-03, to lugnet.robotics.rcx)
|
Message is in Reply To:
| | Re: Transmitting a message from the RCX to the PC
|
| I'm posting this on behalf of John Donaldson who is having a problem with his emails bouncing, so this is his text verbatim. Why can't a mode where a two byte sequence is sent. The first byte is the bot address and the second byte is the data code. (...) (22 years ago, 22-May-03, to lugnet.robotics.rcx)
|
11 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
