Cloud Login
Need a simple, practical guide to reading OBD2 codes?
OBD2 codes are used when a vehicle detects a fault and stores it in one of its control units.
The code gives you a starting point for diagnostics.
It does not always tell you exactly which part is broken.
It tells you which system reported a problem, and what condition was detected.
This is why reading OBD2 codes should be treated as a structured diagnostic step, not as a direct parts replacement instruction.
This guide explains how to read OBD2 codes with AutoPi, what equipment is useful, how the workflow looks and how the codes should be used in maintenance, diagnostics and data logging.
Understanding OBD2
OBD2 stands for On-Board Diagnostics version 2.
It is the standardized diagnostic interface used by most modern passenger cars and light commercial vehicles.
OBD2 lets diagnostic tools and telematics devices request fault codes, live values and emissions-related data from the vehicle.
The available data depends on the vehicle, model year, fuel type and manufacturer implementation.
Some signals are standardized.
Other signals are manufacturer-specific and may require CAN, UDS or OEM documentation to access correctly.
For basic diagnostics, OBD2 is usually the right starting point.
It can expose stored and pending fault codes, readiness monitor status, freeze-frame data and common live values such as RPM, coolant temperature, speed and fuel trims.
For a deeper technical overview of the protocol, message structure and modes, see the detailed OBD2 introduction:
The tools you need
Reading OBD2 codes is mainly a data acquisition and interpretation task.
You need a way to connect to the vehicle, request the codes, store the result and inspect the data in a useful format.
For AutoPi-based workflows, the typical setup is:
AutoPi TMU CM4
The AutoPi TMU CM4 is a Linux-based telematics unit built on Raspberry Pi Compute Module 4 hardware.
It can be used to access OBD2 data, raw CAN data and selected vehicle parameters, depending on the vehicle and project setup.
In a normal OBD2 workflow, the TMU CM4 acts as the device installed in the vehicle.
It requests diagnostic trouble codes, samples selected vehicle parameters, collects GPS position and sends the data to AutoPi Cloud or another backend system.
The device is also scriptable, which makes it useful for developers who need custom logic, custom data handling or integrations with external systems.
This makes the TMU CM4 useful for single-vehicle diagnostics, pilot fleets and larger deployments where OBD2 data is one part of a wider telematics setup.
AutoPi Cloud
AutoPi Cloud is the management and visualization layer for data sent from AutoPi devices.
For OBD2 workflows, it gives one place to view DTCs, decoded descriptions, trips, timestamps and vehicle context.
Fault codes can be stored with metadata such as time, vehicle, device and status.
This makes it possible to review recurring codes, compare behaviour across vehicles and connect faults with mileage, temperature, load or other signals.
The same platform can be used by developers, fleet operators and workshops where diagnostic results need to be stored and reviewed in a consistent way.
OBD2 extension cable
The AutoPi TMU CM4 can normally be plugged directly into the vehicle OBD2 connector.
In many vehicles, the connector location is not ideal for a permanent or semi-permanent installation.
An OBD2 extension cable makes it easier to mount the device in a stable location, for example behind trim, under a seat or inside an enclosure.
It also reduces mechanical stress on the vehicle’s original OBD2 port.
In development, testing and fleet setups, this small change can improve reliability because the wear happens on the extension cable instead of the vehicle connector.
Power cable
The AutoPi TMU CM4 can be powered through the OBD2 port in many vehicles.
Some setups need a separate 12 V supply.
A power cable is useful for bench testing, firmware validation and long-running tests where the device should stay online without depending on ignition state.
In lab environments, external power is often the better choice because it gives predictable power and avoids unnecessary cycling of the vehicle electrical system.
Reading OBD2 codes step by step
Reading OBD2 codes with AutoPi follows a simple workflow.
Connect the device, make sure it has power and connectivity, then inspect the diagnostic records in AutoPi Cloud.
- Locate the OBD2 port: The OBD2 port is normally under the dashboard near the steering column. It is a 16-pin connector and may be covered by a cap. Find it here.
- Connect the AutoPi TMU CM4: Insert the device or extension cable into the OBD2 port and make sure it is firmly seated.
- Power the device: Start the vehicle or use a 12 V power cable so the device can boot and begin collecting data.
- Access AutoPi Cloud: Log in from a computer or smartphone and open the relevant device or vehicle.
- Inspect the codes: Go to the diagnostics view and review current, pending and historical faults where available.
- Plan the next action: Use the DTCs together with mileage, timestamps, recent events and live data to decide what should be checked.
- Clear codes when appropriate: Clear diagnostic codes only after the issue has been documented, checked and repaired or after a controlled test.
Clearing codes should not be used as a fix by itself.
It removes useful diagnostic history and can make troubleshooting harder if the underlying problem returns.
Deciphering OBD2 codes
OBD2 codes follow a standardized format.
A code normally has one letter followed by four digits, for example P0301.
The first letter tells which system reported the issue:
- P: Powertrain, such as engine, transmission and emissions systems.
- C: Chassis, such as braking, steering and suspension.
- B: Body, such as airbags, climate control, doors and interior systems.
- U: Network, such as communication faults between ECUs.
The remaining digits describe whether the code is generic or manufacturer-specific, which subsystem is involved and what condition was detected.
Below are examples of commonly seen codes and what they generally relate to:
| Code | Category | Description | Practical meaning |
|---|---|---|---|
| P0300 | Powertrain | Random or multiple cylinder misfire detected | Several cylinders are misfiring or the misfire is not isolated to one cylinder. |
| P0420 | Powertrain | Catalyst system efficiency below threshold | The catalyst system is not performing as expected, or related sensor data indicates poor efficiency. |
| P0171 | Powertrain | System too lean, bank 1 | The air-fuel mixture is too lean. Check air leaks, fuel delivery and sensor data before replacing parts. |
| P0128 | Powertrain | Coolant temperature below thermostat regulating temperature | The engine is not reaching expected temperature. A thermostat fault is common, but sensor data should be checked. |
| P0442 | Powertrain | EVAP system small leak detected | A small leak is detected in the evaporative emission system. |
| C0035 | Chassis | Wheel speed sensor circuit fault | A wheel speed sensor or related wiring fault can affect ABS and stability control. |
| C1214 | Chassis | Brake control relay circuit open | The brake control relay circuit has an electrical issue that can affect braking functions. |
| B0020 | Body | Passenger airbag deployment loop resistance high | A safety-related airbag circuit should be checked with the correct diagnostic procedure. |
| U0100 | Network | Lost communication with ECM/PCM | The diagnostic system lost communication with the engine or powertrain control module. |
| U0121 | Network | Lost communication with ABS control module | Communication with the ABS module is missing or unstable. |
| U0073 | Network | Control module communication bus off | A communication bus problem can affect several vehicle systems at once. |
From codes to action
A DTC means that an ECU detected a condition outside its expected range.
Some codes point to a clear hardware issue.
Other codes need more context, such as live sensor data, fuel trims, temperature, voltage, mileage or communication status.
This is why the code should be used as the beginning of the diagnostic process.
Not the end of it.
Use service documentation, manufacturer information and reliable technical resources to decide what should be checked first.
In a fleet setup, the same code should also be connected with history.
If a code appears repeatedly on the same vehicle, or across several vehicles of the same type, that pattern may be more useful than the code itself.
The do's and don'ts of OBD2 diagnostics
The goal is to move from “code present” to a verified understanding of the fault.
The points below help keep the process structured.
Do:
- Scan regularly: Periodic scans help detect pending or intermittent codes before they become larger problems.
- Keep records: Log codes, timestamps, mileage and final resolution so you can see patterns over time.
- Keep tools updated: Make sure device firmware, PID definitions and DTC definitions are kept current.
- Check the context: Combine DTCs with live data, sensor readings, voltage and communication status.
- Prioritize safety-related faults: Brakes, steering, airbags and stability control faults should be handled quickly.
Don't:
- Do not ignore mild symptoms: A small issue can still point to a condition that gets worse over time.
- Do not clear codes too early: Clearing codes removes useful diagnostic history before the fault is understood.
- Do not skip basic checks: Wiring, connectors, fuses, grounds and battery voltage should be checked before blaming modules.
- Do not replace parts only from the code name: A sensor-related code may describe a condition, not necessarily a failed sensor.
- Do not guess on safety-critical faults: Use qualified support and OEM procedures when the system affects safety.
Final advice
Used correctly, OBD2 diagnostics provide a repeatable way to understand vehicle faults.
Combined with logging, good records and clear procedures, DTCs can support both workshop diagnostics and fleet maintenance.
A simple scanner can read codes once.
An AutoPi device can collect the same type of data over time and connect it with trips, GPS, mileage and other vehicle signals.
That history is often the useful part.
It shows what happened before and after the fault appeared.
The AutoPi CAN FD Pro is intended for projects that require high-speed CAN and CAN FD logging, advanced diagnostics and integration with external analysis systems.
Key takeaway
For OBD2-based diagnostics, the AutoPi TMU CM4 and AutoPi Cloud provide a practical path from in-vehicle data to structured records.
The device handles data acquisition in the vehicle.
The cloud handles storage, visualization, filtering and integration with external systems.
This separation makes it easier to standardize how OBD2 codes and related signals are collected and used.
It can be used for a single vehicle, controlled tests or a larger fleet.
For detailed specifications and hardware options, see the TMU CM4 product page in the shop.
