Parse CAN Hardware and Circuit Identifiers

This article was written for version 2.0.9 of Core. Click here for the most recent version of the help center.

CAN interface hardware IDs and circuit IDs exist independently of a CAN sensor, and are required parameters for all CAN-based sensor nodes defined in the SDF Configurator.

Kvaser and SocketCAN-enabled hardware devices are supported on PolySync, and each have different methods to identify the USB and/or PCIe CAN interfaces.

Kvaser hardware uses the linuxcan libraries to communicate with CAN hardware on Linux.

All other off-the-shelf hardware uses SocketCAN libraries to communicate with CAN hardware on Linux.

1. Kvaser

PolySync needs to know the CAN channel hardware ID and the CAN channel circuit ID of the Kvaser CAN interfaces (USB, PCIe, etc.) that are connected to the sensors.

The hardware identifier is unique to each physical hardware device (USB, PCIe, miniPCIe), where each device has one or more channels. The circuit identifier is an index for multi-channel CAN hardware interfaces.

Consider the following example where there are two Kvaser Leaf Lights connected: one 2x CAN to 1x USB Leaf Light, and one 1x CAN to to 1x USB Leaf Light.

$ /usr/src/linuxcan/canlib/examples/listChannels
Found 3 channels.
channel 0 = Kvaser Leaf Light v2, 73-30130-00685-0, (0)28373, 3.3.0.769
channel 1 = Kvaser Leaf Light v2, 73-30130-00685-0, (1)28373, 3.3.0.769
channel 2 = Kvaser Leaf Light v2, 73-30130-00685-0, (0)11375, 3.3.0.769
Example input CAN Channel Hardware Identifier CAN Channel Circuit Identifier
channel 0 = Kvaser Leaf Light v2, 73-30130-00685-0, (0)28373, 3.3.0.769 28373 0
channel 1 = Kvaser Leaf Light v2, 73-30130-00685-0, (1)28373, 3.3.0.769 28373 1
channel 2 = Kvaser Leaf Light v2, 73-30130-00685-0, (0)11375, 3.3.0.769 11375 0

For single-channel CAN interfaces, the circuit identifier will always be 0.

1.1 Troubleshooting

This section contains troubleshooting steps for common issues seen while using Kvaser hardware and software on a Linux system.

1.1.1 No channels listed

This issue happens frequently and seemingly randomly. A USB Leaf Light is connected, but the listChannels example application does not detect any hardware.

This happens when the Linux system does not know which kernel module to load (the module is used to talk with the USB hardware), or the existing linuxcan kernel modules were not built against the installed kernel.

Follow these steps (repeatedly) until the Kvaser device(s) can be detected by Kvaser’s canlib listChannels example.

  1. If the machines kernel has been upgraded recently with apt-get update; apt-get upgrade the linuxcan libraries need to be rebuilt
  $ cd /usr/src/linuxcan/
  $ sudo make clean 
  $ make
  $ sudo make install 
  1. Unplug and replug the USB Leaf Light hardware
  2. Manually modprobe the kernel module used to communicate with the hardware
  $ sudo modprobe leaf   # *see note below for a list of other kernel modules
  1. Run the listChannels example application
  $ /usr/src/linuxcan/canlib/examples/listChannels

If the channels are not listed, go back to step 2. Eventually the Linux system will detect the USB device and load the appropriate driver. Once this happens PolySync is able to detect and connect to the CAN channel.

1.1.2 Unable to sniff CAN data

While trying to validate the data coming in over CAN, error frames are read using the Kvaser linuxcan canmonitor example.

This is likely caused by having the wrong baudrate set in the canmonitor example, versus what the CAN sensor is publishing. Nearly all automotive based sensors publish data to the CAN bus at 500K baud.

Update the canmonitor source code to open the CAN channel with 500K baud to read and validate the incoming data.

$ cd /usr/src/linuxcan/canlib/examples/
$ vim canmonitor.c
  Line 93: BAUD_1M --> BAUD_500K

2. SocketCAN

SocketCAN enumerates CAN interfaces just as if it were an Ethernet socket. In PolySync, only the hardware identifier is needed when using SocketCAN CAN interfaces.

Available devices can be queried from the system with ifconfig -a, and are typically represented as can0, can1, etc.

The devices map to the following values in PolySync:

SocketCAN Channel PolySync HW ID
can0 1
can1 2
can2 3
canN N+1