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 / 4929
4928  |  4930
Subject: 
Re: Lego Network Protocol questions
Newsgroups: 
lugnet.robotics
Date: 
Thu, 6 May 1999 21:34:30 GMT
Original-From: 
Ben Laurie <BEN@ALGROUPstopspam.CO.UK>
Viewed: 
1082 times
  
Kekoa Proudfoot wrote:

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.

That was someone else. I came in in the middle :-)

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.

See above.

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.

Will it be big enough to matter in the slotted protocol context?

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.

No problem at all, I'd guess.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics



Message is in Reply To:
  Re: Lego Network Protocol questions
 
(...) 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 (...) (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
    

Custom Search

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