| |
In lugnet.robotics, Kekoa Proudfoot writes:
> Dave Baum <dbaum@spambgoneenteract.com> wrote:
> > In article <FB0GKF.3s@lugnet.com>, "Mike Moran" <mm@ee.ed.ac.uk> wrote:
> > > - In general, I was wondering what the low-level protocol details were,
> > > apart from the frame/segment details that I have seen?
> >
> > Transmit whenever you feel like it and hope you didn't obliterate data
> > coming from the other direction. Rudimentary, but still quite effective
> > given the typical use pattern with is host driven command/response. With
> > RCX to RCX communication you're just taking chances on missing stuff
> > unless you implement a specific master/slave relationship on top of the
> > basic messages.
>
> Dave, did you catch the crosspost from lugnet.robotics.rcx.legos? I think
> there were details discussed there that may or may not have amounted to a
> fairly specific proposal for a protocol for LegOS. Anybody care to
> summarize whatever was decided? I'd be interested in hearing also, I
> skipped a lot of the discussion. Specifically, I would like to find out
> what was decided about the underlying packet format, down to the 55ff00s of
> the protocol.
Just to state my interests: I'm mainly interested in the protocol, eg what
level of service it would provide etc. In particular, I'm interested in
layering a higher level gauranteed delivery protocol atop whatever simple one
is provided.
> Regarding Mike's questions and ideas, I thought I'd share some thoughts
> I've had about serial protocols for the RCX.
>
> - Since the RCX receives its own echo, you can detect collisions by
> checking to see if the echo matches the transmission; the caveat is that
> echos aren't reliable if the IR link has been inactive for a few seconds.
I assumed that the IR burst would be still around whilst it was transmitting,
however, can the IR hardware actually be asked to detect a burst whilst it is
transmitting? What is the software <-> hardware interface to the IR capable of?
> - You can avoid collisions to some extent by holding off transmission if
> you are currently receiving data. You might be able to use larger
> segment sizes than you would otherwise expect if you make use of this.
> The right segment size can only be determined by experiment, I think.
> A #define is in order.
Agreed. You may even be able to use some sort of `backoff' algorithm where you
start with large segments and get smaller as more interference occurs. Then
again, if we assume a higher level protocol using sliding windows with a given
fixed underlying segment size the window would decrease in size until a
constant rate of communication was reached. It's probably better to go with
smaller segments since a higher-level protocol can decide which segments to
resend and so on (if you send an N-item chunk in M-item segments where N = M,
then if the segment is lost all N-items are lost and have to be re-transmitted,
whereas if N = cM (where c = 2, ....) then if a segment is lost only N/c items
have to be re-transmitted).
> - I would argue against using a "slotted" protocol unless you expect all
> RCXs to be in IR proximity of one another and you expect them all to be
> talking a lot of the time. I don't know how often this would be the
> case.
I'll have to look at the graph of throughput in the Tanenbaum book again to
see how much of a problem a small amount of RCX's transmitting simultaneously
would be.
> Mike, regarding synchronization for a slotted protocol, what did you mean
> by embedding that in "the wire-line signal"? Do you mean a physical wire,
> or the IR protocol?
No, I mean the IR protocol. Again, in the Tanenbaum book, he mentions wire-line
signals (ie the signal that would be on a wire if a signalling method was bieng
used) where the clock pulse shows up in the encoding method for binary data
[I'm not sure if he actually uses the term "wire-line"]. For example, in
Manchester Encoding 0's and 1's are represented as transitions from high to low
voltage or vice versa (I can't remember which is for 0 or 1). The clock shows
up because the transitions always happen on a clock tick, hence the wire-line
signal embodies some notion of time that can be used to synchronize both ends.
Are there any pages/articles on what the IR traffic actually looks like at this
level?
|
|
Message has 1 Reply:
Message is in Reply To:
15 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
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
