Omni Mechworks

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.

20240621 211445
Bench-testing the custom dash: ESP32 display module running my LVGL-based UI, with firmware and debugging environment open on the main screen.

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.

dash
Close-up of the prototype UI: custom LVGL layout with large speed readout, rev bar, and status tiles ready to receive live bike data.

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.