CAN-bus properties:
The physical layout of the CAN network is a trade-off 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):
| Nominal speed | 1Mbps | 500kbps | 125kbps | 50kbps | 10kbps |
|---|---|---|---|---|---|
| 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.
Master/Gateway:
The gateway receives 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.
- Firmware locked to CPU signature, accepts only encrypted firmware image matching the bootloader ID
- Lots of local intelligence capabilities
- Optional local user interfaces such as buttons & displays
- Networking via ethernet, Wifi, 3G/LTE or optional XBee®-style modules
- Supports HTTP, Telnet, FTP, uPnP, NetBios, SNTP, SNMP, JSON, MQTT and raw TCP network services
- Data reporting triggered by various events; geofence, G-force (shock), inputs, periodic, etc
- USB Host flashdisk support for firmware & configuration updates and easy dumping of logfiles
Field devices:
The business end of the devices is entirely dependent on your requirements and involves normal R&D activities for electronics design, PCB layout, enclosure solutions, etc.
- Firmware locked to CPU signature, accepts only encrypted firmware matching the bootloader/hardware ID
- Local intelligence capabilities
- Self learning CAN-bus bitrate 'AutoBaud' allows for easy adjustment of bus speed
- Optional local user interfaces such as buttons & displays
Protocol extensions:
Our implementation of the CAN-bus grew from a proprietary communications layer on top of standard 11-bit CAN to a CANopen® compliant network implementation. We have extended the standard CAN functionality with node identification, firmware update capability, file transfer, bus conflict detection and watchdog features.
Compatibility:
After a few years of development, our CAN solution became very similar to the CANopen® standard. With the ascent of our product line of general purpose CAN-bus nodes, we decided to move to CANopen® altogether.
Encryption:
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. Encryption is useful for hack-sensitive systems or for subscription based deployments, where end-customers are not permitted to interface with the network directly.
