OBD-II Fleet Tracker.

Project Overview

Plugs into a vehicle's OBD-II port to stream health, location and driving behaviour — turning a fleet into data a manager can actually act on.

Every car and truck built in the last two decades carries a rich diagnostic computer and a standard socket to read it — the OBD-II port — yet most fleets throw that data away, managing vehicles by guesswork: they learn a van is broken when it breaks down, learn a driver speeds when there is a complaint, and have no idea which vehicle is where. This project plugs a tracker into the OBD-II port to stream the three things a fleet actually needs: vehicle health (fault codes and live engine data), location (GPS), and driving behaviour (telematics) — turning each vehicle into a live data feed a manager can act on.

On health, the tracker reads the OBD-II diagnostic trouble codes (DTCs) — the same codes a garage reads — so a fault (a check-engine condition, an emissions problem) is known the moment it appears, not at the next breakdown, enabling proactive maintenance. It also reads live parameters (engine RPM, coolant temperature, fuel/consumption, speed) for condition and efficiency insight. On location, a GPS gives real-time position for dispatch, routing and utilisation. On driving behaviour, it derives telematics — harsh braking, harsh acceleration, cornering, speeding, idling — from the OBD speed and an accelerometer, which is what drives safety, fuel economy and insurance outcomes.

Streamed over cellular to a fleet platform, this gives a manager a live picture of every vehicle's health, whereabouts and driving — the foundation of modern fleet management: fewer breakdowns (proactive maintenance from DTCs), lower costs (efficiency and reduced harsh driving/idling), better utilisation and safety, and evidence for coaching and disputes. It is honest that OBD-II parameter support varies by vehicle, that reading the port must not interfere with vehicle systems, and that driver-behaviour data is sensitive and must be handled fairly and lawfully. But as an OBD-II tracker unifying health, location and telematics, it converts a fleet from a set of unmonitored vehicles into a managed, data-driven operation.

What this project does

• Reads OBD-II diagnostic trouble codes (health/faults)
• Reads live engine parameters (RPM, temp, fuel, speed)
• Tracks GPS location for dispatch/utilisation
• Derives driving telematics (harsh braking/accel, speeding, idling)
• Streams health/location/behaviour to a fleet platform over cellular
• Enables proactive maintenance, efficiency and safety
• Provides evidence for coaching and disputes

Real-World Applications

Deployment contexts where a build of this kind earns its keep.

Features & Capabilities

• OBD-II DTC + live-parameter reading
• GPS location/utilisation
• Driving telematics (harsh events, speeding, idling)
• Cellular streaming to a fleet platform
• Proactive maintenance from fault codes
• Efficiency/safety insight
• Honest about OBD support, non-interference, data sensitivity

Difficulty, Time & Required Skills

Skills you should have (or will pick up)

• OBD-II (ELM327/CAN) reading of DTCs and PIDs
• GPS tracking
• Telematics (harsh events, speeding, idling) from OBD + accelerometer
• Cellular streaming to a platform
• Handling driver data fairly/lawfully

Bill of Materials

Every part below is commonly available from Indian and international hobby-electronics suppliers. Prices are indicative 2026 retail figures in Indian rupees and will drift — treat them as a budgeting guide, not a quotation.

Estimated total: ₹4,590, excluding tools, shipping and consumables.

Tools and consumables

• Soldering iron (temperature controlled, 350 °C) with 0.8 mm 60/40 or lead-free solder
• Digital multimeter — continuity, DC volts and current ranges
• Wire strippers, flush cutters and a small set of precision screwdrivers
• Heat-shrink tubing and a heat gun (or a lighter, carefully)
• A laptop with a USB port and the toolchain listed above

Hardware Specifications

Consolidated electrical and interface specifications for every active part in the build.

Power Budget & Supply Sizing

Add up the typical active current of every part, then size the supply with at least 50 % headroom so transmit bursts and motor inrush never brown out the controller.

Summed typical draw is 2228.9 mA. With a 1.5× design margin the supply should deliver at least 3400 mA continuously at the stated rail voltage.

Software Requirements & Development Environment

Reference toolchain: Arduino IDE 2.3.x with the ESP32 board package 3.x (or PlatformIO on VS Code). Anything newer normally works; anything older may lack the board definitions used here.

