Industrial IoT Fleet Telemetry Platform

The Challenge

Our client operated a fleet of 5,000+ delivery vehicles with no real-time visibility. Dispatchers worked from phone calls and driver check-ins. The operations center had no live map, no speed or fuel data, and no way to detect vehicle issues without a driver calling in. Route optimization ran on stale data 24 hours old.

They needed sub-second telemetry latency, a dashboard that could render thousands of live vehicle markers without dropping frames, and hardware rugged enough to survive daily use in commercial vehicles.

The Firmware

We developed custom C++ firmware for ESP32-based tracking units. The hardware requirements were tight: the unit had to survive vehicle power-on/power-off cycles (including the load dump transient on 12V automotive systems), operate across a -20°C to +70°C temperature range, and consume minimal current when the vehicle was parked.

Key firmware decisions:

Binary payload format. We designed a compact 28-byte binary telemetry packet rather than JSON or any text format. At a 1-second reporting interval across 5,000 vehicles, the difference between a 28-byte binary message and a 200-byte JSON equivalent is significant: ~140 KB/s vs. ~1 MB/s ingested. This drove cost and infrastructure sizing for the entire backend.

Adaptive reporting rate. The firmware reported at full 1-second rate when the vehicle was moving above 5 km/h, dropped to 30-second heartbeats when stationary, and went silent (storing locally) when cellular signal was below threshold. Stored-and-forward replay on reconnection ensured no data loss during tunnel transits or poor-coverage zones.

OTA firmware updates. We implemented HTTPS-based OTA using the ESP-IDF esp_https_ota component. Rollback on failed boot is automatic - the bootloader checks a valid-boot counter and reverts to the previous partition if the new firmware panics twice on startup.

The Cloud Pipeline

The ingest service ran on a cluster of Node.js workers subscribed to our MQTT broker. Each worker decoded the binary telemetry format, enriched records with vehicle metadata from Postgres, and wrote them to TimescaleDB.

At 5,000 vehicles × 1 message/second, we ingested ~43M rows per day. Timescale’s automatic partitioning kept insert and query performance stable. The “last 5 minutes” queries used by the live map read from a continuously-updated materialized view rather than scanning raw rows.

The Dashboard

The frontend was SvelteKit with a WebGL-based map renderer (MapLibre GL JS). Rendering 5,000 animated markers in a DOM-based map was not viable - frame rates collapsed above a few hundred markers. WebGL pushed the rendering work to the GPU and maintained 60fps even with the full fleet visible.

Vehicle status coloring. Markers were colored by status: moving (green), stationary-engine-on (amber), stationary-engine-off (grey), not-reporting (red). Dispatchers could scan the map and identify problem areas without clicking individual vehicles.

Alert surface. Fuel-below-threshold and speeding events appeared as a sidebar list with vehicle jump-to on click. Dispatchers previously learned about these by phone call; now they appeared within 2 seconds of the event occurring on the vehicle.

The Results

• 99.97% firmware uptime across the fleet over the first six months.
• 80% reduction in cellular data costs compared to the client’s previous JSON-based tracking solution.
• Sub-second UI updates confirmed by end-to-end latency measurement from GPS fix to marker update on screen.
• Route planning cycle time cut from 24 hours (batch, next-day) to real-time.

If you’re building a product that crosses firmware and cloud, we’d like to hear about it.