Custom ESP32 Digital Dash for Motorbike
A custom digital instrument cluster for a modified motorbike, built around an ESP32-based display module with a fully programmable user interface.
Summary
I set out to replace a bulky analogue motorbike dash with a compact, information-dense digital display. Using a LilyGo ESP32 module with an integrated screen, I built a working prototype UI driven by LVGL and brought the display up from raw firmware level. The project is currently paused at the point just before custom PCB and enclosure design.
- Embedded firmware development on ESP32
Low-level display driver integration and graphics (LVGL)
Requirements definition and signal-conditioning concept design
UI layout for glanceable, safety-critical information
Trade-off decision: custom solution vs off-the-shelf hardware
Context
The bike was undergoing a major conversion, and the original instrument cluster was no longer usable. It was a large analogue unit moulded into the OEM fairings, and it relied on electronics that didn’t suit the new layout.
Commercial “universal” dashes were available, but they all shared the same limitations:
Mostly simple LEDs and icons with limited numerical data
Fixed layouts that didn’t match how I wanted to read information
No way to customise hierarchy or add extra parameters
I wanted a dash that behaved more like a modern automotive display: clear speed and RPM, but also battery, coolant, fuel and status indicators laid out logically, all in a compact package that suited the new front end.
Design & Iterations
Phase 1 – Concept & Hardware Selection
I started by defining what the dash should do:
Replace the OEM cluster with a smaller, standalone unit
Display speed, RPM, battery, coolant, fuel and trip/odometer
Provide indicator, high-beam and neutral states in a clearer, more flexible way than simple icons
After researching options, I chose a new LilyGo ESP32 module with an integrated flush-mount display. It gave me:
Enough compute for real-time updates
An all-in-one form factor that could drop into a custom housing
Access to the ESP32 ecosystem for firmware and connectivity
At this stage I also mapped out the bike’s existing signals and identified what would be needed in a breakout board: voltage level shifting, filtering, and safe interfacing between the bike loom and the microcontroller.
Phase 2 – Display Bring-Up & Firmware Exploration
Because the module was new to market, there were very few real examples and almost no polished libraries. Most of the work had to happen at the firmware and driver level.
Key steps:
Studied the display controller datasheet and sparse example projects
Brought up the screen from scratch: initialisation, buffer writes and clear commands
Experimented with the device’s communication protocol and timing until I had a stable image
This phase significantly deepened my understanding of how microcontrollers talk to TFT displays at a byte/bit level, rather than simply relying on high-level abstractions.
Phase 3 – UI Prototyping with LVGL
Once the display was stable, I integrated LVGL (Light and Versatile Graphics Library) to handle the graphics layer.
I designed a modular UI that included:
A horizontal rev bar that brightened and dimmed with RPM
Large numeric speed readout
Structured cells for fuel level, battery SOC, coolant and oil information
Areas reserved for trip/odometer and warning indicators
At this point the dash behaved like a fully mocked-up cluster: the layout was in place, elements were animated, and the design was ready for live data to be connected.
Phase 4 – Scope Limitations & Interim Solution
To move from a bench prototype to something rideable, the next steps were:
Designing and manufacturing the signal-conditioning breakout PCB
Packaging the module and board in a sealed, vibration-resistant housing
Integrating and testing on the bike
At the same time, I needed to complete the wider motorbike build. The realistic assessment was that doing a full custom electronics package would delay the project significantly. I made a pragmatic call to install a basic aftermarket dash so the bike could be finished and used.
The custom digital dash is therefore parked at a mature prototype stage, with a clear plan for how to complete it in a future iteration
Final / Planned Architecture
The current best architecture for the system is:
Controller
ESP32-based LilyGo module as the main processing unit and display driver.
Handles all signal processing, UI updates and any future connectivity features.
Signal Interface (planned)
Custom breakout PCB between bike harness and ESP32.
Level shifting and protection for speed sensor, RPM, indicator, neutral, high-beam and power signals.
Connectors and headers arranged for easy installation and serviceability.
Software & UI
LVGL-based UI with modular widgets for each data type (speed, RPM, fuel, battery, coolant, warnings).
Separation between data layer and presentation layer so the interface can be updated without rewiring signals.
Designed specifically for quick, at-a-glance reading while riding.
Mechanical Packaging (planned)
Compact, sealed enclosure around the display module and PCB.
Weather-resistant, vibration-tolerant mounting at the bike’s cockpit.
Provision for future revisions without redesigning the entire housing.
This architecture keeps the noisy, vehicle-side wiring isolated on the breakout board while the ESP32 and display remain a reusable, modular core.
Skills & Takeaways
Skills demonstrated
Embedded development on ESP32 and similar microcontrollers
Low-level display driver integration and firmware debugging
LVGL-based UI design for constrained, safety-critical displays
Signal-conditioning concept design for automotive environments
Requirements capture and architecture planning for custom electronics
Key lessons
- New or poorly documented hardware often requires working directly at the protocol and register level; that effort pays off in deeper understanding and more robust systems.
Decoupling the UI from the signal interface (via a dedicated breakout board) makes the system more maintainable and easier to iterate on.
Balancing ambition with project scope is important: sometimes using an interim off-the-shelf component is the right decision to keep the larger project moving.
Even when a project pauses before full deployment, the knowledge gained—here in firmware, display control, and embedded UI design—transfers directly into future client and product work.