Modern vehicles utilize the OBDII port and CAN bus protocol for diagnostics and data transmission. Enthusiasts often leverage microcontrollers like the ESP8266 to tap into this data stream for custom applications. This article explores how to decode CAN frames obtained via an Obdii Esp8266 setup, focusing on translating Torque PIDs into usable data.
Understanding Torque PIDs and CAN Frames
Torque, a popular vehicle diagnostics app, uses PIDs (Parameter IDs) to request specific data points from the vehicle’s ECU (Engine Control Unit). These requests, and the ECU’s responses, are transmitted as CAN frames. A CAN frame is a structured message with fields defining its priority, destination, and data payload. Understanding the relationship between Torque PIDs and CAN frames is crucial for building custom OBDII solutions with the ESP8266. Many resources provide Torque PID information without explaining the underlying CAN frame structure. This article aims to bridge that gap.
Deconstructing a Torque PID
Let’s analyze a sample Torque PID for tire pressure:
pid: 222A05 name: Tire 1 Pressure sName: T1Press Min: 0 Max: 50 Scale: x1 Unit: psi Equation: ((A * 1373) / 1000) * 0.145037738 Header: 720
This PID provides several key pieces of information:
- pid (222A05): This hexadecimal value represents the specific parameter being requested (Tire 1 Pressure). The first two bytes (22) often represent the mode, the next two (2A) represent the PID itself and the last two (05) represent a specific sub-parameter or instance.
- Header (720): This likely represents the CAN ID (identifier) in hexadecimal, indicating the specific system or module responsible for this data (likely related to TPMS).
- Equation ((A 1373) / 1000) 0.145037738: This formula converts the raw data (represented by ‘A’) from the CAN frame into a meaningful value (PSI in this case). ‘A’ typically corresponds to a specific byte or combination of bytes within the CAN frame’s data payload.
Constructing the CAN Frame
Based on the PID information, we can infer parts of the CAN frame structure. A standard CAN frame consists of:
- CAN ID: In our example, likely
720(hexadecimal). This identifies the message’s source and destination. - Data Length: The number of bytes in the data payload (typically 8 bytes for standard CAN). This will depend on the specific PID and the data it returns.
- Data Payload: The actual data being transmitted. This is where the raw tire pressure value resides, which will need to be extracted and processed using the equation provided in the Torque PID.
To fully reconstruct the CAN frame for requesting Tire 1 Pressure, we would need additional information. This might include the specific byte order within the data payload for the pressure value, the data length code, and any required request format specific to the vehicle’s CAN protocol. Reverse engineering or consulting vehicle-specific CAN documentation might be necessary.
Conclusion
Utilizing an OBDII ESP8266 for custom car data applications requires understanding the relationship between Torque PIDs and CAN frames. While Torque PIDs provide valuable information, deciphering the corresponding CAN frame structure often requires further investigation. By carefully analyzing the PID components and referencing CAN documentation, enthusiasts can effectively decode raw CAN data and extract meaningful insights from their vehicles.
