EV Range & Trip Logger.

Project Overview

Logs an electric vehicle's real energy use trip by trip and turns it into an honest, condition-aware range estimate you can actually trust.

Range anxiety is the defining worry of electric driving, and it is made worse by range numbers you cannot trust: the dashboard's guess-o-meter swings wildly, the official range assumes gentle conditions, and neither tells you what your car will really do on this route, in this weather, driven the way you drive. This project builds a logger that measures an EV's real energy consumption trip by trip and uses that history to produce an honest, condition-aware range estimate — replacing an optimistic single number with evidence from how the car is actually used.

The system reads the vehicle's energy and driving data (via OBD-II/CAN where available, plus GPS for distance and speed) and logs each trip: energy used (kWh), distance, average speed, and the conditions that dominate EV consumption — chiefly temperature (cold weather and cabin heating slash range), speed (aerodynamic drag rises sharply with speed), and terrain (climbs cost energy, regen returns some). From this it computes real-world efficiency (Wh/km or km/kWh) and, crucially, how that efficiency varies with conditions.

The payoff is a range estimate grounded in reality: given the current battery state of charge and the conditions and driving style at hand, how far can this car actually go — with the honesty to say the estimate is lower in the cold, at motorway speed, or up a long climb. It is honest that OBD/CAN access and signals vary by EV (some expose rich data, some little), that this reads and logs rather than interfering with the vehicle, and that it complements — not replaces — the car's own systems. But as a real-consumption trip logger that turns measured history into a trustworthy, condition-aware range estimate, it attacks range anxiety at its root: not with a more optimistic number, but with an honest one.

What this project does

• Logs each trip: energy used, distance, speed, conditions
• Computes real-world efficiency (Wh/km, km/kWh)
• Learns how consumption varies with temperature, speed and terrain
• Produces an honest, condition-aware range estimate from state of charge
• Records regen and climb/descent effects on energy
• Replaces an optimistic single number with measured evidence
• Reads/logs without interfering with the vehicle

Real-World Applications

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

Features & Capabilities

• Trip-by-trip energy/distance/condition logging
• Real-world efficiency computation
• Condition-aware (temperature/speed/terrain) range model
• Honest range estimate vs current state of charge
• Regen and elevation awareness
• History and trends for driving/planning
• Honest about OBD/CAN variability and read-only scope

Difficulty, Time & Required Skills

Skills you should have (or will pick up)

• OBD-II/CAN reading of EV energy/SoC signals (where available)
• Energy/efficiency computation (kWh, Wh/km)
• Condition modelling (temperature/speed/terrain vs consumption)
• Range estimation from state of charge and conditions
• Trip logging and trend analysis

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: ₹3,160, 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 326.5 mA. With a 1.5× design margin the supply should deliver at least 500 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 OBD-II/CAN read-only for energy, state of charge and speed where the EV exposes them.
• Add GPS for distance/speed/elevation as a backstop and for terrain awareness.
• Add an ambient temperature sensor — temperature is the dominant range factor.
• Log trips to SD and show live range/efficiency on the OLED.
• Read and log only; never write to or interfere with the vehicle.

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

Range anxiety is really trust anxiety. An EV usually has plenty of range for the journey; what it lacks is a number the driver believes. The dashboard estimate is jumpy and optimistic, the rated range assumes benign conditions, and neither reflects this car, route, weather and driver. The cure is not a cleverer guess from the same thin inputs — it is grounding the estimate in measured real consumption, so the number comes from evidence rather than optimism.

That starts with honest per-trip measurement. For each trip the logger records the energy actually used (kWh drawn from the battery), the distance covered, and the conditions in force. Dividing energy by distance gives real-world efficiency — Wh/km or km/kWh — which is the true, personal consumption of this vehicle as driven, not a laboratory figure. Accumulating this across many trips builds a picture far more trustworthy than any single dashboard reading.

The insight that makes the estimate useful is that EV consumption is dominated by a few conditions, and the model must be aware of them. Temperature is the biggest: cold weather raises battery internal resistance and, more importantly, cabin heating draws heavily from the same battery, so winter range can fall dramatically. Speed is next: aerodynamic drag rises with the square of speed, so motorway cruising consumes far more per kilometre than town driving. Terrain matters too: climbs cost energy while descents return some through regenerative braking. A logger that records efficiency alongside these conditions can learn how consumption varies with them — cold vs warm, fast vs slow, hilly vs flat — instead of pretending consumption is constant.

