// blog

# How to Read OBD2 Codes: A Simple Guide for Beginners

Locate the OBD2 port, connect a scanner, read and interpret DTCs with examples. Quick tips for common issues and next steps.

          Updated 14 Aug, 2025

          [← All posts](https://www.autopi.io/blog/)

##
    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](https://www.autopi.io/blog/what-is-obd-2/) 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:

    [
        Read more
    ](https://www.autopi.io/blog/what-is-obd-2/)

##
    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.

1.
        **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](https://www.autopi.io/blog/obd2-port-location/).

2.
        **Connect the AutoPi TMU CM4:** Insert the device or extension cable into the OBD2 port and make sure it is firmly seated.

3.
        **Power the device:** Start the vehicle or use a 12 V power cable so the device can boot and begin collecting data.

4.
        **Access AutoPi Cloud:** Log in from a computer or smartphone and open the relevant device or vehicle.

5.
        **Inspect the codes:** Go to the diagnostics view and review current, pending and historical faults where available.

6.
        **Plan the next action:** Use the DTCs together with mileage, timestamps, recent events and live data to decide what should be checked.

7.
        **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.

    [

    ](https://www.autopi.io/hardware/autopi-canfd-pro/)

        [
            View CAN FD Pro
        ](https://www.autopi.io/hardware/autopi-canfd-pro/)

##
    Key takeaway

    For OBD2-based diagnostics, the
    [AutoPi TMU CM4](https://www.autopi.io/hardware/autopi-tmu-cm4/) and
    [AutoPi Cloud](https://www.autopi.io/software-platform/cloud-management/) 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](https://shop.autopi.io/products/autopi-telematics-unit-cm4-4g-lte-edition).

          [
            ← Back to all posts
          ](https://www.autopi.io/blog/)

// hardware

## Check AutoPi Mini compatibility

Start with supported EV and OBD data. Check your make, model and available parameters before choosing PoC devices.

        [Check vehicle support →](https://www.autopi.io/hardware/autopi-mini/#mini-compatibility)

###### Hardware

## Choose your evaluation device

Start with the hardware your project needs. Software and connectivity terms differ by device and purchase option. Prices below exclude VAT, duties, shipping and optional accessories.

            CAN-FD Pro
            In stock · ships tomorrow

### Dual CAN-FD data logger

High-throughput raw frame capture on two independent CAN-FD channels. On-device DBC decoding, ASAM MDF4 output, J1939 native support and hardware-encrypted data signing - all on a Raspberry Pi CM4.

→ 2× CAN-FD · >3,000 fps/channel · 5 Mbps

→ 4 GB LPDDR4 · 32 GB eMMC + USB expansion

→ NXP SE051 · Tailscale SSH · Docker · S3 sync

→ 12–35 V DC · J1939 · OBD-II · 4G/LTE + GPS

            From EUR 599. AutoPi software included without a subscription. Cellular SIM and data purchased separately.

          [Order CAN-FD Pro](https://shop.autopi.io/products/autopi-can-fd-pro)
          [Learn more](https://www.autopi.io/hardware/autopi-canfd-pro/)

            Mini
            In stock · ships tomorrow

### Fleet telematics & OBD-II

OBD-II and supported EV telemetry with GPS and built-in 4G/LTE. Check your exact vehicle, required signals and regional variant; installation and configuration needs vary.

→ OBD-II / K-Line · EV parameters · GPS tracking

→ 4G/LTE Cat 1 · BLE · internal antennas

→ −40°C to +85°C · CE/UKCA/E-Mark/RoHS

→ 10–30 V DC · compact · fleet-ready out of box

            EUR 129 + EUR 6/month for SIM and Cloud, with a 12-month minimum. First-year minimum: EUR 201. Includes 100 MB/month.

          [Order Mini](https://shop.autopi.io/products/autopi-mini)
          [Learn more](https://www.autopi.io/hardware/autopi-mini/)

            TMU CM4
            In stock · ships tomorrow

### Edge compute platform

Raspberry Pi CM4-based telematics unit for custom software stacks. Run Docker containers, Python services and CAN-FD logging on the same device - managed remotely via AutoPi Cloud.

→ BCM2711 CM4 · 1 GB LPDDR4 · 8 GB eMMC

→ 2x CAN or CAN-FD variant · Docker · Python · SocketCAN

→ NXP SE051 · Tailscale · WiFi · BT 5.0 · GPS

→ 12–35 V DC · 4G/LTE Cat 4 · IP67 option

            From EUR 235 with the SIM and Cloud subscription option: EUR 6/month, 12-month minimum. Also available without a subscription; select your interface and payment option in the shop for the price.

          [Order TMU CM4](https://shop.autopi.io/products/autopi-telematics-unit-cm4-4g-lte-edition)
          [Learn more](https://www.autopi.io/hardware/autopi-tmu-cm4/)

      [Compare all devices →](https://www.autopi.io/hardware/compare/)

// related

## More posts you'll like

      [
        View all →
      ](https://www.autopi.io/blog/)

          Raspberry Pi

          DIY

#### Build a Raspberry Pi Touchscreen Car Computer (Step-by-Step)

          Assemble a Pi-based carputer with touchscreen, power, mounting and software setup. Parts list, wiring tips and configuration for a reliable in-car sys
          ...

        [
          Learn More →
        ](https://www.autopi.io/blog/build-a-raspberry-pi-touch-screen-car-computer/)

          Guides

#### J1939 Explained (2025): PGNs, SPNs & Heavy-Duty Diagnostics

          Learn J1939 basics‚ PGNs, SPNs, addressing and tools for heavy-duty trucks and machinery. Examples and troubleshooting tips included.

        [
          Learn More →
        ](https://www.autopi.io/blog/j1939-explained/)

          Guides

#### CAN Bus Explained (2025): Frames, Arbitration & Tools

          Understand identifiers, arbitration, error handling and analyzers used in automotive systems. Practical examples and diagrams.

        [
          Learn More →
        ](https://www.autopi.io/blog/can-bus-explained/)

            // contact

## Still have questions?

Get in touch with us - we're ready to answer any and all questions.

// send a message

We aim to reply within one business day.

Or email [sales@autopi.io](mailto:sales@autopi.io).
