Subject:
|
Re: Duplex Comms with RCX
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 27 Apr 2000 23:11:16 GMT
|
Viewed:
|
894 times
|
| |
|
|
In lugnet.robotics, "Pink Tail" <pinkmice@borg.com> writes:
> I applaud the thoroughness of your proposal. There's clearly
> a lot of thought gone into the idea.
Thanks. Early in my carreer, I had the benefit of actually implementing a
simple-yet-robust serial communication protocol, so I've had a lot of exposure
to the issues involved here.
> I have two questions;
>
> 1.
>
> Is the three second timeout reasonably accurate or is it, as I
> suspect, just some inaccurate RC time constant in the tower?
> In which case, you would have to choose a value like 2.5 secs
> to guarantee to stay within it.
Three seconds is an approximation. The actual time seems to vary slightly
from one tower to the next, but it is usually at least three seconds. To be
conservative, I would probably limit the maximum window to 2.5 seconds or even
less.
> 2.
>
> Assuming that RCXs with something to transmit are ready and
> waiting, why not assign one of the PCs as the master and have
> it poll each RCX "address". A smallish population of RCXs wouldn't
> take too long to cycle through. The tower would be busy almost
> all the time and packet size would not enter into the equation, except
> that one RCX could easily hog the "medium" everytime it got its
> turn. I assume here, obviously, that because the RCXs are "ready"
> a really short no-response timeout could be used for RCXs with
> nothing to transmit.
This is a nice simplification. The PC would simply poll each possible RCX in
turn, and wait for either (1) a return packet, (2) a "null" packet, or (3) a
short timeout to elapse with no response. The host would cycle through all
known station IDs in turn. This does mean that each time slot is available
only to a single station, but could be balanced by the fact that the minimum
timeslot length can be shorter. (The PC only has to wait long enough for a
single response to each token.)
I had actually considered this approach at one point early on when I was
trying to design a two-way protocol for the RCX. I think I rejected it
because I thought it might make it harder to support more than one PC per
network. I was doing all of my initial testing trying to get two PCs to talk
to each other via the LEGO IR tower, since it is easier for me to write this
kind of code on a PC than it is to write and debug new firmware for an RCX.
For this reason, I tended to gravitate toward a more symmetrical, peer-
friendly protocol, which is why I am now fixated on the approach that I
outlined in my other message. But I'm sure that this simpler method could
also be extended to support multiple PCs in a similar fashion.
I think I also figured that once the PC had sent a token, there wasn't much
benefit in repeating the token for each possible talker. If the PC can
determine that nobody responded to a token, so can the next RCX in line, so
why make the RCX wait for the PC to send the next token? But I think the RCX-
side code would be a _lot_ simpler using the scheme that you propose. And the
timing should be less critical as well, since you'd have the full three
seconds to work with per RCX (if you needed that much time) instead of
compromising packet size in order to increase the number of possible network
nodes, as my proposal does.
There are a lot of variations on this basic idea that should all work more-or-
less equally well. Unfortunately, I'm afraid that none of them are going to
be very easy to implement.
|
|
Message is in Reply To:
 | | Re: Duplex Comms with RCX
|
| I applaud the thoroughness of your proposal. There's clearly a lot of thought gone into the idea. I have two questions; 1. Is the three second timeout reasonably accurate or is it, as I suspect, just some inaccurate RC time constant in the tower? In (...) (25 years ago, 27-Apr-00, to lugnet.robotics)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