• Install the Arduino IDE 2.3.x (or PlatformIO if you prefer a real editor and dependency locking).
• Add https://espressif.github.io/arduino-esp32/package_esp32_index.json under File → Preferences → Additional Board Manager URLs, then install esp32 from the Boards Manager.
• Set the correct port under Tools → Port. On Linux add yourself to the dialout group: sudo usermod -aG dialout $USER and log out and back in.
• Open the Serial Monitor at 115200 baud — every sketch here logs its state there.
• Keep File → Preferences → Show verbose output during: compilation switched on while you are debugging build errors.

Required libraries

Block Diagram

The block diagram shows the functional decomposition of the system — what senses, what decides, what acts, and where the data ends up.

Circuit Diagram & Wiring

Every signal line in the build is shown below, followed by a pin-by-pin connection table you can work through with a multimeter in hand.

Wire one row at a time and tick it off — most "it does not work" reports trace back to a single swapped pair.

Wiring explanation

• Interface the OBD-II port (ELM327 or CAN) to read DTCs and live PIDs; read only — do not write to or interfere with vehicle systems.
• Add GPS for location and a cellular modem for streaming; power from the OBD port (with a safe regulator).
• Add an accelerometer for harsh-event telematics alongside OBD speed.
• Handle unsupported PIDs gracefully — support varies by vehicle.
• Treat driver-behaviour data as sensitive; handle fairly and lawfully.

System Architecture

Read the stack from the bottom up: physical hardware, the firmware that drives it, the transport that moves data off the device, and the software a human actually looks at.

Working Principle

A modern vehicle is already a dense sensor network with a standard interface — the OBD-II port mandated on cars and light trucks — reporting engine and emissions data and storing diagnostic trouble codes when something is wrong. A fleet that ignores this manages blind; a fleet that reads it gains exactly the three data streams that matter operationally. The tracker's job is to unify them: health from OBD, location from GPS, and behaviour from telematics — because a manager needs all three together (where is the vehicle, is it healthy, is it being driven well) to actually run a fleet.

Health is the highest-value stream. Reading the OBD-II DTCs gives the same fault information a garage sees — the moment a fault appears (a check-engine condition, a sensor fault, an emissions problem), the fleet knows, rather than discovering it at the next roadside breakdown. That enables proactive maintenance: schedule the repair before the failure, avoiding the far larger cost and downtime of a breakdown. Live parameters (RPM, coolant temperature, fuel trims, consumption) add condition and efficiency insight, though the design must handle the reality that PID support varies by vehicle — not every parameter is available on every make, so unsupported reads are handled gracefully.

Location is the obvious stream and the enabler of dispatch, routing and utilisation, and behaviour telematics is the stream that changes outcomes. From the OBD speed and an accelerometer, the tracker derives the events that drive fleet safety and cost: harsh braking and acceleration, hard cornering, speeding, and excessive idling. These are the levers of fuel economy (harsh driving and idling waste fuel), safety (harsh events and speeding cause crashes), wear (aggressive driving wears vehicles), and insurance (usage-based insurance prices on exactly this behaviour). Turning raw motion into these named events is what lets a manager coach drivers, cut fuel, and evidence disputes.

Streamed to a fleet platform over cellular, the three streams together transform operations: proactive maintenance from DTCs cuts breakdowns; efficiency and reduced harsh-driving/idling cut fuel and wear; live location improves utilisation and routing; and behaviour data supports safety coaching and insurance. The design is honest about its constraints and responsibilities: OBD parameter support varies, so the tracker degrades gracefully; reading the port must never interfere with vehicle systems (it reads, it does not disrupt safety-critical buses); and driver-behaviour data is sensitive personal data that must be handled fairly, transparently and lawfully (drivers informed, data used for legitimate fleet purposes, privacy respected). Within that frame, it does what fleet management fundamentally requires — turn a set of unmonitored vehicles into a live, unified feed of health, location and behaviour that a manager can act on.

The maths behind it

Health from OBD-II

Read DTCs (mode 03) and live PIDs (mode 01):

  new DTC → fault alert (proactive maintenance)
  live: RPM, coolant temp, speed, fuel/consumption
  handle unsupported PIDs gracefully (support varies).

Driving telematics

From OBD speed v and accelerometer a:

  harsh braking if a_long < −A_HB
  harsh accel   if a_long >  A_HA
  hard corner   if |a_lat| > A_C
  speeding      if v > speed_limit(location)
  idling        if engine on AND v ≈ 0 for > t_idle

