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@algroup*StopSpam*.co.uk>
Viewed: 
2865 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 (...) (27 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
    

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