Using Nuvo-2510VTC Reading and Sending OBD-II Message over CAN Bus

Neousys Technology has released its Nuvo-2510VTC, an in-vehicle fanless computer with built-in Intel Bay Trail processor. As a product for in-vehicle applications, Nuvo-2510VTC provides several specific features, such as ignition power control, shock-absorbing mounting kit and also a CAN bus port. This article mainly describes the CAN bus on Nuvo-2510VTC and provides a demonstration of OBD-II communication over CAN bus as a proof of concept.

The beginning of CAN, controller area network, bus dates back in 1983 and was first released in 1986 when the existing serial buses could not fulfill the requirement being used in cars. After several years, CAN bus was implemented in a real vehicle, BMW 8 Series. And nowadays, CAN bus is quite common in the automobile industry. Though CAN bus, compared with other buses, might not be a high speed bus, it shows several features which makes CAN bus suitable for in-vehicle applications. First, CAN is a bus of multi-master with prioritized message ID. Every node on the bus can send message when the bus is unoccupied. In the CAN message, there is a message ID. If more nodes send at the same time, the one with lower ID gets the authority to send, and the others stop sending immediately. This makes sure the urgent message is transmitted first without extra delay for arbitration. Secondly, CAN bus uses differential signal over two wires and supports multi-drop topology. The differential signal of CAN bus naturally results in noise cancellation. External disturbance on the two wires will be eliminated. Contributed by multi-drop topology, every CAN node on the bus can get the message at the same time. Faulty nodes will not break the bus connection. Besides, there’s no hardware identification, such as an address, of each CAN node. It’s easy to add, replace or remove a node without change to the system or other nodes on the bus.

CAN bus also features its error detecting and error handling capabilities. Five error types, i.e. bit error, stuff error, CRD error, form error and acknowledgment error, are defined to ensure that CAN data frames are correctly transmitted and received. CRC field in the CAN data frame ensures the data consistency of CAN data frame. ACK field makes the transmitting node to know if the message is received by at least one node on the bus. Moreover, a sophisticated fault confinement mechanism, together with the five error types, is implemented to distinguish each CAN node in one of the three states, i.e. error active, error passive and bus off. When a node encounters too many errors, it will be in bus off state and will have no influence on the bus. This allows messages from good nodes to traffic on the bus.

Based on the features, CAN bus focuses on Physical Layer and Data Link Layer according to the ISO/OSI model. While CAN bus provides a reliable foundation of communication, there are many CAN-based HLPs, standing for CAN-based higher layer protocols, defined over CAN bus in different applications. For example, CANopen and DeviceNet are CAN-based HLPs used in industrial automation. OBD-II and J1939 are those for in-vehicle applications. EnergyBus is developed for electric vehicles. There are still other CAN-based HLPs, such as CAN Kingdom, NMEA 2000 and VSCP for different fields.

The mentioned OBD-II, standing for On-Board Diagnostics, refers to the self-diagnostic and reporting capability of a vehicle. OBD-II interface defines five physical signals via a 16-pin connector. Cars can support one or more of them to provide OBD-II capability. CAN bus is one of these five signals and getting more and more popular. After 2008, all vehicles sold in the US are required to implement CAN as one of these five signals. The communication protocol of OBD-II is a simple query and response process based on the OBD-II Parameter IDs and Modes. Figure 1 shows simplified CAN data frame and how OBD-II query frames fit in it. A single CAN bus data frame has a maximal 8 bytes of payload, and OBD-II query frame occupies all the 8 bytes although not all of them are used. In order to transmit all the 8 bytes payload, data length of CAN data frame is set to 8. To send OBD-II query frame over CAN bus, CAN ID is set to 0x7df. The digram shows a basic OBD-II query frame. What we need to do is to fill in the code of Mode and PID, e.g. Parameter ID. For example, Mode 0x01 means to query current data and PID 0x0C indicates engine rotational speed in revolution per minute. The full list of OBD-II PIDs can be found on Wikipedia.

 CAN Data Frame with OBD Query Frame
Figure 1: CAN Data Frame with OBD Query Frame
 CAN Data Frame with OBD Response Frame
 Figure 2: CAN Data Frame with OBD Response Frame

