At the NMRA 2010 meeting in Milwaukee, it was tentatively agreed to work toward a “common platform” definition that manufacturers could use to create boards with reduced uncertainty as to whether they'd be usable in the future. This resulted in a proposed NMRA 9.x.1 Standard and Technical Note, that was presented to the NMRA in October, 2010. The NMRA decided to reject in favor of unauthorized modified version in February, 2010. The resulting controversy may have been resolved at the July 2011 NMRA convention. For more information on this "standards process", see the OpenLCB page on NMRA standards.
This page provided some background information during that discussion.
All groups have chosen Controller Area Network (CAN, reference e.g. ISO 11898-2:2003) at 125kbps as a communications fabric. This rate was generally chosen to be 125kbps to balance length and loading (see the CAN background document).
A common platform standard should require support for that, including proper slew-rate limitation.
The rise/fall time of CAN signals is a controllable parameter. The MCP2551 transceiver part used in e.g. MERG CBUS controls this with an Rs external resistor, by default a zero-Ohm jumper. According to Figure 1-1 of the MCP2551 datasheet, this corresponds to a slope of above 25V/usec. Mike Bolton recommended in September 2009 that future designs use a 100k resistor instead to give a better waveform shape at 125kbps by limiting the slope to just under 5V/usec. This effects the maximum possible stub connection length, see SLLA270 page 9. We agree with this decision. That should be part of the final OpenLCB-CAN specification, along with suitable +/- limits on the quantity.
CAN requires cable termination, but there doesn't seem to be a need to require any particular kind of termination beyond considering it when deciding on connectors.
CAN does not specify cabling, connectors, grounding nor power. The first three are so intimately connected that we consider them together below, followed by power considerations.
Full length CAN runs require twisted pair cabling. At all lengths, the polarity matters.
CBUS uses a wiring recommendation, instead of specifying a connector. The 2009 CBUS cards use a captive-screw connector, allowing connection of CANH/CANL, ground, and several different power voltages. A recommendation is emerging to use the center pair of CAT5 cable (blue for CANH, white/blue for CANL). Ground is generally needed to avoid excessive common-mode voltage.
LEDuino rev B/C has a 4 pin header, carrying +5V, CanH, CanL, Ground (later versions might change this).
The polarity requirement immediately rules out the use of the flat telephone cables commonly found in existing layout control buses: Flat telephone cable isn't twisted, and can be either cross-over or straight-through (which causes much confusion due to different requirements of different DCC vendors). Use of RJ25/RJ14/RJ11 plugs makes it much too easy to use those kinds of cables, which rules out those plugs.
There seem to be two primary approaches to wiring:
Model railroaders are generally used to connecting wires with terminal strips, and a 3-wire or 4-wire (see power section) terminal block on the board could be used for CAN.
To get long CAN buses, though, twisted pair wiring with the proper impedance must be used, and that is not always available in bulk at the local store. Hand-twisted wire is very unlikely to be the proper impedance, which will reduce the length and number of nodes which work reliably. And the connectors are certainly not the proper impedance, which means that each node has a larger impact on the bus & reduces the number of nodes that can work reliably.
RJ45 connectors and twisted pair cables are another choice. These are sometimes called “Ethernet”, “Cat-5” or other names; CAN only needs Cat-3, so we'll call these “Ethernet cables” here.
Ethernet cables and connectors have the proper impedance and minimal loss for both the cable and connectors. They are the best way to ensure that model railroaders routinely can build full-length CAN buses.
Pre-made “Ethernet” cables are quite cheap. Five foot ones are now available in single quantity for less than $1.50; 25 foot ones for less than $5 in single quantity. The board connectors are about $0.70 each, which does add some cost, but must be compared to cost of other connectors.
On the other hand, adding connectors to Ethernet cable (e.g. making your own from bulk cable) requires special tools and some skill. It's easy to mess that up.
RJ45 jacks can carry four pair (usually orange, blue, green and brown; there are two common ways of connecting wires to pins). Many cheap Ethernet cables contain only the green and orange pairs, connected to pins 1,2 and 3,6 (with two different color codes). The CBUS choice of the blue (center) pair makes it difficult to combine a “RJ45” and “terminal block” recommendation, as not all Ethernet cables contain it. The existance of two different color codes in the cables also adds confusion, because a decision to use a specific pair (e.g. 1,2 or 3,6) might result in either green or orange being the right colors at the other end.
Long CAN buses require that boards have some common system ground, at least for the CAN receivers, to avoid excessive common mode. It seems most reliable to carry that in the CAN cable as a 3rd conductor.
(Should say some words about isolating that ground from other parts of the system, e.g. the use of isolation in the CAN receivers?)
CAN isolation generally requires power in the CAN bus. It's also convenient to carry board power, if not load power, in the cable. Doing this in a standard requires specifying a voltage range, and a current limit, in terms that are useful to a model railroader.
CAT5e connectors are limited to 1.5A (some are 1A), but the 24ga wire is the bigger problem for power distribution as it's 0.0480 ohms per foot, or 1 volt drop per 20 feet (one way) at 1A. Use three wires ground, three wires power to reduce drop? On board power convertors from a higher AC voltage?
Boards should have a bootloader so that users can load new code without custom hardware tools. This might be either over a USB connection (if the board has one; it's not required that the board does) or over CAN. Since different CPU vendors are likely to provide different boot-loaders, there's little point in trying to define a common one. It would be good if CAN-based boot-loaders could be used without uncabling the board, either by use of jumpers or some form of addressing (button push?) and non-interfering CAN frames (standard header?).
There are too many CPU families and specific chips out there to say anything specific about memory sizes and CPU speeds. It wouldn't hurt to remind manufacturers that a few pennies spent on either a CPU socket or extra flash/RAM/EEPROM may extend the useful live of the product.
Different proposals have different basic I/O needs. For example, it would be better to have two LEDs and two buttons (plus reset) for OpenLCB, while CBUS would prefer one button (reset?) and an 8-wide DIP switch. (Have S9.5 schematics been posted anywhere?) Could a least common denominator approach work here, with boards recommended to have all these patterned on the board, and selectively stuffed as needed? Or is that just trying to be too tricky?
Wiring and connectors interacts with how many boards you can have, total length, etc. A key part of this is setting user expectations. This section is about what are reasonable expectations to set.
Subject: Electrical properties (was Re: [mergcbus] Re: New 12V CBUS modules
My experience in this area is mostly from trying to make large, long 250kbps CAN backbones reliable for the ad-hoc assemblies we use for physics experiments. What usually happens is that bus works with decreasing noise margin until "one last thing" is added, at which point it's no longer working well at all. Sometimes, that happens when somebody attempts to length the bus to reach "just one last crate", sometimes it happens when "just one last board" is inserted into the middle.
There's a triple trade-off with CAN, once rate & transceiver properties are selected: You can have a lot of nodes, or you can cover a long distance, or you can have useful stubs & close nodes. You can even (sometimes) have two of those. But you can't max out all three of those at once.
In particular, if you have a long bus, the arrangement of distant nodes (node capacitance, stubs, spacing) as well as cable properties will be significant. If you want to get to 500m length (c.f. http://www.merg.org.uk/resources/lcb.html), then you're dealing with a round-trip propagation time of 5.6usec with high-quality cable (even more with "I twist it myself" stuff). That's comparable to the 125kHz settle time of 8-1.2 = 6.8usec. That means that the bus is using "initial wave signaling", because there's no time for the transmitter to interact with the reflected wave and get that back to the receiver. And that, in turn, means that near-by impedance mismatches at the remote end can matter a lot.
For short networks, this doesn't matter. Nor does it usually matter when the only communications are between near-by nodes on long networks (you can get spurious errors there, but they're usually easy to track down). But I think it'll matter a lot if you e.g. have a bunch of nodes at one spot, and then run a long cable around with some stubs on it for throttles to plug in.
How short is short? How many is many? Based on the rules of thumb at LBNL/SLAC, which in turn came from much experience, 100 m / 25 nodes / no stubs over 3m / no cables under 1m works reliably. (Since that is 250kpbs, you could probably add a general factor of two to the length (200m), and perhaps to stub length.) We've relaxed every one of those limits by as much as a factor of two, but only one at a time, and often with difficulty. We too-often ran into trouble when pushing more than that, to the point that we don't intentionally do it anymore. For example, trying to run a single CAN link between two rack groups 50m apart (probably 60m of cable), with 11 closely-spaced (1ft) nodes in a group at one end and 13 in a group at the other, was a complete failure until we put 1m cables between the nodes: they could talk to their neighbors, but not to the remote end. In that case, lowering the rate to 125kbps actually made the problem worse. The eye scope showed that the composite reflection was huge mess, so big it resulted in false rejections of frames.
Because getting the very most out of CAN is complicated, it's hard to know how to set user expectations. Simple ones like "allows lengths of up to 500 metres", "Currently available transceivers set a limit to the number of nodes on a bus segment to 110" and "used spurs of 3m for the CABs and various bits of wire for the bus with no problem" are all certainly true. But they're certainly _not_ all true at the same time.
It's up to other people than me to set user expectations for CBUS, but one simple method that might be considered is:
*) Total cable length of 400m
*) Stubs count double in the total
*) Nodes count as 3m in the total (depends on connector capacitance, etc)
*) Never less than 0.5m between nodes, nor between a stub connection and a node.
(Depending on connectors in use for throttle jacks, you might want to space & count them too, as they carry some capacitance)
This is a little conservative, but since model railroaders tend to just expand things until they fail, that's not a bad position to be in.
In any case, my original post was just to mention that, in addition to total cable length, total node count, and transmission effects of stubs, the impedance effects of short interconnects is something to keep an eye on. People can do with that as they will.
Bob
(The above email didn't discuss connectors; the LBL/SLAC experience is with DeviceNet “thin round” cabling and mini connectors, e.g. really solid impedance and contact resistance control.
http://www.odva.org/Portals/0/Library/CIPConf_AGM/ODVA_12_AGM_New_LowCost_DNet_Media_Lounsbury.pdf
et al)
Site hosted by
This is SVN $Revision: 1474 $