There is a reason why every car in the world uses CANbus communication not UART.
Yep: Vendor lock-in, & lower wiring harness cost for complex vehicles with many interconnected electronic modules.
This diagram explains why the CAN bus communication protocol is used in the automotive world and the redundancy.
Source:
https://canbuskit.fortin.ca/what.php
Without CAN communication, the wiring would a total mess.
View attachment 113299
Kinda proving my point for me, here: An ebike has none of this multipart complexity.
Cluster, accessories & security, are all provided by the display, & there _is_ no transmission integration... & if there were, it could be controlled by display, without direct connection to the motor-controller, or by the motor-controller, without direct connection to the display.
Interconnecting them all offers significant safety & maintenance downsides, with no functional upside: All proposed features work with a single component driving them, & communicating with the others directly; for example, there is no need for motor-controller to communicate with media functions (& huge safety reasons why it shouldn't). In CANBus, there is no meaningful device isolation; every component is exposed to attack & harmful input, by every other component on the wiring harness.
CANBus reduces wiring complexity while
increasing signalling complexity. UART signalling is very straightforward by comparison, & much easier to learn. CANBus also enables undisclosed proprietary unlock & hardware ID features, making it possible to refuse a replacement part. Plus new & exciting failure modes. UART is a
simpler protocol to implement programmatically, & does not easily restrict 3rd party development, the way an authorized-service-only CANBus system does.
Unlike automobiles, ebikes have all their features provided by a very small number of discrete electronic components, where interchangeability offers more feature diversity than a single manufacturer\bundler ever could.
CANBus enables more formidable lockouts against third-party service.
That's the big advantage for OEMs.
When you start building smarter control like mobile App to tune the torque, speed, range, this is where CAN communication shines.
All this is already available with UART communication.
In fact for the more advanced features, it's
only available with UART, due to CANBus controllers requiring more complex OEM-authorized permissions, to reach those settings.
Also CANBus adapters require more complex electronics, making them more expensive to produce.
Aside from a change in communication protocol
used by hardware external to the cellphone (& again,
the UART protocol is simpler to program for!), there is no difference between what can be implemented via a mobile device app commanding a UART versus CANBus adapter, except that CANBus communication is more readily locked against such implementation.
It's quite challenging to build all those features based on UART.
You haven't mentioned a single thing that isn't already done with UART; all of these are intentionally made
more difficult on CANBus systems; & even presuming OEMs did not lock against 3rd party service (which they do), there is no feature beneficial to the end user, which CANBus can offer, that cannot be developed at lower complexity on UART.
Smartphones do not have CANBus adapters built in. All smartphones will need an adapter to communicate by CANBus
or UART; but UART signalling is simpler to program for, the adapters are cheaper, & the
UART motor-controllers available are more freely adjustable than otherwise identical CANBus units.
One could also build a lot more security features in the BMS with CAN and make it seamlessly integrated with the rest of the system.
'Security features', as in "Use only X brand battery"?
True.
CANBus offers a much stronger communications-based lockout capability.
Locking the motor-controller & battery via a "panic button" style communications-based lockout, to enable soft-bricking a battery, display, controller, or other components, in the event of theft
(or accidentally - ask a slew of Dell laptop owners), is possible with any communications system, but in practice the only real advantages are to DRM, with users seeing no real-world benefit, over just locking the battery in place with a decent key.
Of course, the battery's cells themselves cannot be programmatically secured against scavenging, nor can the motor itself, nor the more purely mechanical parts, such as the cassette or wheels.
Meanwhile an alarm systems gains nothing but failure modes, by interconnecting its communication with all other electronic modules on the ebike:
Isolation is the simplest & most effective means of electronic security.
If a soft-brick of the motor-controller or battery is desired, that
can be implemented through UART communication, it just
isn't a widely desirable feature, because such soft-brick features present extremely troublesome failure modes guaranteed to produce support headaches, & because soft-bricking doesn't actually help prevent theft before it occurs,
reduces the likelihood a casual thief will be caught riding it, & encourages professional thieves to disconnect parts as soon as possible, thereby preventing any such lockout & further reducing any chance of recovering the ebike intact.
Interconnectedness may sound like a good thing, to someone unfamiliar with systems maintenance, but in security,
interconnectedness always means more risk, due to an increased number of interconnected attack surfaces. Look at the exploits for Bluetooth, satellite, radio remote,
and cellular systems integrated into CANBus vehicles: Attackers gain entry through a non-critical system, then use the interconnectedness of the CANBus system to gain control over critical systems responsible for vehicular movement. Far from being a solved issue, vulnerabilities have increased explosively as more smart features are added to more vehicles, without any physical network isolation being implemented.
Most of these systems have no functional need to communicate
with each other, they only need to communicate with one user-interface computer
or the motor-controller, & never need both. Any communication with either device, is sufficient to allow full access to all exposed features of
both devices, while maintaining compartmentalized operation!
Furthermore, this isn't some lumbering roadyacht with a hundred devices in it: The BMS (assuming it's even programmable), motor-controller, & display, are
all of the computing devices. That's it. Even when adding features, the number of discrete computing devices doesn't go up: Antitheft, GPS tracking, GPS navigation, geofencing, social apps & gamification, media playback & control, ebike config, live drivetrain stats; these are all already available to & through the display.
Want truly rich smartphone integration? Totally doable, &
the devices necessary to get the smartphone connected, are cheaper using UART than CANBus.
Adding smart features & accessories is not in any way dependent on switching to CANBus instead of UART communication, & in several important ways, both end-user & 3rd-party enhancements are actively hindered by CANBus systems due to the enhanced vendor-locking features.
The GPS hardware may be in the display or it may not be in the display but implementing GPS/ remote lock etc requires a more robust, higher bandwidth communication protocol.
Um. What are you even talking about, on this one?
No. GPS does not in any way need "more robust" or "higher bandwidth communication protocol" between the display & motor-controller. Any possible functionality the motor-controller has, is already achievable over UART, with fewer roadblocks. If you disagree, please mention specifically what would be more practical on CANBus than UART protocols?
Remote locking capability is also protocol independent, & software locking sufficient to prevent using the ebike is already available without CANBus.
With regard to soft-bricking the controller or BMS itself, that is more often problematic than useful, as I stated above. A robust physical lock offers better security and better reliability, obviating any large benefit from part-by-part locking of internally housed electronics.
If you would like a remote communication feature like many of the systems do (Shimano, Bosch, Specialized-Mahle) where you can tune the torque, assist level, speed, using CAN enables hardware engineers to design them appropriately.
False. All of that is readily available, & the only reason any users & 3rd parties can't see those features, are because the OEM chose to make them unavailable.
Also,
wireless features are not via CANBus anyway; they use separate protocols & connect via a gateway device, such as the display (or in rare cases, a wireless communications module on the motor-controller itself). CANBus versus UART has no relevance to wireless features at all, except with regard to aforementioned vendor-locking.
The only
perceived issues with UART motor-controller communication being too slow, which I have seen anywhere among any of the forums & technical discussion groups surrounding ebike motor controllers, was presumption that sensor timing was too low, or the controller's bus rate too low, to maintain readings accurate enough for smooth graduated response. Deeper investigation of the electronics & configurations used, revealed this presumption to be incorrect: The "better" controllers
had nearly the same response times, due to nearly identical components, & the OP had been using a config which left the torque sensor entirely uncalibrated, causing the controller to interpret 0 "Kg" on the pedals as ~12 Kg of pedal force applied.
Bafang does not optimize their motor-controller settings at all, much less for a given ebike.
The motor-controller's "default settings" for the torque sensor are literally non-functional.
Their new CANBus units are being sent out to bike builders with this non-functional torque sensing, locked behind an online permissions server.
The UART units were fully adjustable, to a much finer degree than the motor-controllers offered by Bosch, Shimano, or other large brands.
Can one do all of that just UART, possibly!?
Yes. All of it. Not a single technical barrier to prevent it.
But, it is so much simpler with CAN.
Significantly more difficult,
on purpose.
Anyway, Thanks for engaging me. I have no more data to contribute.
At least contribute something explaining why on earth GPS feature developers would want CANBus motor-controllers instead of UART?
I am all for engaging discussion, but without something besides empty promises to back up the assertions that CANBus is fine or somehow better for users, & with evidence piling high that CANBus is used against users, singing the purported praises of CANBus controllers, smacks of toxic optimism...
I see no evidence at all, that CANBus is good for users, while the downsides created by pervasive vendor-locking, are enormous & visible across multiple industries.
I'm kidding. 
.