These drive safety, fuel and insurance outcomes.

Actionable value

proactive_maintenance: fix on DTC before breakdown
fuel/safety: coach out harsh events + idling
utilisation: from location + status
insurance/UBI: price on behaviour (handled lawfully).

Program Flowchart

The firmware is a single cooperative loop. Nothing blocks for long, so networking, sensing and the user interface all stay responsive.

Assembly Instructions

Build on a breadboard first and only commit to solder once the whole system has run for an hour without a fault.

1. Interface the OBD-II port (read-only)

   Connect an ELM327/CAN interface to read DTCs and live PIDs, powered from the OBD port. Read only — never write to or disrupt vehicle systems.

   Handle unsupported PIDs gracefully.

2. Add location and telematics sensing

   Add GPS for location and an accelerometer for harsh-event telematics alongside OBD speed.

3. Stream and manage

   Stream health/location/behaviour to a fleet platform over cellular; alert on new DTCs and behaviour events.

Step-by-Step Implementation Guide

Work through these in order. Each step ends in something you can observe, so a failure is always localised to the step you just finished.

1. Read health and derive telematics

   Read DTCs and live PIDs, and derive harsh-event/speeding/idling telematics from OBD speed and the accelerometer.

   cppobd-telematics.ino Copy Download

   #define A_HB 0.35f    // g harsh braking
   #define A_HA 0.30f    // g harsh acceleration
   #define T_IDLE_S 180  // idling threshold
   
   // Read stored fault codes (health).
   int readDTCs(char codes[][6], int max){
     return obdReadMode03(codes, max);      // e.g. "P0301"
   }
   
   // Derive a driving event from OBD speed + accelerometer.
   const char* drivingEvent(float speed_kmh, float aLong, float aLat,
                            float limit_kmh, uint32_t idleSecs){
     if (aLong < -A_HB) return "harsh braking";
     if (aLong >  A_HA) return "harsh acceleration";
     if (fabsf(aLat) > 0.35f) return "hard cornering";
     if (limit_kmh>0 && speed_kmh > limit_kmh + 10) return "speeding";
     if (speed_kmh < 3 && engineOn() && idleSecs > T_IDLE_S) return "excessive idling";
     return nullptr;
   }

   int readDTCs(char codes[][6], int max)Reads the stored diagnostic trouble codes — the same fault information a garage sees — so a fault is known the moment it appears, enabling proactive maintenance.

   if (aLong < -A_HB) return "harsh braking"Harsh braking/acceleration are derived from the accelerometer, the safety- and fuel-relevant events a manager coaches out.

   if (limit_kmh>0 && speed_kmh > limit_kmh + 10) return "speeding"Speeding is flagged against the location's limit — a core safety and insurance signal.

   if (speed_kmh < 3 && engineOn() && idleSecs > T_IDLE_S)Excessive idling wastes fuel and is flagged from engine-on with near-zero speed over a threshold.

2. Stream and alert

   Stream health (DTCs/PIDs), location and behaviour events to the fleet platform over cellular, alerting on new faults and behaviour events; handle driver data lawfully.

Complete Source Code

The listing below is complete and compiles as written — there are no elided sections. Read the annotations under each block before you upload it.

/* ═══════════════════════════════════════════════════════════════
   OBD-II Fleet Tracker — ESP32

   Reads vehicle HEALTH (DTCs + live PIDs), LOCATION (GPS) and driving
   BEHAVIOUR (telematics), and streams them to a fleet platform over
   cellular. Read-only (no interference); driver data handled lawfully.
   ══════════════════════════════════════════════════════════════════ */

#include <TinyGPS++.h>
#include <Wire.h>
#include <MPU6050.h>

#define A_HB 0.35f
#define A_HA 0.30f
#define T_IDLE_S 180
#define VEHICLE_ID 42

TinyGPSPlus gps; HardwareSerial gpsSer(2);
MPU6050 imu;
uint32_t idleSince=0;

int readDTCs(char c[][6], int max){ return obdMode03(c, max); }     // faults
float obdSpeed(){ return obdPID(0x0D); }                            // km/h
float coolant(){ return obdPID(0x05); }                             // degC
float rpm(){ return obdPID(0x0C); }

