> Ok, ok! You found me out! It isn't really a "collision detection"
technique
> as much as it is a "collision avoidance" technique... The unit that is
about
> to talk tests the collision input to see if there is any traffic currently
> on the bus. If not, it waits a small about of time and tests again. The
> actual amount of testing required if up to the user. When a sufficent
number
> of tests indicate that there is n traffic then the unit begins talking.
This
> method has worked well in systems that had 128 units on one bus; should
work
> for many more.

This has two problems:

1  -  It forces a minimum amount of quiet time between packets, thereby
wasting bandwidth.

2  -  It doesn't guarantee collision avoidance any more than checking once.
If two nodes are out of sync, the second will see the first transmit either
way and therefore not transmit itself.  If both nodes are in sync, then
neither will see the other no matter how many times each of them check.
They will both check a bunch of times, see that nobody is talking, and then
both try to talk simultaneously.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body