To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 4921
4920  |  4922
Subject: 
Re: Lego Network Protocol questions
Newsgroups: 
lugnet.robotics
Date: 
Thu, 6 May 1999 18:22:24 GMT
Viewed: 
932 times
  
Ben Laurie <ben@algroup.co.uk> wrote:
Sure, but you should be able to get the edge of the stop bit(s) to
within 1/16th bit+interrupt latency (which I'd guess is tiny in
comparison to the bit timing) which gives you the position of any other
bit just as accurately (give or take clock drift - but that should be
tiny). So, allowing a whole bit for slop is generous, IMO. This should
make a slotted protocol quite achievable and efficient. Some fun in
getting started, but after that, no problem.

I was under the impression you wanted to sync a clock to the rhythm of bit
arrivals.  You cannot do this.  You can definitely sync a clock to the
rhythm of byte arrivals.  I was trying to point out this distinction to
you.  You must have been assuming measurement of the byte arrival times
even though you were talking exclusively about bits.  No matter, we were
talking about the same thing then.

You mention measurement accuracy to 1/16th bit + interrupt latency, and
that interrupt latency was small in comparison.  Certainly interrupt
latency is sub-millisecond.  The system timer has a resolution of 1 ms, but
the underlying H8 timer has resolution to 1/500 ms.  The accuracy you will
be able to get will fall somewhere in there.  1 ms accuracy is pretty good,
I think.

When I said that the latency would be unreliable, it was because the OCIA
interrupt (used for scheduling, motor control, etc.) has priority over the
RXI interrupt.  Timing might be accurate most of the time, but in the rare
case when the OCIA interrupt handler is running when a byte is received,
you will get a bogus measurement, which you may or may not be able to
detect given an expected maximum amount of clock skew.

All of this does not matter much.  I agree with you that a slotted protocol
is possible to implement.  If messages are sent at 4800 baud using e.g. a
three byte 55 ff 00 leader, 8 data bytes with complements, plus checksum
with complement, the message adds up to 23 bytes and something less than 5
ms; assuming a sender always sends something at the start of its slot, I
bet you can find a way to keep clocks enough in sync to get away with (in
this example) 5 or 6 ms slots no problem.

I'm still interested in the overall throughput/latency comparisons between
slotted and unslotted if anyone has gotten around to doing them.

-Kekoa



Message has 1 Reply:
  Re: Lego Network Protocol questions
 
(...) That was someone else. I came in in the middle :-) (...) See above. (...) Will it be big enough to matter in the slotted protocol context? (...) No problem at all, I'd guess. Cheers, Ben. -- (URL) grandfather once told me that there are two (...) (25 years ago, 6-May-99, to lugnet.robotics)

Message is in Reply To:
  Re: Lego Network Protocol questions
 
(...) Sure, but you should be able to get the edge of the stop bit(s) to within 1/16th bit+interrupt latency (which I'd guess is tiny in comparison to the bit timing) which gives you the position of any other bit just as accurately (give or take (...) (25 years ago, 6-May-99, to lugnet.robotics)

5 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
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR