I've owned my kit car (an MK Indy) for about 20 years. It's got a motorcycle engine (Honda Fireblade CBR900RR), is road-legal, and gets casual track-day use.
It has electronic paddle gear-shift and a removable steering wheel, but the spiral cable connecting the wheel to the car regularly got tangled on the paddles. So, I hatched a plan to make it wireless.
Before I go into the detail of the implementation, this is it in action...
The Idea
I have been tinkering with ESP32 devices for a while in various projects (home automation, lighting, media streaming etc), and my thought was to use a pair of these - one on the steering wheel and one in the car.
The initial requirements were simple: -
- No wires connecting the steering wheel to the car.
- No batteries in the steering wheel to worry about charging.
- Reliable gear-shifting.
The first prototype met these requirements, but it's grown somewhat since the initial idea.
The "Final" Product
I say "final", but this project is constantly evolving. However, this is what it looks like today...
It's a 3D printed case housing the controller and power module, a 128x64 OLED display and a pair of rotary encoders for control. Why does it need controls? It's evolved beyond the original requirements! It now has configuration menus...

...and a G-Force meter...

...and features such as GPS and data logging, so the display shows the status of those features.
This is the menu in action (together with an Easter Egg for those that grew up in the 1980s!): -
The Architecture
In terms of the architecture, this is a network of ESP32 controllers and peripherals. Below is a block diagram of the concept: -
Essentially there is a central control unit which is hard-wired to the car, the steering wheel which communicates over ESP-NOW, and a number of satellite controllers which send telemetry from sensors throughout the car.
The Steering Wheel
The steering wheel unit comprises: -
- A custom designed 3D enclosure.
- An ESP32-C3 Super Mini for the brain (chosen for low power consumption).
- A wireless power receiver, providing 5v to the controller.
- An i2c 128x64 pixel OLED display.
- A pair of rotary encoders for control.
There is a wireless power transmitter mounted at the steering column, which provides power with no wires at all to the steering wheel once the wheel is mounted. It basically works like a wireless phone charger.
The Controller
The controller unit comprises: -
- ESP32-S3 Dev Kit (chosen because it's talking to multiple units, so benefits from the extra power).
- A relay breakout board to interface with the actual gear shift hardware.
- A BE-220 GNSS/GPS module which works at 18 Hz for track day recording.
- A BMI160 Inertial Measurement Unit (IMU) for recording cornering, acceleration and braking G-Force.
- An SD-Card slot for recording telemetry.
This is the controller hardware, in a custom 3D printed case: -

The Coding
I've been programming ESP32 devices for a couple of years, using Arduino IDE, and this follows the same process. I debated whether to start looking at using the ESP-IDF Framework, but when you're working with i2c OLED screens, IMUs and other elements, the draw of the libraries is too great for now! I will venture there at some point, but for now I favour rapid evolution. After all, this is a hobby project and not a commercial product.
Learning
Speaking of rapid evolution, my first few iterations were entirely written by hand and learn-as-you-go: -
- I initially learned about Bluetooth Low Energy (BLE), creating services and characteristics etc, but then learned about and pivoted to the ESP-NOW. There's less overhead with this protocol and it just works better when you're only communicating between ESP32 devices.
- I created the initial graphics using base Adafruit GFX libraries, but then refactored to use the u8g2 libraries to support the larger and slightly esoteric OLED display.
- I added a third unit (initially for SD card recording before I built this into the central controller) and wrote 3-way networking.
It was a great learning exercise, and I strongly believe that the best way to learn is to try, fail, make mistakes, and fix them.
However...
Agentic Development
Whilst this project was progressing, I'd separately started to tinker with using Artificial Intelligence (AI) for coding. I'd heard of the likes of Claude Code, but having recently bought a Google Pixel phone, it came with a years subscription to Gemini Pro, so I started playing with Gemini CLI, and more recently, Antigravity.
Since those initial concepts, I've started using AI to evolve this project further. It's allowed me to achieve a number of things I simply wouldn't have been able to without weeks of sweat and tears. Some examples of evolution I've made with this include: -
- Moved from using hard-coded MAC addresses for the ESP-NOW network to support automatic pairing and discovery of new/changed modules. This also includes negotiation of encryption keys for a fully encrypted wireless network.
- Replaced the original fixed size struct messages between devices to use a more dynamic Tag-Length-Value (TLV) message structure which makes communications a lot more extensible and dynamic to support things like logging, new sensors and telemetry.
- Made better use of task offloading using FreeTOS background processing to keep the main loop clean of blocking activity such as SD-card writes.
- Improved SD-Card logging to support low frequency data (temperatures, pressures etc) and high frequency data (GPS, G-Force, Throttle etc).
- Built a full wireless web dashboard for the central controller to provide aggregated view of logs from all modules for diagnostics, allow wireless download of GPS logs etc.
- Implemented OTA update capability, orchestrated from the steering wheel menu to ease updating the wheel, the controller and satellite units, without dismantling or struggling to connect USB cables in hard-to-reach areas.
- Added double-pass Exponential Moving Average (EMA) filtering to the G-Force meter to dial out vibration noise.
- Started to prototype new features for sensors, for example tapping into speedometer and engine pulse generator to calculate speed and rpm.
- Refactored code into modules and away from monolithic files.
The progress you can make using AI for development is staggering. I'm not blind to the risks of not understanding what is changing and how it works, but I ensure I understand as much as possible each and every change.
(I use the term Agentic Development in this case, rather than Vibe Coding. Whilst I'm not, and never have been, a professional software engineer, I've coded enough over the years to understand what's good and what's bad. Whenever a change is made, I read and understand the changes. I also use AI to scan my codebase for bad practices, redundant code, security flaws, refactor as it evolves etc.)
Hardware Evolution
The first prototypes were simply modules soldered to each other with wires. For example, the steering wheel looked like this: -
Which worked, but was always going to be sensitive to vibration. So it evolved to a custom PCB: -
Fabricating the PCB was a fun and significant part of the process, and will be a topic for a future post.
All 3D enclosures were designed using Tinkercad. This is an example of the rear section of the steering wheel housing the wireless power receiver, and the steering column section housing the power transmitter: -
Techniques
During this build I've had to learn new skills and techniques, and build capabilities that will help with future projects. Some of these include: -
- Designed and 3D printed various enclosures.
- Modified 3D printer to enable etching of custom PCBs.
- Modified 3D printer to enable drilling of custom PCBs.
- Coding custom software to enable PCB creation.
- PCB acid etching.
- Agentic development.
I'm writing a separate post on the PCB elements as this is a whole topic in itself.
Next Steps
The project is now working with the features described earlier, but there's still work to do. A few ideas for future iterations include: -
- Tap into Speedometer and RPM signals to provide engine an gear telemetry.
- Build pedal position sensors to see accelerator and brake position during track days.
- Tyre temperature sensors using multi-pixel infrared sensors to get temperatures across the tyre width.
- Integration with tyre pressure sensors.
- Software to process my telemetry to support the video overlay process.
What other sensors or features could I add to this project? Has anyone done anything similar to this? Let me know in the comments.





Top comments (0)