I'm starting a home-automation project. At the beginning the data exchanged on the bus will be very small, because just a small amount of nodes will be implemented. But I want to make a decision that will be future-proof. I don't know what will be the progress of the project (maybe I will want to integrate other home-networks).
At the moment, CAN or RS485 should be enough, but I don't need the extra features of CAN (low latency and predictability). If an Ethernet node cost the same of a CAN/RS485 node, why not Ethernet? This is my doubt where this question arose.
Can you beleieve it, some can indeed still be bought...
formatting link
I checked because of your post (well I still have some devices working with that one here, I did the Ethernet design on the Nukeman back in 1993... an NSC Sonic and a DP8392 PHY so I guess I have some sort of a soft spot).
number of nodes is about 10, but I want to have a flexible architecture that could increase in the future.
the developer: framing, multi-master, addressing, conflicts, ...
With CAN you can run up to 500 kbit/s.
For such distances, you might consider optoisolation, if the devices are powered from different distribution panels.
CAN also has lossless arbitration, the higher priority message gets true immediately, the other is sent immediately after the first. A collision in Ethernet will force retransmission of both packets after random latencies.
Unless you have some rigid high level protocol between masters, "multi-master" sounds like a lot of collisions :-)
CAN is much cheaper to implement than Ethernet. The hardware is cheaper
- a Cortex-M3 with CAN controller will be cheaper than one with an Ethernet MAC, and a CAN driver is cheaper than an Ethernet PHY. With Ethernet you need magnetics and an RJ-45 connector - for CAN you can use whatever type of connector you want. Even if you want to follow the suggestion about using optical isolation for the long lines, CAN will still be cheaper in hardware.
And for CAN, you can connect nodes by attaching them directly to the bus
- no need for switches.
The electronics design is easier with CAN - you have two lines from the microcontroller going to an 8-pin driver chip and two lines to your connector (plus common ground), with all the lines at 1 MHz max. With Ethernet you have a dozen or so lines between the MAC and the PHY at 25 MHz, and 4 lines from the PHY through the magnetics to the connector at
100 MHz.
And of course the software is /much/ easier when using CAN (unless you are trying to follow a standard such as CANOpen or DeviceNet - don't go there unless it is a specific requirement for the project).
From what I understand of your project, CAN is /definitely/ the best choice.
No, I don't have numbers - and it's been a while since I have viewed a CAN bus on a scope. But I remember a distinct difference in the edge rates.
For some rough numbers, high quality twisted pair (Cat 5 Ethernet) is about 50 pF/m, so at 30 m that is 1.5 nF. With 55 ohm termination, that's an RC-constant of around 80 ns. If we assume one RC time is good enough for a solid transition, that's still 8% of your 1 Mbit time slot. Add in the propagation delay on the cable, extra capacitance for the nodes, and greater impedance on typical CAN cables (compared to Cat 5), and you can see why it is this transition that is often the limiting factor in speed*length for a CAN bus.
With CAN at 1 Mbps, 30 m is the limit for a reliable bus (depending on the number of nodes and the cable type, of course). With RS-485, where both transitions are driving, 500 m should not be a problem at 1 Mbps.
What we don't know about the OP's application is how sophisticated the transmission scheme at the application level needs to be. I am biased to J1939 CAN, but you can't exactly do FTP over can ... easily.
You can use raw Ethernet, but it many ways it ends up being more work than raw ethernet. There are all tons of tools you can use to test and troubleshoot UDP/IP stuff. You'll have nothing if you go with raw Ethernet. If you ever want any sort of Windows or Linux programs to talk to these widgets, you'll regret doing raw Ethernet.
--
Grant Edwards grant.b.edwards Yow! How do I get HOME?
at
gmail.com
IP and UDP are significantly more work than raw Ethernet. They may be relatively simple, especially compared to TCP, but there are a lot of details to get right. Typically you handle this by using a third-party stack (LWIP being a common choice). And unless you find ready-made code for your particular choice of microcontroller, you still need to make a driver to get packets in and out of your MAC.
With raw Ethernet, this driver is /all/ that you need. You give the Ethernet MAC your source MAC address. You send packets of data to a specific known MAC address or to the broadcast address. You receive packets from others that are either to your own address, or broadcasts. It's that simple. The MAC handles collisions, retries, framing, and (typically) basic checksumming.
If you want to monitor your data, stick Wireshark on the network (as always with Wireshark, you need to use a switch with mirroring on a port, or find a good old fashioned hub rather than a switch).
If you want to write PC code to communicate with your system, it's easy with Linux - just open a raw socket and away you go. You can happily use languages like Python for this to do it quickly and simply. With Windows, life is more complicated - but it is still possible.
Raw Ethernet is faster, more predictable and has lower overheads than IP
- even UDP. That is why it is used for protocols like ATA over Ethernet.
What you can't do, of course, is use standard programs that work with UDP, TCP/IP, or other IP-based protocols. You can't use a DHCP server to organise your network, or ftp to update software, or telnet to test your application.
Having said that, I have no doubts that CAN is a better choice in this particular application (based on the info we have been given so far, of course).
You've always got to run those programs as root, which gets rather old after a while.
I know. I was the one who added raw socket support to Python because I had to deal with the headache of troubleshooting stuff that uses raw Ethernet. :)
From what I've gathered it's rather painful and is difficult to make work across different windows versions.
It does eliminate the overhead of address resolution using ARP. The overhead due to UDP and IP is pretty small.
If you're using UDP/IP then DHCP is nice, and so is tftp for firmware updates. All that "nice" stuff does start to add up. OTOH, writing equivalent functionaly for raw Ethernet also takes a bit of work.
I'd have to agree with that. It looked to me like he was going to have to put a 3-port Ethernet switch in every one of his widgets so he could daisy-chain them (unless he can live with a star topology with a switch at the center). The 10base2 thinnet solution using 50 Ohm coax and BNC "T" connectors would be cute, but good luck getting parts. Can you even buy PHY chips and magnetics for 10base2 these days?
CAN is dead simple as long as you don't try to do something like DeviceNet or its brethren.
--
Grant Edwards grant.b.edwards Yow! I'm a fuschia bowling
at ball somewhere in Brittany
gmail.com
Or manage it (a simple SNMP server is easy), or monitor it (ICMP), or let it set its clock accurately, or...
And inevitably someone is going to want to access the widget from across a router...
The packet headers are trivial, and the difficulty of implementing ARP and DHCP (and possibly auto-config for the no-DHCP scenario) is darn small given the benefits. In most cases, of course.
The RS-485 specifies 100 kbit/s at 4000 ft, thus 115k2 at 1 km should be OK, But 1 Mbit/s at 500 m really ? Do you have a reference ?
The reason for the quite limited range with CAN such as 250 kbit/s at
250 m is mainly due to the propagation delay issue.
For proper arbitration, the total propagation delay must be less than
1/10 bit time, thus limiting the network size.
To create larger networks, you need to create smaller networks with gateway stations in each network. The distance between each gateway can be huge (even satellite links), but each gateway performs the normal CAN arbitration within that CAN subnet as would any true Ethernet switch would do.
I didn't think about that - I've only used such programs during testing, and it's not a big problem to use root on a development machine. But I agree that using root for something you run often is not nice - even with setuid or CAP_NET_RAW (if I've got that one right).
Well, I owe you my thanks here. It made some development work I did much easier.
I haven't used raw Ethernet much in practice - I only used it as a stepping stone to getting LWIP working on an MPC microcontroller. But it was easy to set up, and easy to work with on the PC (using Python, as root...), and let me troubleshoot my MAC setup.
I believe the common method is to use WinPCap - the library that Wireshark uses. But I'd hate to have to try to get something like that working on the latest "telephone" windows!
Basically, I think that if you are communicating over Ethernet with a PC (Windows, Linux, whatever) or other standard equipment, then IP with UDP and/or TCP is definitely the right choice. But raw Ethernet is quite a realistic option for a closed network between nodes that you have full control over, and the low and predictable latencies can fit far better in many industrial applications than UDP.
I don't think coax Ethernet used magnetics - it certainly did not have good isolation. I remember getting buzzed when connecting coax Ethernet cables to computers on different mains circuits.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
Timing Diagram Font
GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
For those web sites you hate
I ran a quick google, and found a useful note from Maxim:
They show 1 Mbps at 500 m for a "conventional" RS-485 driver, and double that for more powerful drivers with pre-emphasis.
Remember, the standards say one thing - but the chip manufacturers go above and beyond that in search of a sale. I doubt if the RS-485 standard talks about 52 Mbps rates supported by current high-speed drivers.
My understanding was that you had closer to 1/2 bit time for stabilisation - the bus needs to be stable by the time you get the bit sample point. But certainly the propagation delay is a key factor here, whatever the fraction of the bit time you need.
I don't really have the numbers to argue more about whether it is the dominant-to-recessive transition or the propagation delay that is the final limiting factor, or how much that depends on the bus load, cable type, etc. When you have many nodes, I expect that the termination will be a bigger factor (due to the higher capacitance), while on longer lines or special cables (such as fibre), the propagation delay will be the biggest factor.
It is sometimes possible to cheat - I have run CAN buses longer and faster than theoretically possible, but with very specific situations. There were only two nodes, one at each end of the bus, and there was never any arbitration when both nodes wanted to send at the same time.
Oh it certainly did, those I used came in a DIP-14 (16?). Then the PHY was behind the transformer so it took also a DC-DC convertor to power the DP8392 (-9V).
10base2 does use magnetics and is isolated. On problem with that is that the entire network cable is floating and can get statically charged, that can zap you. I don't recall if there where cards with bleed resistors, but each card had some over voltage protection device over the magnetics, somewhere in the region of 1500V. And if I think about it, I seem to remember termination resistors with a little metal chain to ground your cable at one end. But that memory is a bit vague. ;-)
That chain could explain your experience: If the cable was grounded somehere remote and you'd touch the cable BNC and the PC case, you could have a potential difference. You would not notice this if you touched only the BNC connector on the PC, as this was isolated.
Main cause for voltage on a PC case are ungrounded PC's in my experience, not difference between mains circuits (they must be quite substantial for you to feel them). The case of ungrounded PC's is at half the mains voltage due to the capacitive voltage divider in the mains filter.
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
Populus vult decipi.
[The people like to be deceived.]
again: It's a transmission line, the RC time constant doesn't matter!
formatting link
A wave travels along the line, we don't calculate with lumped capacitance or inductance.
BTW: The termination is likely not 55 Ohms, a typical Ethernet TP cable has 100 Ohms impedance. CAN cables rather 120 Ohms.
50pF/m and 100 Ohms Z results in 500nH/m inductance, 2E6m/s (0,67c).
The driver should see a resistive 50 Ohms load (two directions 100 Ohms), no capacitance, no inductance, as long as the cable is terminated with it's characteristic impedance.
Losses in the dielectric and resistive losses distort and damp the signal, but that's much less an effect than the cable capacitange times the termination resistance.
[...]
That's a CAN specific issue - the round trip time including transceiver (and maybe isolation couplery) delay must be shorter than a bit time to enable the non-destructive bitwise arbitration.
UART signalling over CAN transceivers can run also at 1MBit/s for much more than 30m.
Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
It did, but in my experience it was almost never used correctly. Most commonly, neither end got grounded, second place went to the folks who grounded *both* ends. It was rare to see a corrected 10base2 segment. And if you had a properly grounded segment, that would usually get "fixed" in fairly short order, as the ground connection was invariably in someone's way...
To this day I'm still surprised that Ethernet survived the 10base2 debacle.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.