const char* drivingEvent(float v, float aL, float aLat, float limit,
                         uint32_t idleS){
  if (aL < -A_HB) return "harsh braking";
  if (aL >  A_HA) return "harsh acceleration";
  if (fabsf(aLat) > 0.35f) return "hard cornering";
  if (limit>0 && v > limit+10) return "speeding";
  if (v < 3 && engineOn() && idleS > T_IDLE_S) return "excessive idling";
  return nullptr;
}

void stream(const char* json){ sendOverCellular("fleet/telemetry", json); }

void setup(){
  Serial.begin(115200);
  gpsSer.begin(9600, SERIAL_8N1, 26, 25);
  Wire.begin(21,22); imu.initialize();
  obdInit();                                    // ELM327/CAN, read-only
}

void loop(){
  while (gpsSer.available()) gps.encode(gpsSer.read());

  // HEALTH: new DTCs -> proactive maintenance alert
  static char codes[8][6]; int n = readDTCs(codes, 8);
  if (n > 0){
    char m[160]; snprintf(m,sizeof m,
      "{\"veh\":%d,\"dtc\":\"%s\",\"health\":\"fault\"}",
      VEHICLE_ID, codes[0]);
    stream(m);
  }

  // BEHAVIOUR: telematics from OBD speed + accelerometer
  int16_t ax,ay,az; imu.getAcceleration(&ax,&ay,&az);
  float aL = ax/16384.0f, aLat = ay/16384.0f;
  float v = obdSpeed();
  if (v < 3){ if(!idleSince) idleSince=millis(); } else idleSince=0;
  uint32_t idleS = idleSince? (millis()-idleSince)/1000 : 0;
  const char* ev = drivingEvent(v, aL, aLat, speedLimitAt(gps.location), idleS);

  char m[260];
  snprintf(m,sizeof m,
    "{\"veh\":%d,\"lat\":%.6f,\"lon\":%.6f,\"kmh\":%.0f,"
    "\"rpm\":%.0f,\"coolant\":%.0f,\"event\":\"%s\"}",
    VEHICLE_ID, gps.location.lat(), gps.location.lng(), v, rpm(), coolant(),
    ev?ev:"none");
  stream(m);
  if (ev) sendOverCellular("fleet/event", m);

  delay(2000);
}

Configuration & Calibration

Configuration steps

• Configure the OBD interface (ELM327/CAN), the PIDs to read, and DTC handling.
• Configure GPS, cellular streaming, and telematics thresholds (harsh/speeding/idling).
• Handle unsupported PIDs gracefully per vehicle.
• Configure lawful/transparent handling of driver-behaviour data.

Calibration procedure

An uncalibrated sensor produces confident, precise, wrong numbers. Do this once per physical unit and record the constants.

1. OBD/PIDs

   Verify DTC reading and which PIDs the vehicle supports; handle unsupported ones.

2. Telematics

   Calibrate accelerometer orientation and harsh-event thresholds so real events flag without excess false positives.

3. Location/streaming

   Verify GPS fix and cellular streaming across the operating area.

Network Architecture & Connectivity

Communication protocol

Trackers stream health (DTCs/PIDs), location and behaviour events; the platform unifies them for maintenance, dispatch and safety.

Message contract between the device and the broker.

Cloud platform configuration

A fleet platform unifies health, location and behaviour, driving proactive maintenance (DTCs), dispatch/utilisation (location), and safety/fuel coaching (telematics).

Dashboard setup

A fleet map with per-vehicle health/faults, location, live parameters, and driving-event scoring.

Mobile app integration

DTC/maintenance alerts, harsh-event/speeding alerts, and location.

Security considerations

• Authenticate trackers; secure telemetry.
• Read-only OBD; never interfere with vehicle systems.
• Handle driver-behaviour data fairly, transparently and lawfully.

Testing Procedure & Expected Output

Test from the bottom up. Confirm power, then each sensor in isolation, then the integrated loop — the first failing step tells you exactly where to look.

Bench-test checklist. If a row fails, stop and fix it before moving on.

Expected output

The fleet platform shows each vehicle's health (faults), location, live parameters and driving events, enabling maintenance, dispatch and safety coaching.

{
  "veh": 42,
  "lat": 28.61390,
  "lon": 77.20900,
  "kmh": 58,
  "rpm": 2100,
  "coolant": 92,
  "event": "harsh braking"
}

