Tire Pressure Monitor.

Project Overview

Puts the true pressure of every tyre on a live dashboard and warns the moment one goes low — catching the slow leak before it becomes a blowout.

A tyre losing pressure is one of the most common and most dangerous faults on a vehicle, and the most invisible: a tyre can be dangerously under-inflated and look completely normal, and by the time a driver feels it in the steering the damage — uneven wear, overheating, a potential blowout at speed — is already being done. Under-inflation also quietly wastes fuel and shortens tyre life. This project builds a wireless tyre-pressure monitoring system (TPMS) that measures the actual pressure in every tyre and surfaces it live on a dashboard, warning the moment one drops — turning an invisible, gradual hazard into an obvious, early alert.

The system is inherently wireless, because the sensors ride on a spinning wheel and cannot be wired to the dash. Each tyre carries a small battery-powered sensor (on the valve stem or inside the tyre) that measures pressure — and usually temperature, since heat and pressure move together — and transmits it by radio to a receiver in the cabin. The receiver, built here around an ESP32, listens to all the wheel sensors, shows each tyre's pressure on a display, and alerts when any tyre falls below a safe threshold or when a fast pressure drop signals a rapid leak.

The value is early warning of exactly the fault drivers cannot otherwise see. A slow puncture is caught while it is still a top-up, not a blowout; a correctly-inflated set of tyres saves fuel and lasts longer; and a sudden loss is flagged immediately. It is honest that a real automotive TPMS is a safety-regulated system and that the wheel sensors, their batteries and their radio protocol are the hard part (this project focuses on the receiver, alerting and dashboard, working with TPMS sensor modules). But as a wireless per-tyre pressure monitor with low-pressure and rapid-leak alerting, it addresses a leading, invisible cause of tyre failure with exactly the live visibility a driver lacks.

What this project does

• Receives wireless pressure (and temperature) from each wheel sensor
• Shows every tyre's live pressure on a dashboard
• Alerts on low pressure (below a safe threshold)
• Alerts on a rapid pressure drop (fast leak/blowout risk)
• Flags high tyre temperature
• Turns an invisible, gradual hazard into an early warning
• Helps save fuel and extend tyre life through correct inflation

Real-World Applications

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

Features & Capabilities

• Wireless per-tyre pressure + temperature sensing
• Live dashboard of all four (or more) tyres
• Low-pressure and rapid-leak alerting
• High-temperature warning
• Per-sensor battery/signal awareness
• Configurable thresholds per axle/vehicle
• Honest about safety-regulated TPMS and sensor/radio complexity

Difficulty, Time & Required Skills

Skills you should have (or will pick up)

• Wireless sensor reception (TPMS sensors / sub-GHz or BLE)
• Pressure/temperature interpretation and thresholds
• Rapid-drop (rate-of-change) leak detection
• Dashboard display and alerting
• Per-sensor health (battery/signal) handling

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: ₹10,520, 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 1280 mA. With a 1.5× design margin the supply should deliver at least 2000 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

• Wheel sensors are wireless — you receive their radio packets; you do not wire to the wheels.
• Match the receiver front-end to the sensors' protocol (sub-GHz or BLE) and pairing/IDs.
• Drive a display for the live per-tyre dashboard and a buzzer/LED for alerts.
• Power from ignition-switched 12 V via a regulator; a small backup cell rides through cranks.
• Map each sensor ID to its wheel position (front-left, etc.) during pairing.

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

The problem TPMS solves is one of invisibility. Tyre pressure cannot be judged by eye — a radial tyre can lose a large fraction of its pressure and still look inflated — so drivers routinely run under-inflated without knowing. Under-inflation flexes the sidewall more, which builds heat, which is what actually destroys a tyre: overheating leads to tread separation and blowouts, and blowouts at speed cause loss of control. It also increases rolling resistance (wasting fuel) and causes uneven wear (shortening tyre life). A monitor that simply makes the real pressure visible, continuously, removes the invisibility that makes the hazard so dangerous.

Because the sensors live on rotating wheels, the system is fundamentally wireless. Each wheel carries a self-contained sensor — a pressure transducer, usually a temperature sensor, a small battery, and a radio — that periodically transmits its reading. Direct TPMS (per-wheel sensors) is what gives a true reading of each individual tyre; the receiver's job is to listen to all of them, associate each sensor's unique ID with its wheel position, and present the fleet of readings coherently. This is why pairing/learning sensor IDs to positions is a core part of setup.

The receiver turns readings into two kinds of alert, because two different failures matter. The first is an absolute low threshold: any tyre below the vehicle's recommended pressure (with a margin) is flagged — this catches the slow leak and chronic under-inflation. The second is a rapid rate of change: a pressure that is falling fast signals an active leak or an imminent blowout, and deserves an immediate, louder warning even before it crosses the absolute threshold. Watching both the level and the slope of pressure is what separates a useful safety device from a gauge. Temperature is monitored alongside because an overheating tyre is itself a danger sign.

