can bus length limit?

There's a story about a Texas folk hero, Pecos Bill, and the timesomebody bet him he couldn't swim across the Gulf of Mexico fromGalveston, Texas to Key West, Florida. He trained for a month and whenthe big day came, he plunged into the Gulf of Mexico. Day and nightBill swam for a week, fighting sharks and hurricanes. Finally, heclosed in on his destination. However, as he saw Key West off in thedistance over the waves, he realized he was just too tired to keepgoing ” so he turned around and swam back to Texas!

Designers working with CAN communication face their own challenges, andlike Pecos Bill, the round-trip turns out to be a criticalconsideration. A key feature of the controller area network (CAN) protocol is how ithandles bus contention, when more than one node tries to transmit onthe shared bus. CAN uses bit-wise arbitration to select which nodeshould continue signaling. Since the nodes listen to each bit and mustdefer to a higher priority message, their response time must be quickenough to cease transmission before corrupting the next bit. Asillustrated in the following three cases, this imposes constraints onthe acceptable component delays and cable length, as well as the usablesignaling rate.Case 1: Normal CAN busoperation ” without contention Usually only one node at a time will try to communicate via the sharedCAN bus. Without loss of generality, we can discuss a two-node network,and extend this discussion to more nodes. Figure 1 illustrates how thisworks. At first both nodes are in the recessive state, so there is nodifferential signal applied to the bus, as in (1a). If node A begins tocommunicate, it initiates a CAN message with a dominant bit. Thetransmit data (TXD) input to the CAN transceiver is a logic zero, whichcommands the differential driver to generate a differential signal ontothe bus lines as in (1b). The receiver at node A senses thedifferential signal, and outputs a logic zero on the received data pin(RXD). The differential voltage propagates down the cable according tothe transmission line properties of the twisted pair as shown in (1c)and (1d). Eventually, the differential signal reaches node B, and thereceiver at node B also outputs a logic zero on RXD as in (1e). At thispoint, node B is aware that node A has begun a CAN message and,therefore, node B will not attempt to initiate a message until node Ais finished.

Note that node B does not immediately know that node A has started amessage, as the signal from A to B has a finite delay. The total delayin this scenario is the sum of the delay through the transceiver (andassociated isolation and buffering circuits) at A, plus thetransmission delay through the cable, plus the delay of thetransceiver, isolation and buffering circuits at B. At first glance itseems that this one-way delay is the critical timing limitation neededto ensure that node B does not conflict with messages from node A. Aswe'll see in Case 2, this is not yet the whole story.Case 2: Delayedcontention ” later message has higher priority Our next scenario (Figure 2) assumes that again node A initiates amessage, but that a higher priority message from node B is alsoinitiated a short time later. As before, the scene opens with bothnodes in recessive mode as in (2a), and then node A initiates a messageby going dominant as in (2b). Again the dominant differential voltagepropagates along the cable. Just before the signal reaches thetransceiver at B, that node happens to initiate a message with adominant bit as in (2c). At this point, both nodes are transmitting adominant bit, and both nodes are receiving a dominant bit as in (2d),but neither node is aware that the other node is active. Since in ourscenario node A has a lower priority message than node B, at some pointnode A commands a recessive bit by setting its TXD to zero as in (2e).However, the RXD senses the bus is still in a dominant state, due tothe action of node B.

By examining a specific hypothetical case with practical values fordelays, we can illustrate more concretely these timing requirements. Inour two-node example, let the total one-way delay be 200ns, and let thesignaling rate be 1Mbps, or the maximum specified by the ISO 11898-2standard. Therefore, the bit time will be 1000ns. This case proceeds asin Case 2, except that the second bit from node B will be a zero(recessive) matching the message priority from node A. (In Case 2, nodeB had a dominant second bit, indicating higher message priority.)

In Figure 3, node A begins a message at time t=0, transmitting adominant bit on the bus (b). As in Figure 2, it is possible that node Bbegins to transmit just before the signal from node A is received (c),at time t=199ns. Neither node is aware of the activity of the otheruntil node A switches to a recessive state at the beginning of itssecond bit at time t=1000ns. Node B then switches to recessive at thebeginning of its second bit at time t=1199ns. After another one-waydelay, that recessive signal reaches node A at time t=1399ns. Onlyafter that point should node A read the RXD signal and have confidencethat the true state of the network is represented.

Note that only by waiting twice the total of the one-way delays (orequivalently by waiting the total round-trip propagation time) willnode A be able to distinguish this case, where the messages from A andB have equal priority (Case 3), and where the message from B has higherpriority. Due to the bitwise arbitration scheme inherent in the CANprotocol, this round-trip delay must be well within the timing budgetof a single bit, in this case 1000ns. Otherwise, node A might begin totransmit its third bit, before the arbitration of the second bit iscomplete.Limitations on signaling rate and cable length Knowing that the round-trip delay is critical, CAN defines aprogrammable propagation delay (PROP_SEG) as part of each bit to ensurethat every node does indeed wait long enough before sampling the busdata. While beyond the scope of this paper, the calculation of PROP_SEGinvolves knowledge of the round-trip delay and of the local systemclock rate. In practice, PROP_SEG limits the sample point to about 5/6or less of the total bit time to allow for the other segments, so theround-trip delay is bounded as a fraction of the bit time.

The CAN standard specifies cable with 5ns per meter propagation delay,and a maximum cable length of 40 meters for signaling at 1Mbps. With abit time of 1000ns, the latest possible sample point (set by PROP_SEG)is about 850ns. The cable itself has a 200ns one-way delay (or 400nsround-trip), leaving only about 450ns for the total delay contributionsof the transceivers and associated circuits.

