Low-level CAN Features

The OpenXC message format specification defines a “raw” CAN message type. You can configure the VI firmware to output raw CAN messages using this format.

For example, this JSON configuration will output all CAN messages received on a high speed bus connecetd to the CAN1 controller:

{   "name": "passthrough",
    "buses": {
        "hs": {
            "controller": 1,
            "raw_can_mode": "unfiltered",
            "speed": 500000
        }
    }
}

The only change from a typical configuration is the addition of the raw_can_mode attribute to the bus, set to unfiltered. When using the raw CAN configuration, there’s no need to configure any messages or signals.

You may use both simple vehicle messages and CAN message output simultaneously - the 2 message types will be interleaved on the output interfaces, so you’ll need to check for the right fields before reading the output.

If you’re only interested in a few CAN messages, you can send a filtered set of raw messages. Change the raw_can_mode to filtered and add the messages ID’s you want:

{   "name": "passthrough",
    "buses": {
        "hs": {
            "controller": 1,
            "raw_can_mode": "filtered",
            "speed": 500000
        }
    },
    "messages": {
      "0x21": {
        "bus": "hs"
      }
    }
}

This will read and send the message with ID 0x21 only.

The raw_can_mode flag can be applied to all active CAN buses at once by defining it at the top level of the configuration. For example, this configuration will enable unfiltered raw CAN output from 2 buses simultaneously:

{   "name": "passthrough",
    "raw_can_mode": "filtered",
    "buses": {
        "hs": {
            "controller": 1,
            "speed": 500000
        },
        "ms": {
            "controller": 2,
            "speed": 125000
        }
    }
}

When defined at the top level, the raw_can_mode can be overridden by any of the individual buses (e.g. hs could inherit the unfiltered setting but ms could override and set it to filtered).

There are yet more ways to configure and control the low-level output (e.g. limiting the data rate as to not overwhelm the VI’s output channels) - see the raw configuration examples for more information.

Writing to CAN

By default, the CAN controllers on the VI are configured to be in a read-only mode - they won’t even send ACK frames. If you configure one of the buses to be raw_writable in the firmware configuration, the controller will be write-enabled for raw CAN messages, e.g.:

{   "name": "passthrough",
    "buses": {
        "hs": {
            "controller": 1,
            "raw_can_mode": "unfiltered",
            "raw_writable": true,
            "speed": 500000
        }
    }
}

With a writable bus, you can send CAN messages (in the OpenXC “raw” message JSON format) to the VI’s input interfaces (e.g. USB, Bluetooth) and they’ll be written out to the bus verbatim.

Obviously this is an advanced feature with many security and safety implications. The CAN controllers are configured as read-only by default for good reason - make sure you understand the risks before enabling raw CAN writes.

For additional security, by default the firmware will not accept raw CAN write requests from remote interfaces even if raw_writable is true. Write requests from Bluetooth and network connections will be ignored - only USB is allowed by default. If you wish to write raw CAN messages wirelessly (and understand that those words make security engineers queasy), compile with the NETWORK_ALLOW_RAW_WRITE or BLUETOOTH_ALLOW_RAW_WRITE flags (see all compile-time flags).

The raw CAN write support is intended soley for protoyping and advanced development work - for any sort of consumer-level app, it’s much better to use writable simple vehicle messages.