The design is honest about scope and safety. A production automotive TPMS is a safety-regulated system (mandated on many vehicles) with certified sensors, robust radio protocols, and integration into the vehicle — and the genuinely hard, safety-relevant engineering is in the wheel sensors: their pressure accuracy, battery life over years, sealing, balancing, and interference-resistant radio. This project focuses on the receiver, alerting logic and dashboard, working with existing TPMS sensor modules rather than reinventing the certified wheel unit. Within that honest frame, it delivers the core safety value: continuous, per-tyre visibility and early warning of both slow leaks and fast failures — exactly the information a driver cannot otherwise obtain about one of the most common causes of serious tyre failure.

The maths behind it

Low-pressure alert

For each tyre i with recommended pressure P_rec:

  low if  P_i < P_rec × (1 − m)     (e.g. m = 0.20 → 20% low)

Catches slow leaks and chronic under-inflation before damage.

Rapid-leak (rate) alert

Track pressure slope over a short window:

  dP/dt = (P_now − P_prev) / Δt
  fast-leak if  dP/dt < −R_leak   (falling quickly)

Warns of an active leak/blowout even before the absolute
threshold is crossed.

Temperature / heat check

Heat destroys under-inflated tyres:

  high if  T_i > T_max

Rising temperature with falling pressure is a strong danger
sign — flag it prominently.

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. Pair the wheel sensors

   Fit or use TPMS sensors on each tyre and pair their IDs to wheel positions (front-left, front-right, rear-left, rear-right) in the receiver.

   Set each tyre's recommended pressure per the vehicle placard.

2. Build the receiver + dashboard

   Wire the receiver front-end, display and buzzer/LED to the ESP32; power from ignition-switched 12 V via a regulator with a small backup cell.

3. Set thresholds and alerts

   Configure the low-pressure margin, rapid-drop rate, and high-temperature limit; verify alerts fire clearly.

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. Receive, map and judge each tyre

   Receive each sensor's pressure/temperature, map it to a wheel position, and flag low pressure, a rapid drop, or high temperature.

   cpptpms.ino Copy Download

   struct Tyre { float p, t, pPrev; uint32_t tPrev; };
   Tyre tyre[4];                       // FL, FR, RL, RR
   
   const float P_REC = 2.2f;           // bar, recommended
   const float LOW_MARGIN = 0.20f;     // 20% low
   const float R_LEAK = 0.15f;         // bar/sec rapid drop
   const float T_MAX  = 85.0f;         // degC
   
   int alertsFor(int i){
     Tyre& y = tyre[i];
     int a = 0;
     if (y.p < P_REC * (1 - LOW_MARGIN)) a |= 1;      // low pressure
     float dt = (millis() - y.tPrev) / 1000.0f;
     if (dt > 0 && (y.p - y.pPrev)/dt < -R_LEAK) a |= 2; // fast leak
     if (y.t > T_MAX) a |= 4;                         // hot
     y.pPrev = y.p; y.tPrev = millis();
     return a;                                        // bitmask of alerts
   }

   Tyre tyre[4]; // FL, FR, RL, RREach sensor is mapped to a wheel position so an alert names the actual tyre — the driver knows which one to check.

   if (y.p < P_REC * (1 - LOW_MARGIN)) a |= 1; // low pressureThe absolute low-threshold check catches the slow leak and chronic under-inflation that are invisible by eye.

   if (dt > 0 && (y.p - y.pPrev)/dt < -R_LEAK) a |= 2; // fast leakThe rate-of-change check flags an active fast leak or blowout risk even before the absolute threshold is crossed.

   if (y.t > T_MAX) a |= 4; // hotA hot tyre — often the consequence of under-inflation — is itself a danger sign and flagged.

2. Display and alert

   Show all tyres' live pressures/temperatures and raise a clear, escalating alert (louder/faster for a rapid leak) that names the affected wheel.

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.

/* ═══════════════════════════════════════════════════════════════
   Tyre-Pressure Monitor (TPMS) — ESP32 receiver + dashboard

   Receives wireless pressure/temperature from per-wheel sensors,
   maps each to a wheel position, and alerts on low pressure, a rapid
   drop (fast leak) or high temperature. Live per-tyre dashboard.
   ══════════════════════════════════════════════════════════════════ */

#include <Preferences.h>

struct Tyre { uint32_t id; float p, t, pPrev; uint32_t tPrev; bool seen; };
Tyre tyre[4];                              // FL, FR, RL, RR
const char* POS[4] = {"FL","FR","RL","RR"};

const float P_REC = 2.2f;                  // recommended, bar
const float LOW_MARGIN = 0.20f;
const float R_LEAK = 0.15f;                // bar/sec
const float T_MAX  = 85.0f;
const uint32_t STALE_MS = 300000;          // 5 min without a packet

int wheelOf(uint32_t id){                  // sensor ID -> paired position
  for (int i=0;i<4;i++) if (tyre[i].id==id) return i;
  return -1;
}

