The physical layout of the CAN network is a tradeoff between communication speed, effective bus (trunk) length and stub-length. An individual bit takes a finite amount of time to travel from one end to the other end. And all nodes must be able so see each individual bit before it's transmitter has moved to the next bit. Hence, with long bit-time (low speed), the bit can travel much further than with a short bit-time (high speed):
|Maximum trunk length||25m||100m||500m||1km||5km|
|Maximum drop length (cumulative)||1.5m (7.5m)||5.5m (27.5m)||22m (110m)||55m (275m)||275m (1375m)|
|Max number of nodes||~120|
|Message capacity (2-byte)||10000/s||5000/s||1250/s||500/s||100/s|
|Message capacity (8-byte)||5500/s||2750/s||680/s||275/s||55/s|
|Update of 50kB firmware||<1s||~2s||~7s||~16s||~80s|
* Message capacity based on 70% bus utilisation while firmware update duration is based on 99% bus utilisation.
In a typical system with low power requirements, the power supply for the nodes is also provided via the bus cable. Our standard gateway provides a protected power pass-through for 24V nominal at up to 2A.
The gateway received data from the devices on the CAN-bus and deals with this data according the needs of the system. It can be written to logfiles, presented via a webserver, or send over the network using techniques like JSON.
Additionally, this gateway is responsible for keeping the devices up and running with the latest available firmware and settings. Typically, the firmware images are stored on the gateway via FTP or directly via SD card or USB flashdrive. But we could also have the gateway to retrieve updates automatically.
Arduino demontration device:
For evaluation purposes, we designed a node around the well-known Arduino® UNO design. 'Our' STM32F103 processor deals with the CAN-bus and interfaces with the Arduino-compatible ATmega328 microcontroller using the SPI bus or the standard serial port. Programming of the Arduino is also managed via the CAN-bus by assigning a firmware file to a specific node.
Our implementation of the CAN-bus consists of a proprietary communications layer on top of standard 11-bit CAN, or 29-bit CAN for encrypted messages. We have extended the standard CAN functionality with node identification, firmware update capability, file transfer, bus conflict detection and watchdog features.
If desired, an encryption mechanism is available on the CAN-bus communication using the Rabbit stream cipher. Encryption prevents eaves-dropping of potential valuable data, or worse, injection of fake data.