A vehicle's live health, location and a harsh-braking event — the unified feed a fleet manager acts on; a new DTC would raise a proactive-maintenance alert before a breakdown.

Troubleshooting: Common Errors & Fixes

Performance Optimisation

• Stream at a sensible rate; alert on DTCs and events immediately.
• Read supported PIDs; handle unsupported gracefully.
• Derive telematics on-device from OBD speed + accelerometer.
• Keep OBD read-only and non-interfering.
• Replace every delay() with a millis() comparison — blocking delays are the single most common cause of dropped readings.
• Sample sensors on a fixed cadence and publish on a slower one; you almost never need to transmit at the sampling rate.
• Move networking into its own FreeRTOS task so a slow DNS lookup cannot stall the control loop.
• Use uint8_t / uint16_t where the range allows; on an 8-bit AVR a 32-bit add costs four times as much.
• Batch several samples into one MQTT publish. Radio time, not CPU time, dominates the energy budget.
• Set the MQTT keep-alive to a value that matches your reporting interval so the broker does not churn reconnections.
• For battery builds use deep sleep between samples: an ESP32 drops from ~160 mA awake to about 10 µA asleep, which is the difference between days and months of runtime.

Safety Precautions

• Read-only OBD — never write to or interfere with vehicle systems, especially safety-critical buses.
• Driver-behaviour data is sensitive personal data — handle it fairly, transparently and lawfully; inform drivers.
• Install the tracker without obstructing driving or the OBD port's intended use.
• OBD parameter support varies by vehicle — degrade gracefully.
• Lithium cells vent and burn when abused. Only use protected cells or a proper BMS, never charge below 0 °C, and never leave a charging pack unattended on a wooden desk.
• Never power an RF module without its antenna fitted — the reflected power destroys the output stage. Check your local licence-free band and duty-cycle limits before transmitting.
• Wear eye protection when soldering or cutting, and solder in a ventilated space — rosin flux fumes are a respiratory irritant.
• Power the circuit through a bench supply with a current limit while you are testing. A 300 mA limit turns a wiring mistake into a beep instead of a dead board.
• Disconnect power before changing any wiring. Hot-plugging a sensor onto a live bus is the fastest way to lose a controller.

Maintenance

• Act on DTC/maintenance alerts proactively.
• Verify OBD/PID support and telematics thresholds per vehicle type.
• Check GPS/cellular coverage.
• Review driver-data handling for fairness/compliance.
• Re-check every screw terminal and header after the first week — thermal cycling loosens connections that felt tight on day one.
• Log pack voltage. When resting voltage after a full charge drops below about 4.0 V, the cell is near end of life — replace it.
• Keep the broker and dashboard containers patched, and rotate device credentials at least once a year.
• Recalibrate at the interval given in the calibration section, and keep the constants in a text file next to the firmware — not only in flash.
• Keep a short logbook of firmware versions and what changed. Six months later you will not remember why that constant is 1.083.

Future Improvements & Upgrades

A working v1 is a platform, not a finish line. These are the upgrades that add the most capability for the least rework.

• Add fuel-efficiency and eco-driving scoring.
• Add crash detection and emergency alerting.
• Integrate maintenance scheduling from DTCs/mileage.
• Add usage-based-insurance scoring (lawfully).
• Design a proper PCB. Once the breadboard version has run for a month, moving to a two-layer board removes the intermittent-contact failures that dominate prototype faults.
• Add over-the-air firmware updates so you never have to physically reach a deployed node again.
• Add persistent local storage (microSD or the on-chip flash) so a network outage does not create a hole in your data.
• Move configuration out of the source: a captive-portal setup page or a JSON config file makes the build reusable without a recompile.
• Add a battery and solar option so the unit survives a power cut and can be sited away from a socket.
• Write a small test harness that feeds synthetic sensor values through the decision logic, so you can validate thresholds without physically triggering the event.

Frequently Asked Questions

References & Learning Resources

These are the primary sources worth reading in full. Manufacturer datasheets always outrank forum posts when the two disagree.

1. OBD-IIReference
2. Diagnostic trouble codes (DTCs)Reference
3. Fleet telematicsReference
4. Usage-based insuranceReference
5. ELM327 OBD interfaceReference