Subject:
|
Re: Transmitting a message from the RCX to the PC
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Fri, 23 May 2003 16:19:06 GMT
|
Viewed:
|
2838 times
|
| |
|
|
n lugnet.robotics.rcx, Chris Phillips writes:
> 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 who's 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.
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!
> 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 messages.
> 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.
My initial idea/solution would be to run different firmware on one of the
RCX's incorporating a short but very useful delay in the response time, but
I'm just a relative ignorant newbie :-).
Has anyone ever thought of asking Lego if they could provide a fix for
something like this? It's so crazy it might just work.
> Does this make sense?
Perfectly
Steve
I would have replied last night but all this thinking along with having just
seen the Matrix Reloaded made my brain hurt :-)
|
|
Message is in Reply To:
 | | Re: Transmitting a message from the RCX to the PC
|
| (...) 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 (...) (21 years ago, 23-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
|
|
|
|
