The Vehicle Interface (VI or CAN translator) is piece of hardware that connects to the car’s CAN bus, translates proprietary CAN messages to the standard OpenXC message format and sends the output over USB, Bluetooth or Ethernet/WiFi to a host device.

CAN Buses on OBD Pins

The OBD-II port has one standard pin pair for a single CAN bus, but many automakers expose other buses on additional, non-standard pin pairs. For this documentation, we’ll use this nomenclature:

OBD-II Pin PairOpenXC Bus NameOther common name
6 (+) and 14 (-) CAN1 CAN high / CAN low from ISO 15765-4 and SAE-J2284
3 (+) and 11 (-) CAN2-1 Ford secondary, Chrysler CCD
1 (+) and 8 (-) CAN2-2 Ford: infotainment, GM: J2411

Most vehicle data is available from CAN1, and all vehicle interfaces connect that bus. Some data is available only on CAN2-1 or CAN2-2, and these buses are not connected to all available VIs (see below). To find out if the information you need is on a bus connected by a particular VI, check the binary firmware documentation for your vehicle manufacturer.

Obtaining a Vehicle Interface

There are two ways you can obtain a vehicle interface.

  • Purchase a Pre-Made VI: The Ford Reference VI and CrossChasm C5 Vehicle Interface are both available for purchase.

  • Build one yourself! The original OpenXC design was built on a chipKIT development board and is still fully supported. The design is open-source and posted below, along with instructions on how to assemble all the required parts.

Ford Reference VI

The VI is a open source reference design for a “dongle” style vehicle interface that connects directly to the diagnostic port with no cable. Ford created this design and manufactured a small quantity to seed the developer community. If you have an idea for an OpenXC application and this hardware would help, you can buy the hardware

Ford Reference VI

The reference VI is not as compact as the C5, but it is open source hardware, so you are free to use or modify this design in your own hardware, and it connects to both the CAN1 and CAN2-1 bus pins (and with a small modification can connect to CAN2-2).

CrossChasm C5

CrossChasm has graciously made the C5 available for purchase from their website, and contributed code to the VI firmware to support their platform. The device on the left is Bluetooth only. The devices on the right is 3G Modem only. Both devices have the exact same programming interfaces. See the vi-firmware documentation for more details on configuration options.

CrossChasm C5 Devices

The C5 is a very compact interface, so it’s great for fleet deployments. It connects to the CAN1 bus pins only with the default cable. A crossover cable is needed to access a secondary CAN bus.

DIY chipKIT-based VI

VI with Enclosure
VI with Cable

This VI design was the first OpenXC interface, and is still fully supported by the latest VI firmware. The design uses entirely off-the-shelf components, built on top of a Digilent chipKIT Max32 development board (open source hardware!). The VI can be assembled with a range of functionality starting at around $110, with no soldering required.

The chipKIT VI can connect to up to 2 CAN buses simultaneously, and you can choose from any of CAN1, CAN2-1 or CAN2-2.

Other Implementations

There are many possible implementations of a VI. The minimal functional requirements are that the VI:

  • Physically connects to the OBD-II diagnostic connector directly or with a cable.
  • Connects a CAN controller to at least the US federally mandated CAN bus pins.
  • Runs the open source VI firmware.
  • can be reprogrammed the end user without additional hardware (most likely via a USB or serial bootloader).

Optionally, the VI may:

  • Connect another CAN controller to non-standard CAN bus pins (such as Ford’s medium speed or infotainment bus pins)
  • Allow lower-level user re-programming and debugging via ISP or JTAG.
  • Pass 12v power from the vehicle through to a separate power jack for peripherals

Unless you are implementing custom CAN messages, you will most likely need a pre-built OpenXC binary firmware from the manufacturer of your vehicle. Each OEM can decide whether or not to participate in OpenXC and if so, decide which types of data they wish to expose.

Once you’ve purchased or constructed a vehicle interface, you can get started with one of the programming environments to make sure it’s working correctly. Both the Python and Android environments have a “smoke test” you can use without writing any code.