CAN-bus properties:

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):

Nominal speed1Mbps500kbps125kbps50kbps10kbps
Maximum trunk length25m100m500m1km5km
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/s5000/s1250/s500/s100/s
Message capacity (8-byte)5500/s2750/s680/s275/s55/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.

  • 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


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 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 can be activated on the CAN-bus communication using SKIP32 encryption. Encryption prevents eaves-dropping of potential valuable data, or worse, injection of fake data.

Agentschap NL
Gerealiseerd onder het innovatieprogramma

ARM Cortex M3