int judge(int i){
  Tyre& y = tyre[i]; int a = 0;
  if (y.p < P_REC*(1-LOW_MARGIN)) a |= 1;                 // low
  float dt = (millis()-y.tPrev)/1000.0f;
  if (dt>0 && (y.p-y.pPrev)/dt < -R_LEAK) a |= 2;         // fast leak
  if (y.t > T_MAX) a |= 4;                                // hot
  y.pPrev = y.p; y.tPrev = millis();
  return a;
}

void onPacket(uint32_t id, float p, float t){
  int i = wheelOf(id);
  if (i < 0) return;                       // unknown/other vehicle
  tyre[i].p = p; tyre[i].t = t; tyre[i].seen = true;
  int a = judge(i);
  drawTyre(i, p, t, a);                     // update dashboard cell
  if (a & 2) alert(URGENT, POS[i], "FAST LEAK");
  else if (a & 1) alert(WARN, POS[i], "LOW");
  else if (a & 4) alert(WARN, POS[i], "HOT");
}

void checkStale(){
  for (int i=0;i<4;i++)
    if (tyre[i].seen && millis()-tyre[i].tPrev > STALE_MS)
      alert(WARN, POS[i], "NO SIGNAL");     // sensor battery/fault
}

void setup(){
  Serial.begin(115200);
  loadPairing(tyre);                        // sensor IDs <-> positions
  receiverInit(onPacket);                   // sub-GHz/BLE front-end
  displayInit();
}

void loop(){
  receiverPoll();                           // dispatches onPacket()
  checkStale();
  delay(200);
}

Configuration & Calibration

Configuration steps

• Pair each sensor ID to a wheel position and set the recommended pressure per axle.
• Configure the low-pressure margin, rapid-drop rate and high-temperature limit.
• Configure alert escalation (gentle for low, urgent for fast leak).
• Configure stale-sensor (no-signal/battery) handling.

Calibration procedure

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

1. Pressure accuracy

   Cross-check sensor readings against a known-good gauge at a couple of pressures.

2. Thresholds

   Set the low margin and rapid-drop rate so real problems alert without nuisance warnings from normal temperature-driven pressure changes.

3. Pairing/position

   Confirm each alert names the correct wheel by deliberately deflating one tyre slightly.

Network Architecture & Connectivity

Communication protocol

Wheel sensors broadcast pressure/temperature to the in-cabin receiver; for fleets the receiver can forward per-tyre status to a platform.

Message contract between the device and the broker.

Cloud platform configuration

For fleets, a platform tracks every tyre across every vehicle so under-inflation and leaks are managed before failures.

Dashboard setup

A per-vehicle tyre view with pressures, temperatures and alerts; a fleet roll-up of tyre health.

Mobile app integration

Low-pressure and fast-leak alerts naming the vehicle and wheel.

Security considerations

• Accept only paired sensor IDs; ignore foreign/spoof packets.
• Alerting is local and immediate; cloud is optional for fleets.
• Tyre data is low-sensitivity but per-vehicle — secure fleet uploads.

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 dashboard of every tyre's pressure and temperature, with clear low/fast-leak/hot alerts naming the affected wheel.

{
  "FL": { "bar": 2.2, "degC": 34, "state": "ok" },
  "FR": { "bar": 2.2, "degC": 35, "state": "ok" },
  "RL": { "bar": 1.6, "degC": 48, "state": "LOW+HOT" },
  "RR": { "bar": 2.1, "degC": 36, "state": "ok" }
}

Rear-left is low and running hot — flagged early, before the under-inflation could overheat the tyre into a blowout; the other three read normal.

Troubleshooting: Common Errors & Fixes

Performance Optimisation

• Judge both absolute pressure and its rate of change for slow and fast leaks.
• Map every sensor to a position so alerts name the wheel.
• Flag stale sensors (battery/fault) as a real condition.
• Escalate urgency: fast leak louder than a low warning.
• 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

• This aids the driver; a production automotive TPMS is a safety-regulated system — treat this as a monitor, not a certified replacement.
• Fit wheel sensors correctly and re-balance wheels as needed; a poorly fitted sensor is a hazard.
• Do not let the display distract driving; alerts should be glanceable/audible.
• Correct inflation is a safety and fuel matter — act on low readings promptly.
• 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.
• 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

• Replace wheel-sensor batteries before they die; act on no-signal flags.
• Re-verify pressure accuracy periodically against a gauge.
• Re-pair positions after tyre rotation.
• Keep recommended pressures updated for load/vehicle.
• 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 automatic tyre-rotation-aware position learning.
• Add temperature-compensated pressure (cold-equivalent).
• Add fleet trend analytics (slow-leak detection over days).
• Add tread-wear estimation from long-term pressure/temperature.
• 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. Tyre-pressure monitoring systemReference
2. Tyre safety and under-inflationReference
3. Blowout / tread separationReference
4. ESP32Espressif
5. Rolling resistance and fuel economyReference