Flash e-bike Part 5 (Electronic Speed Control)
In part 1 of the series, I introduced the background of this particular exercise, and why we're embarking on it. In part 2, I disassembled the bike and identified the major pieces of its systems. In part 3 we looked at the mainboard, and figured out what its primary components were, and how they worked. In part 4 we reverse engineered the BMS, in particular the communication protocol.
In this part, we're concerning ourselves with the electronic speed controller (ESC). The goal of this exploration is to not spend money, or waste hardware. In an ideal scenario, we can re-use the ESC (simplifying connectors, wiring, etc.) and its programming; It may not be obvious, but there is a lot of nuance in tuning an ESC.
Identification
The first issue to address figuring out who makes the ESC and what model it is. None of the bike reviews specify the ESC, nor is it in the specifications, or in manual for the bike. With the ESC removed and accessible, we can start searching for any text on the unit itself. Thankfully, there's a large "ASI" debossed on the resin casting.
Searching online for "asi esc" returns Accelerated Systems as the second link in kagi, so that's a good start. A little searching on their product pages yields the BAC355/BAC555/BAC855 line, which looks very similar to what we have.
ASI also Publishes a fairly complete spec sheet with pinouts. I compared the pinout in the datasheet against my unit and the wiring harness supplied with the bike.
The wiring harness in the image above shows the wires going to the motor, via the black cable exiting the frame to the top. The display, throttle, and pedal sensor are the other cables visible, going to the right. I verified with the multimeter that every signal went to a sensible harness and pin according to the datasheet. This gave me high confidence that I could use this documentation for future exploration, and that I'd be able to make my own harnesses as necessary in the future.
Testing
Next, I was concerned with whether I could actually wire-up the ESC and run the bike without the mainboard. I moved all the parts back to the garage, and replaced all the wiring as necessary.
To enable the ESC to operate, I shorted the B+ and Enable pins that we identified in the mainboard post, and did the same with the brake loop. In principle, this should have allowed the ESC to work with throttle and pedal assist. At least, I thought it would. The motor was steadfastly refusing to turn or behave as if it was powered at all.
I was pretty frustrated. But, I took the opportunity to re-read the bike user manual for anything that I might have missed. The clues I needed were in two separate parts of the manual. In the How to turn your bike On and start riding section, there is the note "The screen will show 0 mph and Pedal Assist Level 0." (PAS is short for "Pedal ASsist") Later, in the Throttle on Demand section, there's the note "To use the throttle make sure your bike is in the On state and PAS is between 1-4." Combined, these mean that the bike will default to having PAS set to "no assist" and throttle disabled.
I had it in my mind that I might be able to hobble-along with no mainboard at all, but apparently not.
Third-party displays/controllers
Faced with the prospect of making my own display and controller, which I definitely don't have time for, I was searching online for "asi motor controller protocol". Luckily, about half-way down the first page of results, I came across a knowledge base article on the EggRider page. Eggrider appears to be a relatively well known display controller, and supports a range of bikes.
The knowledge base article on the EggRider page did mention some required programming of the ESC:
- Flash parameter read access code (address 62) - 0
- Display Protocol (address 66) - Disabled
- Assist Mode Source (address 210) - Network Gains
Configuration interface
To implement the above, we're going to have to connect a computer to the ESC. Given the supplies we have on hand, there are two options. It's reasonable to assume we're not going to need the cable between the ESC and the mainboard any longer; we can cut it and use the ends with the USB-UART adapter. There are two ways to do this. One is to use the round connector and the free wires with the adapter.
Another is to rely on the fact that the ESC connector, and the connector on the mainboard, are 2mm pitch JST connectors. The JST connector that went to the mainboard perfectly mates to the pins we need for programming.
Over the course of this project, I ended up using both methods. I ended up re-purposing the end of the cable that mates with the round connector later on, and needed a way to do more programming. The second method came in handy.
Programming
Unfortunately, they don't explain what tools are needed to make the programming changes the Eggrider requires. I sent a message to ASI via their contact page, and got reasonably helpful replies. ASI publishes a program called "BacDoor" for technicians (and perhaps bike shops). They don't make it available to end users, but if you buy an evaluation kit from their website you'll get access to it. The kit costs $750 at publication time, which isn't unreasonable for what you get, but I don't need almost any of it. I was able to find that the ESC uses ModBus as the protocol for configuration and diagnostics.
While discussing this with my friend Andrew of Derelict Robot Industries, he mentioned that there is another ESC company, GRIN Technologies, that basically copied the ASI register map when they developed a competing ESC. Their Phaserunner software should work with the ASI (in principle).
In practice, though, it didn't. While it was capable of reading the registers when it first connects, it didn't correctly update them. Also, while I could change the values required for the EggRider, they weren't persisted across reboots.
Eventually, I relented. The sales engineer from ASI implied that might be possible to get a copy of BacDoor via less-than-official means in one of the emails:
The controller is programmed for that specific setup, and we do not give out the software to end users. Even if you were to gain access to the software through 'other means', I'm reasonably sure that the parameters are locked, and unreadable.
I started searching the ebike forums, and was able to find a copy. With it in hand, I programmed the registers and saved them to flash. It turns out that the registers for the display protocol and Assist Mode source aren't protected as the engineer had mentioned.
Meanwhile, I had been in contact with the folks at EggRider. While they support several bikes that use the ASI controller, their business model is built around "plug-and-play" support of a handful of bikes. The Flash isn't officially supported, and they made it very clear that I wouldn't receive any support, and that I wouldn't have a warranty. This was fine for me, and a good bargain, all things considered. So, I bought one.
Next steps
In the next post we're going to wire-up the EggRider and see if we can get it to work. If we're lucky, we might even get to put some miles on the bike. In yet another post, we're going to write a small and simple Rust program that will obviate the need for BacDoor in these setups entirely. There's really no reason why the EggRider makes the user set these parameters anyway. When it boots up, it could just as easily send the ModBus commands to the ESC. Making this program will take a few hours of my time, but will allow people to setup the ESCs without scouring the internet for software that they technically don't have a license to. Thanks again for reading.