Error detection and management
Nodes that transmit messages on a CAN network will monitor the bus level to detect transmission errors, which will be globally effective. In addition, nodes receiving messages will monitor them to ensure that they have the correct format throughout, as well as recalculating the CRC to detect any transmission errors that have not previously been detected (i.e. locally effective errors). The CAN protocol also has a mechanism for detecting and shutting down defective network nodes, ensuring that they cannot continually disrupt message transmission.
When errors are detected, either by the transmitting node or a receiving node, the node that detects the error signals an error condition to all other nodes on the network by transmitting an error message frame containing a series of six consecutive bits of the dominant polarity. This triggers an error, because the bit-stuffing used by the signalling scheme means that messages should never have more than five consecutive bits with the same polarity (when bit-stuffing is employed, the transmitter inserts a bit of opposite polarity after five consecutive bits of the same polarity. The additional bits are subsequently removed by the receiver, a process known as de-stuffing). All network nodes will detect the error message and discard the offending message (or parts thereof, if the whole message has not yet been received). If the transmitting node generates or receives an error message, it will immediately thereafter attempt to retransmit the message
A CAN/CAN gateway incorporates two CAN controller with a microcontroller. CAN messages are received by a CAN controller, processed by the microcontroller and then sent by the opposite CAN controller. Processed means that messages may be filtered, remapped to different CAN identifiers or that the data content of the messages may be altered. Also different baud rates may be used on both sides.
A CAN/CAN gateway connects two CAN systems and controls the message exchange by applying rules and functions on these messages. This distinguishes the gateway from the repeater, which acts more or less like a piece of cable. This extended functionality leads to higher costs in respect to a CAN repeater.
The main issue while using a CAN/CAN gateway is the latency time for a received message to be sent out on the other side. For an idle network this time is the propagation delay of the gateway. But as soon as there is busload this time gets undetermined. This has two reasons. Even if there is only busload on the receiving side, the propagation delay increases, because the microcontroller has to spend more and more time in the CAN receive interrupt routine and a message to be sent out has to wait for the processor to have time for doing so. If there is busload on both sides, the CAN controller has to wait for an idle bus to get access to it. This time increases with the busload and depends also on the CAN identifier used due to their priority. Therefor the CAN system integrator has to take extra care on the busload, if a gateway is going to be used.
From the application point of view the implications of this issue get obvious while e.g. looking on the SYNC message of the CANopen protocol. This message is used to synchronize actions on different CANopen nodes to the moment they receive the message. If the SYNC message is delayed by an arbitrary period of time, system behavior tends to get unpredictable. Filtering, also by using the acceptance filter of the CAN controller will help, but cannot reduce the effect completely.
Due to the fact that the CAN/CAN gateway acts on messages, error frames will not be distributed from one side to the other. Furthermore CAN/CAN gateways can have the full extend of bus length on both sides for a given baud rate and the full count of modules.
The motivation to use a CAN/CAN gateway is given, if two CAN systems should be connected, but the message flow has to be controlled. In this case the system integrator benefits from the versatile functionality offered by this devices. While e. g. developing a new electronic control unit (ECU) for an automotive application, the system designer may use a CAN/CAN gateway to shift identifiers or to modify data contents of specific messages and is able by this means to combine old and new units.
A CAN/CAN gateway which routes the CAN messages over a media like an optical fiber (CG-FL, EtherCAN FX) or Ethernet (EtherCAN CI) using a protocol like TCP or UDP is called a CAN/CAN router. They extend the concept of a gateway to a larger physical expansion, but preserve the attributes of a gateway. This devices are able to realize point to point connections of CAN systems over distances up to 40km with low latencies and enable sophisticated CAN applications.
Basic functioning scheme of a CAN repeater
A CAN repeater incorporates two CAN transceiver with a glue logic. It propagates a CAN signal from one side to the other and vice versa. Therefor an ideal CAN repeater acts like a piece of cable, it is transparent for the CAN signal. Due to the propagation delay of the two CAN transceiver and the glue logic an equivalent length can be given for a specific CAN repeater. It is about 40m for a repeater without galvanic decoupling and about 60m for a device with galvanic decoupling.
The maximum length of a CAN system for a given baud rate cannot be extended by the use of a CAN repeater. But a CAN repeater allows to implement topologies different than a simple line. Stub lines or star topologies can be realized by using CAN repeaters.
If a CAN network is divided into two segments by a CAN repeater both of them must be terminated correctly with two 120R resistors at its ends. Both segments are physically independent, but form a single CAN network from the logical point of view. This means that the maximum length of a stub line is only determined by the maximum distance between two end points of the network. A CAN line, which has a stub somewhere in the middle, has three endpoints “A”, “B” and “C”. The maximum of the three distances “AB”, “AC” and “BC” is essential for determining the maximum baud rate in this specific system. It has to be noted that the equivalent cable length of the CAN repeater has to be taken into concern. For an example on this topic visit our article: CAN Repeater example
A CAN repeater can be used to regenerate the CAN signal for very long CAN lines or it can help to increase the maximum count of nodes in a CAN system. Due to the fact that a CAN repeater is transparent for the CAN signal error frames are also propagated. But a repeater may offer the functionality to disconnect a segement, which is locked to a permanent dominant state. This can help to increase the system reliability. Most of our repeaters include this feature.
Our CAN repeaters are offered with a parameter called inhibit time. It is important to choose the correct value for this parameter that the repeater will work as expected in a dedicated system. We recommend to set it to 10-20% of the bit time. More details on this subject can be found here: CAN inhibit time
The most important motivation to use a CAN repeater is to implement a network topology which is not a line. This approach can help to decrease the overall length of a CAN system. If a galvanic decoupling between two parts of a CAN network is needed, it can be realized by a galvanic decoupled CAN repeater.
A CAN repeater gives the opportunity to offer a solution to network problems, which otherwise could only be solved by higher costs or as worst case by having to use something different than CAN.
CAN & Flexray differences: