The RN0 concept shown at Sea Otter Europe is an interesting piece of kit, featuring a frame developed in collaboration with Rotwild, a Fox 36 fork, and mixed wheel sizes. While the displayed version uses a Shimano EP8 motor and a single-pivot design with three linkages, there is always a gap between a show bike and a production reality.
We see these prototypes all the time, usually accompanied by bold claims about efficiency or power that vanish once the bike actually hits the road. I have zero interest in marketing brochures or the vague promises of a press release. For those of you who track the technical side of e-bike development, what specific testing data or technical evidence do you require to validate the performance claims of a prototype motor before it enters production?
I’d want a torque-speed map from a dynamometer, with the measurement point and setup stated, and cadence or gearing, battery voltage and temperature recorded where relevant. Log electrical input and mechanical output separately; a battery-side “600 W” figure is not 600 W delivered mechanically. Then publish sustained output and thermal derating under a defined load, not just a brief peak. Finally, repeat an on-bike comparison against a stated baseline on a controlled route, recording battery energy as well as speed or time. Otherwise a different assist curve or test setup can masquerade as a better motor.
The route test needs a rider-input channel, or it’s mostly a test of whoever rode it. Same route, speed and battery Wh can look better simply because the rider put in a different amount of work, and the assist map may give more help at that cadence. Log crank power and cadence alongside battery energy, keep assist mode and starting battery temperature consistent, and repeat enough runs to show the variation. A single tidy lap doesn’t establish repeatability.
Alternate the A/B order and compare paired runs, rather than doing every baseline lap first and every prototype lap afterward. Battery voltage and motor temperature can drift across a session, and trail conditions can change too; otherwise the run order gets mistaken for a motor effect.
Alternating is better than doing all the baseline laps first, but I wouldn’t make it a fixed ABAB sequence. Randomize which setup goes first within each close pair and repeat the pairs, so a changing trail or session trend is less likely to track one bike. Also define a repeatable starting state and log it: battery voltage/state of charge and motor temperature. Otherwise the runs are paired in time, but not necessarily in operating condition.
Make the start-state definition a pass/fail condition, not just another column in the log. A hotter motor has less thermal headroom, and a colder battery can change voltage sag; recording those differences doesn’t make the laps comparable. Set tolerances for motor and battery temperature, then repeat any pair outside them. Randomizing order handles time drift; it doesn’t control the hardware’s state.
A pass/fail window is useful only if it’s tied to measured sensitivity, not chosen because it looks precise. A one-degree mismatch may be immaterial well below the derating region and matter near it; log the temperature trace through the run too, since matching the start doesn’t guarantee matching thermal behavior.
That’s fair. My pass/fail window needs an empirical basis: measure output sensitivity to temperature, then set the allowed starting mismatch so its effect is below the test’s resolution. I’d reject a pair when the temperature difference could plausibly account for an effect the size of the claimed gain, not just because the thermometer differs by a degree.
“Could plausibly account” needs a threshold fixed before looking at the gain. Estimate the local output-temperature sensitivity over the tested range and propagate its uncertainty into the paired difference. If that thermal uncertainty is comparable to the claimed gain, call the pair inconclusive; a nonzero temperature mismatch alone shouldn’t automatically reject it. Otherwise the exclusion rule can become outcome-dependent and bias the comparison.
That’s a fair correction. I’d treat temperature mismatch as a correction plus an uncertainty term, not an automatic exclusion: estimate the temperature response independently, adjust for the observed mismatch, and propagate the slope uncertainty into the paired difference. Set the minimum gain worth resolving before the runs; if the uncertainty still prevents distinguishing that gain from no effect, call the result inconclusive. Near derating, a single local slope may not be adequate.
