We at Copperhill Technologies offer a variety of CAN (Controller Area Network) devices for developing automotive and industrial embedded systems. In that capacity, we receive frequent inquiries regarding OBD2 (Onboard Diagnostics).
OBD2, or Onboard Diagnostics Second Generation, is a vehicle diagnosis system found in modern cars and trucks. The OBD2 system collects data from sensors and other monitoring devices, which are then examined by the vehicle's engine control unit (ECU) to determine whether any issues need to be addressed. Problems with the engine, gearbox, emissions system, and others, are among the most common faults that OBD2 can discover.
The inquiries we receive, unfortunately, also reflect some misunderstanding of OBD's purpose and functionality. To make it a point, OBD2 is a mere diagnostics system that allows you to monitor the vehicle's performance. It does not allow you to control the car stereo, windows, steering wheel, or brakes (there were multiple inquiries in that direction, ignoring the more than serious liability aspects).
Of course, there are valid approaches to ODB2 development. Besides some unique ideas, most are about vehicle maintenance and fleet management, including telematics, vehicle performance, and predictive failure analysis.
Furthermore, some entrepreneurs with great ideas miss the stringent hardware requirements to meet harsh environmental conditions, such as temperature and vibration. Your solution should work in Death Valley as well as Antarctica. Many of our customers use the Raspberry Pi with the PiCAN series of CAN Bus HATs for their OBD2 projects. This approach is a great starting point to prove the concept, but in the majority of cases, not recommended for mass production. Alternatively, if you deem your OBD2 project a fun hobby, you are on the right track.
To make it a point, regardless if your OBD2 project is a mere hobby or a great business idea, you need to know OBD2. For example, OBD2 is not a mere protocol based on the CAN Bus. There are five different OBD2 protocols. They are:
- ISO 15765 (CAN bus): Mandatory in US cars since 2008 and is today used in the vast majority of cars
- ISO14230-4 (KWP2000): The Keyword Protocol 2000 was a common protocol for 2003+ cars in, e.g., Asia
- ISO9141-2: Used in EU, Chrysler & Asian cars in 2000-04
- SAE J1850 (VPW): Used mostly in older GM cars
- SAE J1850 (PWM): Used mostly in older Ford cars
However, since ISO 15765 (CAN Bus) has been mandatory for US cars since 2008, one can assume that OBD2 in the majority of cars in the US uses Controller Area Network.
For more information on OBD2, see:
- OBD-II & Electronic Engine Management Systems...
- How To Use Automotive Diagnostic Scanners: - Understand OBD-I and OBD-II Systems...
- Vehicle BUS Communications: Practical Hands On working with CANBUS & OBD-II...
This is a CAN-Bus OBDII ECU simulator using the Teensy 4.0 module (included). Useful for testing OBDII interface and writing diagnostic software. ECU PIDs parameters are adjustable via potentiometers.
This board requires a 12 VDC power supply. A 12 VDC adapter is included.
CAN (J1939) and J1708 networks transport multiple valuable information for telematics of vehicles and stationary objects, such as engine parameters, ABS, EPS, diagnostic codes (DTC), and much more. Crocodile contactless readers are used in telematics systems to gather data from digital buses without breaking the insulation of wires and electrical contacts and without sending active requests [...]
Modern vehicles have electronic control units (ECUs) to control various subsystems such as the engine, brakes, steering, air conditioning, and infotainment. These ECUs (or ‘controllers’) are networked to convey information and output measured and calculated data to each other.This in-vehicle network is a data goldmine for improved maintenance, measuring vehicle performance and its subsystems, fleet [...]
The MasterCAN V-Gate module reads messages from an SAE J1587 and SAE J1939 network, filters and merges the data into single SAE J1939 messages, and transfers the processed data via the output CAN Bus interface. The converter is suitable for vehicles and machinery equipped with SAE J1708 (SAE J1587) networks. The device input signals may be: PGNs (Parameter Group Numbers) according [...]
An electronic logging device (ELD) is electronic hardware that is attached to a commercial motor vehicle engine to record driving hours. The driving hours of commercial drivers (truck and bus drivers) are regulated by a set of rules known as the hours of service (HOS). The Commercial Vehicle Driver Hours of Service Regulations vary in Canada and [...]
The TMU Pi3 telematics unit by Autopi (Denmark) utilizes the Raspberry Pi 3 Model A+ SBC, and it connects to in-vehicle CAN Bus networks via the OBD2 port.The device uses the 1,4-GHz Broadcom BCM2837B0 SOC with Cortex-A53 64-bit quad-core processor, including 512-MiB SDRAM and a 32-GiB micro SD card with installed Raspbian Jessie operating system and Autopi [...]
To mention it upfront, I am not suggesting building the best ELD (Electronic Logging Device) solution in the market. Such systems already exist, and while I like the idea of disrupting the market, I deem such an attempt extremely time-consuming, thus expensive, and most likely not worth the efforts. In other words, KEEPTRUCKIN and Samsara [...]
As it turns out, I recently received two inquiries that involved the testing of wireless vehicle bus adapters for FMS and IoT applications, thus requiring the simulation of SAE J1939 data traffic. In one case, the device in question was the Wireless Vehicle Adapter (WVA) by Digi; the second case involved an unspecified IoT device. In [...]
Sierra Wireless has announced their Airlink MP70 router to support analytics and reporting for cloud-based vehicle fleet operations. The Airlink MP70 router enables the communication of SAE J1939 or OBD-II vehicle data to the cloud. The Airlink Management Service – Advanced Reporting and Analytics (Alms Ara) services enable organizations to manage their vehicle fleets using Sierra Wireless’ industry-leading Airlink [...]
Congatec (Germany) introduced their conga-SMX8, the company’s first Smarc 2.0 Computer-on-Module. It was designed for Internet-of-Things (IoT) applications as well as for embedded control systems.These Smarc 2.0 modules with NXP i.MX8 processors, hardware-based virtualization, and resource partitioning are also applicable for stationary and mobile industrial applications including real-time robotics and motion controls. Since the modules support an [...]