From that model comes the deliverable: an honest, condition-aware range estimate. Given the current state of charge and the conditions and driving at hand, the logger estimates how far the car can really go — and, crucially, has the honesty to say the number is lower in the cold, at speed, or up a climb, rather than flattering the driver. That honesty is the point: a range estimate you can trust because it is built from what your car actually does. The design is candid about its constraints — OBD/CAN signal availability varies widely between EVs (some expose rich battery data, others almost none), GPS provides a backstop for distance/speed/elevation, everything is read-only and non-interfering, and it complements rather than replaces the vehicle's own systems. Within that frame it does the one thing that actually reduces range anxiety: turn measured history into a range number worth believing.

The maths behind it

Real-world efficiency

Per trip:

  efficiency (Wh/km) = energy_used_Wh / distance_km
  range-equiv (km/kWh) = distance_km / energy_used_kWh

This is the car's TRUE consumption as driven — not a rated
lab figure.

Condition-aware consumption

Consumption depends on conditions:

  E(v,T,grade) ≈ E_base
    × f_speed(v)     (drag ~ v²  → higher at speed)
    × f_temp(T)      (cold + heating → much higher)
    × f_grade(grade) (climb costs; regen returns some)

Learned from logged trips, not assumed constant.

Honest range estimate

range_km = (SoC × usable_kWh) / efficiency(conditions)

Use the efficiency for the CURRENT conditions, so the estimate
falls honestly in cold / at speed / uphill instead of
flattering the driver.

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 energy and conditions (read-only)

   Read EV energy/SoC/speed via OBD-II/CAN where available; add GPS for distance/speed/elevation and an ambient temperature sensor.

   Handle EVs that expose little data by leaning on GPS/temperature.

2. Log trips and compute efficiency

   Accumulate energy, distance and conditions per trip; compute real-world efficiency and store the trip.

3. Build the condition-aware estimate

   Learn how efficiency varies with temperature, speed and terrain, and estimate range from the current state of charge and conditions — honestly.

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. Accumulate a trip and its conditions

   While driving, accumulate energy used and distance, and record the dominant conditions (temperature, speed, elevation change).

   pythontrip.py Copy Download

   class Trip:
       def __init__(self):
           self.kwh = 0.0; self.km = 0.0
           self.temp_sum = 0.0; self.samples = 0
           self.climb_m = 0.0; self.v_sum = 0.0
   
       def sample(self, power_kw, dt_h, dist_km, temp_c, dv_elev_m, speed):
           self.kwh += power_kw * dt_h          # energy actually drawn
           self.km  += dist_km                  # distance covered
           self.temp_sum += temp_c; self.samples += 1
           if dv_elev_m > 0: self.climb_m += dv_elev_m   # climbs cost energy
           self.v_sum += speed
   
       def summary(self):
           n = max(self.samples, 1)
           eff = (self.kwh * 1000.0) / self.km if self.km else 0   # Wh/km
           return {
               "kwh": round(self.kwh, 2), "km": round(self.km, 1),
               "wh_per_km": round(eff, 0),
               "avg_temp": round(self.temp_sum / n, 1),
               "avg_speed": round(self.v_sum / n, 1),
               "climb_m": round(self.climb_m, 0),
           }

   self.kwh += power_kw * dt_h # energy actually drawnEnergy is the real quantity used — integrated from battery power over time — the basis of trustworthy efficiency, not a rated figure.

   eff = (self.kwh * 1000.0) / self.km if self.km else 0 # Wh/kmReal-world efficiency is energy over distance — the car's true consumption as actually driven.

   self.temp_sum += temp_c; self.samples += 1Temperature is logged with the trip because it is the single biggest driver of EV consumption.

   if dv_elev_m > 0: self.climb_m += dv_elev_m # climbs cost energyClimbs are recorded because terrain materially changes energy use — the estimate must be terrain-aware.

2. Estimate range honestly for the conditions

   From the current state of charge and the efficiency for the present conditions, estimate range — and let it fall honestly in the cold, at speed, or uphill.

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.

#!/usr/bin/env python3
"""
EV Range & Trip Logger

Logs real per-trip energy/distance/conditions, computes real-world
efficiency, learns how consumption varies with temperature/speed/terrain,
and produces an HONEST, condition-aware range estimate from state of charge.
Read-only: reads and logs, never interferes with the vehicle.
"""
import statistics, json

USABLE_KWH = 40.0                        # battery usable capacity

