The vehicle interface (VI or CAN translator) is based on a microcontroller with two external connections - one to the CAN bus via the OBD-II port, and one to the host device via USB or serial. It passively listens for a subset of CAN messages, performs required unit conversion or factoring and outputs a generic version to the USB interface.
Unless you are implementing custom CAN messages, you will most likely need a pre-built OpenXC binary from the manufacturer of your vehicle. Each OEM can decide whether or not to participate in OpenXC and if so, which types of data they wish to expose.
The current implementation uses the Digilent chipKIT Max32, an Arduino-compatible microcontroller based on PIC32. The Network Shield add-on adds two CAN transceivers, which is enough to enable most OpenXC applications.
The translator is powered via its micro-USB port, which is connected to the host device. CAN messages are received via the OBD-II port in the driver's footwell.
If you want wireless support, we have documentation and an extended parts list for adding a Bluetooth module.
Parts List
This is a list of the hardware used in the reference OpenXC kit - you're guaranteed to have a 100% compatible OpenXC device if you use these parts exactly. There are many equally compatible variations on this list from hundreds of different vendors, so feel free to use other parts you may have on hand (like the crimp connectors, for example).
Tools List
This is a list of the tools needed to assemble the kit.
For the suggested enclosure, you'll also need the following:
There are 2 USB ports on the combined Max32 and Network Shield, so getting the cables sorted out can be a bit confusing. The ports are meant to be used as follows:
The OBD-II cable is safe to plug in at any time, with the vehicle running or off. The cable only fits one way into the vehicle's port, like a USB cable.
CAN
Modern automobiles are laced with a number of microcontrollers and sensors that monitor and control everything from the throttle position to the ambient air temperature. These devices communicate with each other over a wired in-vehicle network, a CAN bus.
(Creative Commons, Ford Motor Company)
Compared to something like the network of the Internet, CAN is relatively simple and low-level. CAN buses have 2 wires, and vehicles typically have two or three CAN buses running at speeds ranging from 125Kbps to 500Kbps. The protocol used to send data between nodes on the network is roughly equivalent to a link layer protocol like MAC or ARP. It's a broadcast network and only one node can send data at a time. It handles message priorities at the bit level which makes it a good choice for vehicle networks, when you absolutely, positively, must make sure the brake pedal status is sent.
CAN Data Format
CAN network traffic is organized into frames (or messages) that have:
Within the 64 bits of data of each CAN message there are typically multiple data points, e.g. the steering wheel angle, a quality factor for the sensor, the center point of the steering wheel, etc. Each of these bit fields is known as a CAN signal.
The exact format of these bit fields and messages are typically considered sensitive information by vehicle manufacturers. The OpenXC VI allows these companies to keep that information private, but still give consumers and developers access to the data contained within. Even for engineers inside the companies, dealing with a standard data format across many vehicles is often preferable to keeping track of a database of CAN message and signal definitions.
The CAN bus is one of the primary components of OBD-II, a vehicle diagnostic standard mandatory for all cars sold in the United States since 1996. The OBD-II standard sends and receives messages on the CAN bus. If you've ever watched your mechanic plug a tool in somewhere underneath your steering wheel, or seen a vehicle monitoring app for your smartphone, that's OBD-II in action. You'll always find the port by the driver's knees.
Diagnostic messages work slightly differently than the CAN messages used by all other in-vehicle systems. When you turn on your car, the CAN bus is very busy with so-called "normal" messages. For example, the engine control unit (ECU) continuously sends a CAN message with the engine speed (in RPM). The cluster listens for this message on the bus and updates the tachometer arm when it receives a new value. The cluster doesn't have to query for anything.
Conversely, diagnostic messages use a request/response style. When you attach an off-the-shelf OBD-II scan tool, it sends specially formatted diagnostic command messages over the CAN bus. Nodes on the network that can output diagnostic information are listening for these messages, and send out the requested status information over CAN when asked. There's no point in sending these messages when nothing is attached and capable of interpreting the results, so these messages are not sent continuously to minimize the level of traffic on the network.
The diagnostic request protocol is relatively standard across vehicle manufacturers, but beyond the standardized (and mandated) OBD-II parameters, the diagnostic message identifiers and formats are also largely proprietary.
Bought all of the parts for the VI? The detailed assembly guide is next.