Manufacturers of CAN transceivers often specify “loop delays,” whichinclude both driver and receiver delays. Since two transceivers areinvolved in the round-trip calculation, each should have a loop delayof 225ns or less to support a bus length of 40 meters with 1Mbpssignaling. If additional components are part of the transceivercircuits such as isolation, voltage level shifting or protectionelements, the delay these cause must also be included in the totaldelay budget. Even high-speed optocouplers typically have one-waydelays of 40ns or more, and the total round-trip signal must go throughfour optocouplers. This significantly reduces the allowable cablelength (or increase the bit time) for CAN systems using opto-isolation.For the 1Mbps situation, even the delays for fast optocouplers willreduce the allowable cable length by Equation 1:

An integrated SiO2 isolation with a high-speed CAN transceiver in asingle package (ISO1050) is now on the market. With a worst-case totalloop delay of less than 210ns (including driver, receiver and twoisolation channels!), you can reduce the total round-trip loop delayand simplify your system timing and design for isolated CAN solutions.You can also perform a level-shifting function, translating voltagesfrom a 3.3V controller to the 5V CAN transceiver, without additionaldelay.

Of course, there are other considerations when designing for optimizedperformance in terms of signaling rate and cable length. Thetransmission line effects of the network imply that loading,node-to-node spacing and stub length are important to the signalfidelity and noise immunity of the system. A good reference islisted at the end of this paper.Example with lab data In order to demonstrate these concepts, a lab set-up with two isolatedCAN nodes and 50 meters of cable can be instrumented. We expect a cabledelay of 250ns in each direction, and isolated transceiver loop delaysof about 150ns, typical of the ISO1050. So the sample point at node Ashould be about 800ns after the start of the bit, as shown in theFigure 5.

Summary Designers are using CAN communications in a variety of applications,and need to understand the timing constraints and cable lengthtradeoffs. Each component in the signal chain contributes to the totaltiming budget, and the round-trip delay must be considered to ensurereliable communication. Using fast transceivers like the ISO1050 ensurethat the CAN signals make the round-trip journey in time, even fasterthan Pecos Bill can swim the Gulf of Mexico.

Reference  For more information on interface solutions, visit:www.ti.com/interface-ca.

About the Author Clark Kinnaird is asystems engineer at Texas Instruments where hedevelops new industrial interface products that involve specificationsand application support for RS-422, RS-485, CAN, ControlNet, Profibusand other common industrial networks. He received his PhD EE from SMU,an MSE EE from the University of Florida and a BS in NuclearEngineering from the University of Florida. Currently, Clark is also anadjunct Associate Professor of EE at SMU in Dallas, teaching courses inelectronic circuits, signal processing and control theory. Clark can bereached at: .

The specification requires that the total length of a CAN bus, including all stubs, should not exceed 131 feet. Additionally, the specification recommends limiting the number of devices connected to a single CAN bus segment to less than or equal to 32.

'mb' Moshe Barazani: According to the DS303-1 and the Bosch protocol and ISO 11898, the 1Mbit should be supported for bus length of 30meters. Practically we could reach not more than 10meters. This also stands with some notes that I could locate on the web.

Does anyone have any experience to share in such architecture? Did you use “Repeaters” to extend the bus length? Any suggestion in how can a bus be lengthen to 30meters? Any idea what were the different standrad calculations when allowing 30-40 meters?

'oe:' Did you have done any calculations of your overall signal propagation, e.g. adding all relevant delay times transceiver - opto coupler - cable - opto coupler - transceiver ??

As you already said, having all bad components, you will not reach 30m, in the worst case your calculation will end up with a length of minus some meters.

Repeaters will not extend cable length when you stay with 1Mbit/s. They will add additional delay.

'sc' Steve Corrigan: A 30 meter bus should not be a problem with a 1 Mbps signaling rate as long as the cable is at the very least 120ohm CAT 5 twisted-pair cable. Shielded is even better. 5ns per meter propagation delay is typical for this cable. The down and back max prop delay is then 400ns. Then, if you add a 150ns total loop delay for a sending transceiver and another 150ns for the most distant receiving transceiver (in this case HVD251s), then the total prop delay from controller to controller is now around 700ns. Easily enough time for a correct sampling point. I have operated at 1Mbps on 40m without any problems at all. This is, by the way, the maximum bus length specified by ISO 11898 (1993).

Problems you may be having

40m at 1Mbps on a standard bus is no trick at all, so something is not electrically correct with your bus arrangement. This is how your bus should be set up for high-speed operation.

'sc:' Stubs too close together increase the capacitive effects of each – they become a lump sum and damp the effective signaling rate. What isolators are you using? If they're optos you may want to switch to another part like ADI's ADuM1100.

'ob' Oliver Betz: is it a must to use isolation, or to use a (maybe specific) optocoupler? TI's parts are much faster, consume less power and cost less than fast optocouplers.

'mb:' taking the worst case scenario according to the manufacturer you might end up with cable with minus length. The problem is that you cannot get the typical values of the delay and not even some statistics of “how many components might get to the max delay out of 1000”

'ob:' with fast couplers and transceivers I see no problem to make a 100% design. ADuM1100 has typ. 10.5 and max. 18ns prop. delay. HCPLx710 typ. 20ns, max. 40ns. Two times transceiver delay (each 120ns..175ns). Still enough room for several meters of cable. Regarding the probability: comparing the “worst case” and the “typical” values gives an idea about the distribution. A rectangular distribution would be a rather pessimistic but still acceptable assumption. After all, I wonder in which case there could be a real need for galvanic isolation of such a small bus - different, distant power sources?

AFAIK galvanic isolation suppresses only low frequency noise, RF can be filtered better and cheaper. Oliver

Heikki Saha, explains propagation delay, 2013-10-18: Propagation delay consists of:

Some example values:

⇒ Basic implementation without isolation and logic, we get: