Embedded / Case study

BatteryDisplay

A connected monitoring prototype that captures battery data on a CAN bus and makes it available at the bench and in a browser.

My focus: Electronics, firmware & system integration
Tools & scope: ESP32 · CAN · BLE · .NET · Linux
Project: Working prototype

01 / The brief

A clearer view of a battery test.

When a battery fault is hard to reproduce, the readings around it matter. BatteryDisplay captures selected CAN signals for a local display, a removable log, and remote monitoring in a browser.

For my engineering thesis, I designed the carrier PCB and enclosure, built the ESP32 firmware, and integrated the proxy, server, and diagnostic interfaces. I tested the complete chain on a bench with recorded and synthetic CAN traffic.

CAN bus: 250 kbit/s
Catalogue: 22 message definitions
Local interface: 20 × 4 LCD and microSD

02 / Architecture

From a CAN frame to a browser reading.

The ESP32 handles acquisition and local monitoring. The Raspberry Pi takes care of the network path.

InputBattery CAN bus250 kbit/s

CAN → acquisitionBatteryDisplayESP32

Local outputLCD + microSD

Direct BLEWindows diagnostics

BLE → decodeRaspberry Pi.NET proxy

HTTP → publishFlask serverTelemetry buffer

JSON API → displayBrowserLive dashboard

Telemetry flows left to right; local display and logging operate independently of the proxy.

How each stage works

CAN · 250 kbit/s

Battery CAN bus

Provides the incoming frames. A PCAN adapter replays recorded or synthetic traffic for bench tests.
ESP32 · BLE

BatteryDisplay

Receives and caches the latest frames, then exposes them and their message definitions over Bluetooth.
.NET · HTTP

Raspberry Pi proxy

Caches the definitions, polls for frames, decodes their signals, and publishes telemetry samples.
Flask · JSON API

Browser dashboard

Displays the latest decoded readings from a short buffer held in server memory.

From the ESP32 · Local

LCD and microSD

Selected readings appear on the 20 × 4 LCD and are logged to removable storage, independently of the proxy.

From the ESP32 · Direct BLE

Windows diagnostics

A .NET desktop client inspects known CAN identifiers, message definitions, and the latest raw frames.

03 / Bench demo

The complete chain in operation.

The assembled device sits beside the bench supply while the dashboard receives readings through the Raspberry Pi proxy.

Silent footage, 9 seconds. Playback starts on request.

Powered prototype and live dashboard during a bench test.

04 / Hardware

Designed, printed, and assembled.

A carrier PCB connects the ESP32, CAN interface, display, buttons, and microSD inside a two-part, 3D-printed enclosure.

Exploded CAD view showing the cover, two buttons, display, PCB, and base of the enclosure — Enclosure design The display and controls mount to the lid, with the carrier board inside the base.

KiCad 3D view of the custom carrier PCB, showing the ESP32 footprint and peripheral connectors — Carrier PCB design KiCad 3D view of the custom board, with the ESP32 footprint and connectors for the peripheral modules.

05 / Engineering decision

Rebuild the session after a power cycle.

The proxy caches message definitions for decoding. After a Bluetooth session failure, it reconnects and restores those definitions before polling resumes, picking up the device’s current catalogue.

One documented bench trial

I powered the device off and back on while leaving the proxy running. Its journal recorded these milestones after failure detection.

BLE connection restored: 12 s
Definitions restored and polling resumed: 89 s
First successful HTTP publication observed: 117 s

The proxy recovered without a service restart. This trial covered BLE recovery after a device power cycle. Network outages and sample retention during the interruption were outside its scope.