Not part of the proposal, this is just a place to dump reference information and links for CAN implementations.
11-bit standard header
29-bit extended header and 8-byte payload results in a total transmission taking about 135 bit times.
Email on wiring:
The spec for CAT5/CAT5e is less than 188ohm/km, out and back, so roughly 5.7 ohms for 200 feet. CAT5 cable meets that, the phone cable doesn't (though it's not very different). These values are _very_ far from the limits for CAN. Typically CAN is meant to work up to 100 meters with 320 ohms per km (which is what you get with AWG24 wire plus gold connectors assuming 100 nodes; less nodes means more length). There's also an outline of this calculation in the excellent Phillips app note: <http://www.nxp.com/acrobat_download/applicationnotes/AN96116.pdf> The real difference is likely to be in characteristic differential impedance, which is the much more critical parameter for cables of significant length.
The usual CAN physical layer is designed for a terminated differential impedance of about 124 ohms.
CAT5 is 100+/-5 ohms at 100MHz, somewhat above the frequency for CAN. Most (modern) phone wiring is ADSL compatible, which requires 100 ohms (with a typical tolerance of 'less than 220' ohms for typical inter-house lengths; I've never seen a lower tolerance limit, but these are phone lines with a notional audio-frequency impedance of 600 ohms so the struggle is usually on the higher end) from 26kHz to as high as possible, preferably to 1.1MHz for full DSL bandwidth. That's a lower frequency range than CAN, but for copper/poly wire the impedance isn't going to change much up to a few hundred MHz.
Connections can cause discontinuities, as can stubs to connect to individual nodes. There are several working group reports and app notes available on this. There's a particularly thorough ISO working group report, but unfortunately those are not available on the web for free AFAIK. The app note referenced above is pretty good, though (see section 6). Basically, a linear wiring system (node to node to node to node to ...) with fixed end terminators is going to be able to easily do 125kHz/100m/100nodes with either of the cables you're looking at.
On length limitations and timing, there's another app note: <http://www.nxp.com/acrobat_download/applicationnotes/AN10211_2.pdf> Table 7 is referring to what is stated by the SAE J2284 standard. That's "High Speed CAN (HSC) for Vehicle Applications at 500kbps", and it really does say 50 meters (I don't think it's freely available online, but most college MechE departments will have access). 50m is probably a little short for a model railroad bus. But for use in an automobiles and trucks, that's a very reasonable length limit, and they explicitly discuss various forms of fault-tolerance operation where short lengths help.
There is also the "thick cable" form of Device Net, which has a low DC specific cable resistance, typically about the equivalent of AWG16 wire. There's also a "thin cable" form, roughly equivalent to the 11898 CAN automotive cable or AWG23. Particularly for large numbers of nodes, these do result in different limits. The "thick cable" form typically has about a factor 3 or 4 longer DC limitation than "thin cable". But all of these are well above 100m/100nodes, even in the AWG24 form. (There's a table on page 21 of AN96116)
125Kbps with max-length extended header frames is about 900 frames/second. CAN is very good at running at 100% utilization, so long as nodes can keep up and a proper set of priorities is in place.
The EUROMAP 66-1 “Protocol for Communication with Peripheral Equipment” standard defines a CAN interface that's commonly used in shop floor automation. It uses DB9 connectors that optionally includes a 24V power line. Each device has two connectors and permanently attached terminator. The intent is to use male-female cables to connect modules together, but in practice other arrangements are also used.
|
Pin |
Use |
|---|---|
|
2 |
CAN Low |
|
3 |
CAN Ground |
|
7 |
CAN High |
|
9 |
Optional: CAN 24V power |
This connector wiring is also used for e.g. the Lawicell CAN adapters.
LocoNet cables are often “conductor swapping”. (The data leads don't care if the wires are swapped; the Rail Synch leads might if using transponding, but otherwise don't) This is a problem for using them with CAN. Otherwise, they're just nice 6-wire untwisted cables.
NCE cab and control buses won't have conductor swaps, at least not if they've been working.
The breakout panels are probably not electrically compatible with high-speed CAN.
CAN is designed to run at 100% usage without problem, and it's routine for CAN segments in other contexts to run at 100% for extended times. Therefore, the CAN network does not require any inter-frame spacing, limitations on bandwidth usage, etc; the segment can be allowed to run at 100%.
The real limitation is whether the nodes themselves can handle the full rate of frame arrival. There is (currently) no mechanism in OpenLCB to throttle the rate of frames arriving at a node, nor is it easy to create one in a CAN network. The stream and datagram protocol have been designed to allow a node to efficiently use a very limited amount of buffer memory, but don't provide mechanisms to limit the arrival of frames.
For long term reliability, a node must be able to completely process an entire CAN frame in the time it takes to receive the next one, which may be as little as 42 (?) bit times.
The CIM/RIM algorithm for finding aliases is designed to work without any CAN errors. Arbitration conflicts are OK, but deliberate errors are not, because different CAN implementations may deal with them differently. During execution of the algorithm, some frames might have the same header. They therefore have to have the same contents, or else a non-arbitration error can occur.
Although it might be a useful debugging tool, putting the full NID in the data portion of the frames can cause errors. Therefore, we decided not to do that.
“Introduction to the Controller Area Network (CAN)”, Steve Corrigan, Texas Instruments Application Report SLOA101A, August 2002, revised July 2008 (http://focus.ti.com.cn/cn/lit/an/sloa101a/sloa101a.pdf)
“Controller Area Network Physical Layer Requirements”, Steve Corrigan, Texas Instruments Application Report SLLA270, January 2008 (http://focus.ti.com/lit/an/slla270/slla270.pdf)
EUROMAP 66-1 “Protocol for Communication with Peripheral Equipment” standard
“TJA 1040 High Speed CAN Transceiver” Phillips Semiconductors Application Note AN10211 Rev 2, 10 November 2006 (http://www.nxp.com/acrobat_download/applicationnotes/AN10211_2.pdf)
“PCA82C250 / 251 CAN Transceiver” Phillips Semiconductors Application Note AN96116, 1996 (http://www.nxp.com/acrobat_download/applicationnotes/AN96116.pdf)
B. Gaujal and N. Navet, “Fault confinement mechanisms on CAN: analysis and improvements”, IEEE Transactions on Vehicular Technology, pp.1103-1113, 54(3), May 2005 (An interesting analysis of how CAN nodes react to error rates on the CAN bus by e.g. taking themselves offline, etc)
“Live Insertion With Differential Interface Products”; TI Application Report SLLA107 February 2002
“iCoupler® Isolation in CAN Bus Applications”; Analog Devices Application Note AN-770
“Improved CAN network security with TI’s SN65HVD1050 transceiver”, Steve Corrigan, Analog Applications Journal, 3Q 2006 (Discusses live insertion)
“A CAN Physical Layer Discussion”, Pat Richards, Microchip Technology note AN228 (MCP2551 discussion)
InterfaceBus.com web site page with an overview of CAN (many useful further links) and a survey of CAN connector wiring (see also the page on wiring for round connectors.
This is SVN $Revision: 743 $