| Author |
Message |
therion
Guest
|
 Posted:
Sun Sep 25, 2005 12:15 am Post subject:
Re: RS485 CSMA/CD protocol |
|
|
"therion" <therion0@yahoo.com> wrote in message
news:dgv8ou$smm$1@sunce.iskon.hr...
| Quote: | 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. |
|
| Back to top |
|
 |
David Dyer-Bennet
Guest
|
| Posted:
Mon Sep 26, 2005 12:15 am Post subject:
Re: Ethernet, Aloha and CSMA/CD - |
|
|
Rene Tschaggelar <none@none.net> writes:
| Quote: | 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").
| Quote: | 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.
| Quote: | 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/> |
|
| Back to top |
|
|
Guest
|
| Posted:
Mon Sep 26, 2005 10:15 pm Post subject:
Re: Ethernet, Aloha and CSMA/CD - |
|
|
Anne & Lynn Wheeler <lynn@garlic.com> writes:
| Quote: | 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.)
| Quote: | 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. |
|
| Back to top |
|
|
Paul Keinanen
Guest
|
| Posted:
Tue Sep 27, 2005 12:15 am Post subject:
Re: Ethernet, Aloha and CSMA/CD - |
|
|
On Tue, 27 Sep 2005 01:15:38 +0800, prep@prep.synonet.com wrote:
| Quote: | 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 |
|
| Back to top |
|
|
Henrik Johnsson
Guest
|
| Posted:
Tue Sep 27, 2005 4:41 pm Post subject:
Re: RS485 CSMA/CD protocol |
|
|
therion <therion0@yahoo.com> wrote:
| Quote: |
"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]
| Quote: | 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.
| Quote: | Please help in that direction!
|
Even if that direction is a dead end?
/Henrik
-- |
|
| Back to top |
|
|
Ignatios Souvatzis
Guest
|
| Posted:
Tue Dec 20, 2005 4:48 pm Post subject:
Re: Ethernet, Aloha and CSMA/CD - (was: RS485 CSMA/CD protoc |
|
|
On 2005-09-23, Roberto Waltman wrote:
| Quote: | 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/ |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in