Chapter 14 - CAN BUS

Now that Annex32 includes CAN bus functionality, what is it, and what might we use it for ?

CAN (Controller Area Network) is a protocol for reliably broadcasting short bursts of structured numerical data to all nodes on the CAN bus.

Messages start with an 11 bit destination node ID number (giving from 0 to 2047), which is only an arbitrary assigned number that the appropriate designated receiving nodes must watch out for in the broadcasted messages and respond to if recognised.

Messages addressed to lower ID numbers take priority over messages to higher numbers, so ID=0 is king of the bus, whereas ID=2047 is at the bottom of the pecking order.

Data is very structured, with messages normally consisting of between 1 and 8 bytes of data ordered specifically for how the destination is expecting it.

A vehicle ECU could be reading a cam sensor and transmitting frequent updates to the dashboard console for it to smoothly and responsively process as a rev counter display.

A BME180 node might be sending temperature, humidity and pressure values for a weather station node to receive and process the expected data in a specific order.

Analog data would be converted into digital and could be sent as a single byte 8 bit value (0 to 255), or larger numbers would be sent with hi and lo bytes if necessary.

What gives CAN bus its big advantage over point-2-point wiring is the number of devices that can reliably exchange data on just a single low-current pair of wires.

A control panel with dozens of switches and indicators just needs a single CAN bus pair of thin data wires to exchange data between multiple sources and destinations.

The CAN bus is so cheap and reliable to implement that systems may have dozens of different CAN bus's (some cars have over 70) each for specific roles, for instance it would make sense for an autonomous vehicle to use a different CAN bus for its entertainment system from those it uses for its LIDAR sensors and vehicle control systems

The CAN BUS uses 2 wires as a differential pair, which either have a potential difference between them (logical 0), or are both at the same potential (logical 1).

The pair of wires may be twisted together to cancel out induced noise from spark sources such as motors, arc welders, lightning storms etc, thereby improving reliability.

UTP network cables uses twisted pairs to achieve high speed (up to 1000Kbs) sustained data rates over distances up to 100meters, making it also suitable for a CAN bus.

Speed and distance are a tradeoff - cars typically use 'fast' CAN at 500Kbs, but CAN also caters for slower bus speeds to achieve greater distances of hundreds of meters.

The 2 CAN bus wires are designated CANH(igh) and CANL(ow) and connected together by 120 ohm termination resistors at their ends (giving 60 ohms total bus resistance).

The termination resistors are always trying to pull the CANH and CANL wires to the same potential (which is about 2.5v above 0v).

This default passive equalised condition of no potential voltage difference between CANH and CANL is called the 'recessive' state and represents a CAN logical 1.

CAN logical 0 is called the 'dominant' state and is caused by a node actively driving CANH towards 3.5v and CANL towards 1.5v creating a potential difference of about 2v.

Therefore the active CAN logical 0 will always dominate a passive CAN logical 1, because any node can apply an active voltage between CANH and CANL to create a logical 0, but a logical 1 is only attained by no node sending a logical 0 for long enough to allow the termination resistors to drain away the potential difference to achieve logical 1.

The ability for a CAN logical 0 to always dominate and take priority over a CAN logical 1 is used very effectively for message collision detection and arbitration.

The reason a rudimentary pair of wires with only one active logical state can achieve fast reliable data transfers is mainly due to the sophistication of the CAN transceivers.

The pair of CAN wires does not have a separate clock like SPI or I2C etc, so the transceiver must manage the pulse timings according to the CAN bus speed configuration.

CAN transceivers have separate transmitters and receivers, so they have the important ability to monitor the actual state of the bus even as they transmit a message.

Nodes will look for an adequate passive duration of logical 1 inactivity before attempting to send a message by first sending a 'start' bit, followed by the 11 bit destination ID.

If more than one node starts to send a message, eventually one of their destination ID address bits will be a recessive logical 1 while the other will be a dominant logical 0.

The node that has tried to send the recessive logical 1 will read that the bus is in the active logical 0 state caused by another node, so it will stop sending, thereby allowing the dominant message to continue unhindered. As well as message collision detection and arbitration, CAN transceivers have ability for hand-shaking and error-correction.

And it obviously all works remarkably well, because CAN literally now controls our daily lives - it has become an essential part of transport and industry and military and all the infrastructures on which we depend, including hospitals, supermarkets, nuclear power, water, sanitation, traffic control, trains, planes, space, ships, cars, trucks, buses, agricultural machinery, production lines, autonomous vehicles of every type, and almost any other complex technical systems.

An important factor of CAN performance are the 120 ohm termination resistors at each end of the CAN bus, which can be likened to doors with damped automatic closers.

The doors can be opened as fast as you like, but they can only close automatically at their own speed which is governed by the hydraulic damper, (ie:termination resistors).

Adding more self-closing mechanisms to a door might make it close faster, but it would require more power to force open and take longer.

Likewise if additional termination resistors are added in parallel other than just at the CAN bus ends it will reduce the overall nominal bus resistance to less than 60 ohms.

Many CAN transceiver modules have 121 ohm termination resistors soldered to the pcb without any convenient way to disconnect - they are ok to use at the ends of the bus, but if they are intended for intermediate locations then the termination resistors should be removed to avoid reducing CAN bus resistance and degrading performance.

The Annex32 implementation of CAN has the great advantage of remote wifi connectivity,and of course Rapid Development, plus easy SD card for data storage if needed.

So it should make a great OBD2 CAN bus sniffer (a future project I am looking forward to).

It offers ability to interact with existing vehicles eg: for adding additional equipment, but also offers ability to add a new CAN bus to vehicles, eg: for camper interior lighting.

Unless used as a data sniffer, the very nature of CAN bus means it will be connecting at least 2 devices, possibly many more... so it opens the door for more complex fast interactive systems without wifi distance and reliability limitations or vulnerability (eg: it would be good for connecting distributed security sensors).

Despite the fact that CAN is for sending and receiving numerical data, it could actually be used to exchange variable-length text strings if needed (see a subsequent example).

This offers ability for a CAN node to interact with UDP messages - eg: a CAN PIR sensor node might send "Announce Speak Gate 1 triggered" to my EasyNet 'Sentry' alarm.

In my case my EasyNet nodes also have ability to address messages to the node byte of the IP address, which could be used as the CAN ID - but It is entirely up to the listening nodes to respond to whatever they are told (as with UDP nodes), so the destination ID could actually be a nodename$ using ASCII codes if wished.