class EfficiencyModel:
    """Learns Wh/km bucketed by the dominant conditions."""
    def __init__(self):
        self.buckets = {}                # (temp_band, speed_band) -> [wh/km,...]

    @staticmethod
    def bands(temp_c, speed):
        tb = "cold" if temp_c < 10 else "mild" if temp_c < 25 else "warm"
        sb = "town" if speed < 45 else "mixed" if speed < 80 else "motorway"
        return (tb, sb)

    def learn(self, trip):
        key = self.bands(trip["avg_temp"], trip["avg_speed"])
        self.buckets.setdefault(key, []).append(trip["wh_per_km"])

    def wh_per_km(self, temp_c, speed):
        key = self.bands(temp_c, speed)
        hist = self.buckets.get(key)
        if hist:
            return statistics.median(hist)          # this car, these conditions
        # fall back to any history, then a sane default
        allv = [v for h in self.buckets.values() for v in h]
        return statistics.median(allv) if allv else 160.0

def honest_range_km(model, soc_frac, temp_c, speed):
    wh_km = model.wh_per_km(temp_c, speed)          # condition-aware
    available_wh = soc_frac * USABLE_KWH * 1000.0
    est = available_wh / wh_km
    return round(est), round(wh_km)                 # km, Wh/km used

def log_trip(model, trip, path="trips.jsonl"):
    model.learn(trip)                               # update the model
    with open(path, "a") as f:
        f.write(json.dumps(trip) + "\n")           # keep the evidence

if __name__ == "__main__":
    model = EfficiencyModel()
    # ... each completed trip:
    #   trip = Trip(...).summary(); log_trip(model, trip)
    # live estimate for current conditions:
    km, wh = honest_range_km(model, soc_frac=0.62, temp_c=4, speed=95)
    print(f"Honest range ~{km} km at {wh} Wh/km "
          f"(cold + motorway → lower, and we say so)")

Configuration & Calibration

Configuration steps

• Configure the OBD/CAN signals available on your EV and the usable battery capacity.
• Configure GPS and temperature inputs; set condition bands (temp/speed) for the model.
• Configure trip start/stop detection and logging.
• Configure conservative rounding for the range estimate.

Calibration procedure

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

1. Energy accuracy

   Cross-check logged trip energy against the car's own trip energy or a full charge's known kWh.

2. Condition bands

   Verify efficiency really does separate across temperature and speed bands after a few varied trips.

3. Range honesty

   Compare estimated vs actual range achieved; tune to be honest/slightly conservative, not optimistic.

Network Architecture & Connectivity

Communication protocol

Trips are logged locally and can sync to a store for history/trends; the condition-aware model improves as trips accumulate.

Message contract between the device and the broker.

Cloud platform configuration

A store of real trips per vehicle powers honest range, efficiency trends and (for fleets) charging/scheduling insight.

Dashboard setup

Trip history, real efficiency vs conditions, and a range estimate you can trust.

Mobile app integration

Live condition-aware range and pre-trip range for a planned route/weather.

Security considerations

• Read-only vehicle access; never interfere.
• Trip/location data is personal — secure and minimise it.
• Local logging works offline; sync is optional.

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

A live, condition-aware range estimate plus a trip log of real energy, distance, efficiency and conditions.

{
  "km": 42.6,
  "kwh": 9.1,
  "wh_per_km": 214,
  "avg_temp": 4,
  "avg_speed": 95,
  "climb_m": 180,
  "range_estimate_km": 116,
  "note": "cold + motorway -> honest lower range"
}

A cold motorway trip logged at 214 Wh/km — far above a gentle-day figure — and the range estimate honestly reflects it rather than promising the rated number.

Troubleshooting: Common Errors & Fixes

Performance Optimisation

• Log real energy/distance per trip; compute true efficiency.
• Bucket efficiency by condition for an accurate estimate.
• Estimate range from state of charge honestly, not optimistically.
• Degrade gracefully when OBD signals are sparse.
• 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 and log only — never write to or interfere with the vehicle.
• Do not let the display distract driving; keep it glanceable.
• Trip and location data are personal — secure and minimise them.
• This complements the vehicle's own systems; do not rely on it as a sole safety-critical gauge.
• 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

• Keep logging trips so the condition model stays current.
• Re-check energy accuracy against known charges periodically.
• Update usable capacity as the battery ages (efficiency trends hint at health).
• Verify OBD/CAN signals after vehicle software updates.
• Re-check every screw terminal and header after the first week — thermal cycling loosens connections that felt tight on day one.
• Rotate the microSD card annually and keep an image of the working system. Cards used as loggers wear out silently.
• 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 route-based range (elevation/weather along a planned route).
• Add battery-health estimation from long-term efficiency/capacity trends.
• Add charging-cost and eco-driving coaching.
• Add fleet scheduling from real per-vehicle efficiency.
• 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. Electric vehicle rangeReference
2. Range anxietyReference
3. Regenerative brakingReference
4. Aerodynamic drag and speedReference
5. OBD-II / EV dataReference