They almost buried the lede:
From an OEM perspective, the appeal is pretty clear. A universal mounting standard and unified CANBUS communication system can reduce tooling costs, simplify inventory, and shorten development timelines. Ananda says future M7000 derivatives will remain backward compatible, allowing brands to adapt quickly as market demands shift without starting from scratch with entirely new frame designs.
There is a real problem with the ebike market today, when compared to the bicycle market, which is the wholesale lack of standardized parts. Sure, the the bicycle in the 19th Century also didn’t have standardized parts, but the difference is now very apparent: for acoustic bikes, there are just six standards for bottom brackets, but are almost as many mid-drive ebike motor mounting patterns as there are manufacturers, of which there are many. This is just one example, and one can find incompatible ebike brake sensor, CAN vs UART data buses, headlight voltages, HUDs, and more.
Without standardized parts, there cannot be widespread availability of parts. Without parts, there cannot be bike shops that can sustainably maintain people’s ebikes, nor can riders attempt to extend the life of their ebikes on the road. Without modular replaceable parts, more e-waste and bicycle waste will be produced. Without standardization, vendor lock-in is the natural result, yielding unnecessarily higher prices for consumers.
We need commoditization of basic ebike components, and there are no sufficently-large players that can throw their heft around for force the change. Compare to, say, Shimano, who can basically create a new racing bike standard out of thin air, and the industry will comply.
So I do appreciate when a manufacturer comes out with an ostensible standards-based lineup, promising backwards compatibility. But I’m also skeptical: in computer design, some of the longest-lasting standards are: the IBM PC (1980s IBM design adopted by clone manufacturers), PCI (1990s, from a consortium of PC makers), and color-coded ports for mouse/keyboard/VGA (2000s Intel-led consortium). What we see is that the most durable standards (de facto or otherwise) are multilateral in nature: it takes multiple players to agree to standardize. Not necessarily with each other manufacturer, but consistency within the same company would help.
If we get to the stage where there are “format wars” over the specs for a mid-drive ebike motor, then that would be genuine progress, because a format war means we can identify actual factions that are producing those standards. HD DVD fans were certainly disappointed to lose the war to Blu Ray, but it never deprived them of their ability to watch what they already bought. Fortunately, bicycles are durable goods and can last for a lot longer than a stamped optical disk.
A universal mounting standard and unified CANBUS communication system can reduce tooling costs, simplify inventory, and shorten development timelines.
Wait, when did e-Bikes move to CANBus? Also, what for?
So far as I’m aware, CAN makes a lot of sense when it’s no longer just two devices talking to each other, but a bunch of devices talking amongst themselves. Using UART for the same scenario would result in a lot more signalling wires, whereas CAN only requires a single, twisted pair of data lines that are shared by all devices.
Automobiles followed a similar progression, since CAN was a product of Bosch. Initially meant to simplify the connections between engine sensors, it later proved useful all around a car, from the switches that control power windows to the adjustment of power mirrors. Most importantly, it signals between all of those decices using just two thin wires.
For ebikes, the mandatory data path is between the user display and the motor, so UART worked fine. But other peripherals like brake, speed, and gear sensors, those had their own wires, all having to go to a central controller somewhere. So might as well use CAN to simplify the wiring and maybe add new functionality:
Imagine the display has a button to enable the headlights, and that sends a CAN signal to the controller to close the relay for the headlights. But maybe you have an auxiliary headlight that reads the same signal and turns on as well. And maybe the taillight also turns on, plus a wireless relay so that the lights in your pedals also turn on.
CAN is acceptable to wire two things together, but it really shows when building a cohesive network of peripherals. Unlike modern computer data networks, all devices on a CAN bus receive the same messages and so they can all react to the same “broadcast”. I have personally sniffed the CAN bus on an automobile to implement some nifty integration with a dashcam. Maybe we might have CAN be how a GPS bike computer continues measuring speed using the wheel sensors, even when in a tunnel.
That said, I’d be remiss if I ignored a major downside of CAN: because it’s not drop-dead easy to examine like UART, some manufacturers will implement strange, proprietary message types using CAN. This makes it harder for users to intercept or modify those signals, since there isn’t any documentation. Reverse engineering is sometimes needed to deduce the meaning of certain CAN messages. Ideally, industry standardization around CAN and ebike sensors would mean they’re all compatible with each other. Or at least, I hope that happens.
Still, I’m of the opinion that CAN is light-years preferable than every manufacturer reinventing their own data bus. The electronics community has been poking and proding CAN for decades, so using CAN means less reverse engineering overall.
I get the value of CANBus when it comes to complex systems like a vehicle, where there are multiple input and control events (steering vs. driver assist vs. self-driving).
What I don’t get is why the hell a BIKE needs a CANBus in the first place. It’s a simple device. If they want to stick sensors all over it and feed that onto a display, that’s fine too, although I’d argue what the value is for showing how hard you’re breaking or even collecting the data.
CANBus iin a bike just smells like over-engineering and data collection gone insane.
I don’t disagree about bikes seemingly getting more complicated. But I’d counter that my 2023 ebike would immediately benefit if all the existing sensors were CAN: from the mid-drive motor+controller, I have the left and right brake sensors running to the front, plus the display, and the headlight power circuit. Branching off the display are the controls for the turning on the bike.
To the rear, I have the derailleur sensor, the speed sensor, and the taillight circuit. I’ve been meaning to also expose the brake light circuit, so that would be yet another set of wires.
If I had CAN bus today, I’d shrink the wiring down to just: two CAN wires and two power wires to the front, and two CAN wires and two power wires to the rear. All sensors on the front attach to the display. All sensors at the rear are wired as a chain, with the tail/brake lights being at the very end.
The ease of cable routing alone would be worth it. And perhaps those wires could then be armored, for improved resiliency.