The OBD-II response frame looks simular with the OBD-II query frame except that CAN ID ranges from 0x7e8 to 0x7ef and the 0x40 is added to Mode of the corresponding query frame. That is, Mode 0x41 is the response mode of Mode 0x01, Mode 0x42 is the response mode of Mode 0x02, and etc. In the OBD-II response frame, the value of queried PID starts at the 4th byte of CAN Data. The OBD-II PID list also indicates the formula to calculate the final values. Take querying current engine rotational speed of the vehicle as an example. The following diagram shows the query and response frame, assuming that the engine rotates at 3000rpm.

 OBD-II Query and Response Frame over CAN bus

 Figure 3: OBD-II Query and Response Frame over CAN bus

The query frame has a CAN ID of 0x7df and indicates the frame is to going to query some data. Mode 0x01 is the mode to show current data, and PID 0x0C means engine rotational speed in revolution per minute. CAN ID of the response frame might vary from 0x7e8 to 0x7ef. The number of bytes is 0x04, which means 4 bytes, i.e. Mode, PID, value A and value B, are available. The response mode 0x41 means the frame is a response to a mode 0x01 query frame, and PID 0x0C shows the frame contains the engine rotational speed. According the the PID list, the formula of engine rotational speed is (A*256+B)/4. That is, (0x2E*256+0xE0)/4, 3000 RPM.

Nuvo-2510VTC from Neousys Technology is an in-vehicle fanless computer with Intel® AtomTM E3845 quad-core processor. The built-in CAN bus port is complied with CAN Specification 2.0 Part A and Part B. Bit rates up to 1Mbps are possible at network lengths less than 40 meters. APIs, application programming interfaces, for Windows programming are provides for developing user applications. Nuvo-2510VTC and its APIs cover most sophisticated part of CAN communication so that users can focus on sending and receiving the CAN message. In C programming with the APIs, a data structure of CAN Message, CAN_MSG, is provided. CAN_MSG defines CAN_MSG.id, CAN_MSG.len and CAN_MSG.data[8] for the green, blue and red fields shown in Figure 3 respectively.

Block diagram of the demonstration system
Figure 4: Block diagram of the demonstration system

To demonstrate reading and sending OBD-II messages over CAN bus using Nuvo-2510VTC, we establish a demonstration system as shown in Figure 4. An OBD-II to Bluetooth module, ELM 327 compatible, is commonly used in vehicles to transmit the OBD-II message via Bluetooth to your cellular phone with an OBD-II APP, such as Torque, to get the diagnostic information from the vehicle. A Nuvo-2510VTC is connected to the ELM 327 module via a commercial off the shelf DB9 to OBD-II cable, and acts as an ECU simulator, which receives OBD-III query frame over CAN from the ELM 327 and response to the query. With the installed OBD-II APP, the response can be observed on your cellular phone. The demonstration program on Nuvo-2510VTC is modified from the CAN sample program. It sends a triangle wave and sine wave of vehicle speed and engine rotational speed respectively. Figure 5 shows the demonstration system and the result on the cellular phone. The left graphics is vehicle speed, i.e. PID 0x0D, while the right one is engine rotational speed in RPM, i.e. PID 0x0C.

 Real demonstration system and result
 Figure 5: Real demonstration system and result

In summary, CAN bus is a serial bus which supports multi-drop topology and is widely used in automotive and industrial applications. The 5 error types, 3 error states and 2 error counters form the fault confinement mechanism and ensure the stability of bus communication. Designed for in-vehicle application, Nuvo-2510VTC from Neuosys Technology provides a built-in CAN bus port. The provided SDK facilitates access to CAN bus despite the sophisticated theory of operation. Using the built-in CAN bus port of Nuvo-2510VTC to read and send OBD-II message over CAN is demonstrated as a proof of concept. This shows Nuvo-2510VTC is complied with CAN 2.0 Part A and Part B and compatible with off-the-shelf CAN bus products and CAN-based HLPs. For further detail of Nuvo-2510VTC, please visit the product web page.

Comments are closed.