A custom PCB and desktop application that emulate speed, torque, cadence and handlebar buttons, so e-bike firmware can be developed and regression-tested on the bench, including automated safety tests.
While developing firmware for an e-bike drive system, we needed realistic speed, torque and cadence inputs before the production sensors existed, and we needed tests that could be repeated exactly. Riding a bike around the car park doesn't give you either. So we designed and built our own e-bike emulator: hardware that pretends to be the bike, plus software that turns it into an automated test bench.
What we delivered
- Custom emulator PCB with a CAN interface, a configurable wheel-speed pulse generator, torque and cadence emulation, USB and three rotary encoders for hands-on control
- 3D-printed enclosure with labelled speed, torque and cadence knobs
- Emulator firmware that converts requested values into real CAN messages and sensor signals, so the controller sees exactly what a real bike would send
- Desktop application for manual control, button emulation, automated shift tests, live plotting, signal drawing and result analysis
From manual checks to automated validation
Engineers can drive the emulator with sliders or knobs for quick checks. The real value is in automation: test scenarios are drawn as time-based profiles (speed, torque, cadence, button presses and pass/fail limits), saved as CSV, and replayed against every firmware version with exactly the same inputs.
During each test the application records the system's response straight from the CAN bus and checks it against a pass/fail mask. If the response leaves the allowed region, the test fails, and the plot shows exactly where and how.
One example is the legal assistance limit: assistance must start reducing at 25 km/h and reach zero before the configured 28 km/h hard limit. The emulator sweeps the speed through that range, the analyzer checks the measured assistance against the mask, and the test runs again automatically after every firmware change.
Result
- Firmware development continued while sensors and mechanical parts were still unavailable
- Deterministic, repeatable tests instead of manually reproduced riding conditions
- A growing library of CSV test profiles for regression testing
- Automated shift and safety tests that run after every firmware change
- Clear diagnosis of failures: what input was applied, how the system responded, and where it went wrong
The full story, with screenshots of every part of the application, is on our blog: We Built an E-Bike Emulator So We Could Test Firmware Without the Bike.
Technologies & disciplines
- Hardware-in-the-loop test systems
- PCB design and embedded firmware
- CAN bus communication and monitoring
- Desktop test software, data acquisition and visualisation
- Automated regression and safety testing
- Mechanical design and 3D printing