RS485 CSMA/CD protocol

"therion" <therion0@yahoo.com> wrote in message 
news:dgv8ou$smm$1@sunce.iskon.hr...
> Hi, I would need to implement an CSMA/CD L1 protocol code for RS485 in my 
> new AVR project for home automation.
> Any link, hint or help for the similar source code?
>

Ok, while most of you where elaborating about token vs. CSMA/CD , you forgot 
the Q... and I built a prototype network with 5 nodes - and it worrks very 
well! I will post C source code soon.
The aim of the project is to build a HOME AUTOMATION network, no video, no 
brakes , not driving planes!!! just control of the light, HVAC and usual HA 
stuff.
Like Tim Shoppa pointed
" I think
the original poster was looking to avoid such mistakes by asking for
example code that does things the right (not wrong) way."

Please help in that direction!

THX. 

Rene Tschaggelar <none@none.net> writes:

> Tim Shoppa wrote:
> 
> >>And if you have
> >>multiple masters, then better implement a token
> >>protocol. IMO, this collision protocol was one of
> >>the biggest mistakes in history of IT.
> > The token ring advocates always pointed out how certain circumstances
> > could lead to collision detection not working nicely.  They were also
> > extremely unconfortable with the lack of guaranteed bandwidth for each
> > master etc.
> 
> The point is the behaviour under load. A token protocol doesn't
> require a token ring. A bus is sufficient, ARCnet works on
> twisted pair and over coax.
> 
> Tokenring failed for commercial reasons. It was single source
> and the price was beyond reasonable.

It was also *tremendously* more dificult to implement in routers and
such.  The volume of code required to add token ring was phenomenal.
(and FDDI, which participate heavily in what we called "token ring
brain damage"). 

> When you have a network and it should work under heavy load,
> eg all nodes want to transfer huge binaries at the same time,
> then a token protocol distributes the bandwidth of the medium
> over the nodes while the colision detect system just detects
> endless collisions and does endless retries.

Cheaper to buy a bit more network bandwidth and use a simpler
protocol, as it turns out.  Ethernet works fine under even rather
heavy loads in the real world. 

> It is less that the tokenring advocates were uncomfortable.
> A realtime system requires a defined response time that suits
> the physical installation this system should control.
> A car control system requires responsetimes in the millisecond
> region and you wouldn't want your cars cpu to retry some bullshit
> while you want the car to stop. Realtime response has nothing
> to do with being comfortable, it has to do with lives.

Using a *network interconnect* for something requiring realtime
response is pretty dumb, though.
-- 
David Dyer-Bennet, <mailto:dd-b@dd-b.net>, <http://www.dd-b.net/dd-b/>
RKBA: <http://noguns-nomoney.com/> <http://www.dd-b.net/carry/>
Pics: <http://dd-b.lighthunters.net/> <http://www.dd-b.net/dd-b/SnapshotAlbum/>
Dragaera/Steven Brust: <http://dragaera.info/>

Anne & Lynn Wheeler <lynn@garlic.com> writes:

> the big transition for ethernet was adding listen before transmit
> (and adapting t/r cat5 hub/spoke)

The big change was IMO, the DIX, DEC, Intel, Xerox, spec with 10Mb
over coax, and the tightened up DIX II. The original cable was a
special, and was changed to RG-forget. This also got rid of the small
embarsment of the cable exceding Tempest specs and in theory being
unexportable from the US. (The fix was to change the cable spec.)


> my vague recollection was early ethernet was 3mbit/sec, didn't do
> listen before transmit and had this big thick cables ... looked a
> lot like the pcnet cables (which i believe did 1mbit/sec but used a
> tv head-end type implementation).

There was a 3 Mb `Xerox Wire' that preceded DIX.

-- 
Paul Repacholi                               1 Crescent Rd.,
+61 (08) 9257-1001                           Kalamunda.
                                             West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.

On Tue, 27 Sep 2005 01:15:38 +0800, prep@prep.synonet.com wrote:

>Anne & Lynn Wheeler <lynn@garlic.com> writes:
>
>> the big transition for ethernet was adding listen before transmit
>> (and adapting t/r cat5 hub/spoke)
>
>The big change was IMO, the DIX, DEC, Intel, Xerox, spec with 10Mb
>over coax, and the tightened up DIX II. The original cable was a
>special, and was changed to RG-forget. This also got rid of the small
>embarsment of the cable exceding Tempest specs and in theory being
>unexportable from the US. (The fix was to change the cable spec.)

As far as I remember, the only special thing about the yellow DIX
cable was the markers that dictated the minimum distance where you
could put your vampire taps. Quite a few installations used the
standard RG-8 (currently known as RG-213), but you had to measure the
minimum tap distance yourself.

Paul

therion <therion0@yahoo.com> wrote:
> 
> "therion" <therion0@yahoo.com> wrote in message 
> news:dgv8ou$smm$1@sunce.iskon.hr...
>> Hi, I would need to implement an CSMA/CD L1 protocol code for RS485 in my 
>> new AVR project for home automation.
>> Any link, hint or help for the similar source code?
>>
> 
> Ok, while most of you where elaborating about token vs. CSMA/CD , you forgot 
> the Q... and I built a prototype network with 5 nodes - and it worrks very 
> well! I will post C source code soon.

Over what distance have you tried this? In my experience it could work 
fine on a short bus, but fail over longer distances. I've had buses
with about 20 nodes over a distance of 2-3 meters where collisions
occurred due to hardware failure. If the desired signal was input at
one end and a disturbing signal at the other then the nodes close to
the good transmitter would still reliably receive that signal, no
collision would have been detected in that end of the bus.

[snip]

> Like Tim Shoppa pointed
> " I think
> the original poster was looking to avoid such mistakes by asking for
> example code that does things the right (not wrong) way."

It's not a matter of using clever code, the electrical interface will
not work predictably in such a setup. To compensate you will have to
use a pretty complex protocol in addition to all the CSMA/CD stuff.

If you use the termination to hold the "high" level and only drive the
"low" level actively (or vice versa) you would probably stand a better
chance, It would perhaps require a lower data rate, but in home
automation I guess it could be fast enough.

> Please help in that direction!
> 

Even if that direction is a dead end?

/Henrik

-- 

On 2005-09-23, Roberto Waltman wrote:

> May be, but it also may have been an unavoidable mistake - I can not
> think of a better approach for Hawaii's original ALOHA radio network
> on which Ethernet/CSMA/CD where partially based. (Especially when you
> consider the technology available at the time.)
> Each station in the Aloha network could not listen to the others, both
> because of the terrain of the island and because the antennas were
> directed to the "common medium", the satellite, so they had to
> broadcast blindly and wait for the satellite to echo it back to all
> the stations + acknowledge, as an indication that there was not
> collision.

Only there wasn't any satellite.

Peripheral stations would broadcast uncoordinated toward the central 
station; the central station would broadcast - on a different frequency
channel - acks to the peripherals (if reception was ok) and, of course,
packets for the peripherals.

On top of that, virtual serial lines were implemented that could address
RJE or printers or whatever either at another station or at the central
site, which included a gateway to a satellite link to ARPAnet at some
point - which might be the reason for the confusion.

But yes, many of the peripheral stations would not be able to hear one
another; so carrier sense was impossible, and explicit collision
detection wasn't done either. The central station (as any other) would
discard packets with wrong CRCs and send an ACK for good packets.

Regards,
	-is
-- 
seal your e-mail: http://www.gnupg.org/