• Hello ES! We could use some help to get us past the finish line on building the new knowledgebase for the forum.
    Can you donate? Please see our fundraising page. Thank you!

FOC Open Source Firmware for Bafang CAN bus controllers with GD32F303 processor

But regulating this via the PI controller probably has its downsides too—if we implement a soft start, won't it also be noticeable while pedaling? Additionally, as you can see, this value needs to be set differently depending on the motor. When different users configure different power levels, surging will occur for those who set higher power, while those who set it too low will experience sluggishness. Whereas with the implementation I want to use, the ramp will always be constant and will be around 40ms?
 
I thought about making the PI parameters user settable already, but this would be a source for many struggle I guess. So I decided to keep them hardcoded. If someone finds more universal and more stable values, please report them, then we can use them for the next release.
I tuned the parameters for the M820 already, as it started to oszillate much faster than the M510/M560....
 
Asking for a feature/ have time and an idea. ;)

There is a 9gear hub out there from 3x3.
There is a electric shifter system for it, too.
It works with a trigger and actuator.
This actuator changes the gears. It has 4 wires. 12v+, 12v-, can-high and can-low.
If triggered by trigger (via BT ) it sends a can command to the bosch system to reduce the motor power to reduce the force while shifting. They call it EShift.

Would it be possible to implement that into your firmware?
 
@ChrisDerSeher the 3x3 E-Shift is only compatible with the newer Bosch BES3 (also called SmartSystem). This is CAN-FD, not normal CAN. What you're asking for here is a full blown reverse engineering project on its own. Not a plain implementation..

Rohloff E-14 V1 is normal CAN and could be implemented.. V2 is CAN-FD.
 
Ok, thanks.
I can reverse engineer a piece of wood or a 230V switch, but not a hardware nor a can protocol. So I'll just stop padelling while shifting like I do now...
 
I got the M215 (BBS01 CAN) controller running on the EBiCS firmware now. As I have no M215 middrive, but just the controller, I'm testing with my generic Hoverboard motor. It's throttle only at the moment, the power levels of a simple PAS control have to be implemented next...

 
the power levels of a simple PAS control have to be implemented next...
I've implemented it now, the PAS mode is triggered by a torque filter value of 255.
It's simply one line of code. The max motor current of the recent level is ramped with the cadence. The minimum cadence is defined by the PAS timeout, the cadence where the current is reaching the maximum for the level, is defined by the parameter Ramp End. It's a little tricky, you have to devide the value by ten. If you want a threshold cadence of 60/min, you have to set the parameter to 6.0.
With the smallest PAS timeout of 0.1s and 24 pulses per crank revolution, we get a minimum candence of 25/min before the motor starts assisting.
This are quite a lot differences to the UART BBS01 behaviour, but I think we need some experience and user feedback to decide if we need some improvement.
- I don't know, how many pulses per crank revolution the M215 provides on one quadrature line.
- the motor current is controlled, not the battery current --> the motor power is increasing with the cadence.
- no gimmiks like start boost, I'm not familiar with the BBS01 UART parameters, I just know the discussion, that no one knows which parameter has which function....

 
Last edited:
I need to check the structure of the file header....
I managed to find the right header for the M215. So the firmware update via the Canable tool works now.
There are some issues, that I can't solve at the moment. The 5V supply of the throttle and the speed sensor is not present and the controller draws about 120mA with nothing attached. First I thought I destroyed something removing the potting, but the with the original firmware the idle current is almost zero and the 5V supply works. So it must be something with the GPIO settings.
The controller needs some more analysis...
 
Done, but not tested
Unfortunately, this didn't help. I just now found a way to demonstrate this.

In the video, I hold the rear wheel in the air, turn the crank slightly by hand, and then let go. After that, the motor starts accelerating on its own and doesn't stall. I don't press the gas.

This occurs some time after starting, about half an hour or an hour. After restarting with the button, the problem goes away.

 
This occurs some time after starting, about half an hour or an hour. After restarting with the button, the problem goes away.

Lift the torque sensor rest voltage threshold
The torque signals drifts a lot obviously. If you restart the system, the offset is calibrated again, that solves the issue of course.
We have two possibilities:
1. increase the threshold to a value even higher than 800
2. Recalibrate the offset from time to time at runtime, if there is obviously no force on the pedal. We would need to find a condition that lets us identify this situation reliably.
 
Last edited:
The torque signals drifts a lot obviously. If you restart the system, the offset is calibrated again, that solves the issue of course.
We have two possibilities:
1. increase the threshold to a value even higher than 800
2. Recalibrate the offset from time to time at runtime, if there is obviously no force on the pedal. We would need to find a condition that lets us identify this situation reliably.
You can easily set the threshold to 1000. Even light pressure on the pedal gives more.
 
The other day, something strange happened. I can’t write the wheel size (in mm) via CANable to my M510 with Ebics. At the same time, when I perform synchronization in the web interface, I read the correct values (the ones I wanted to set). The motor controller receives 0 inches, and the speed sensor isn’t working. Similarly, I can’t change the speed limit - but in this case, it doesn’t get set to zero; instead, the old value remains. In the original firmware, all the changeable values are updated correctly.
I suspect something’s wrong with my CAN board. It’s been through a lot in the last few days. I ordered a couple of new boards. Let’s see what happens. 😊
 
I can’t write the wheel size (in mm) via CANable to my M510 with Ebics.
The parameter Wheel Size is not used, but the Wheel Circumference.
Decoding example: 05103203 6 70 17 B5 01 C0 08
ID: 05103203
Speed Limit Byte 1/0 : 70 17 -> 0x1770 = 6000 => 60.00km/h
Wheel Size Byte 3/2 : B5 01 -> 0x01B5 -> 0x01B . 5 = 27 . 5 => 27.5"
Circumference Byte 5/4 : C0 08 -> 0x08C0 = 2240 => 2240mm

Decoding example: 05103203 6 C4 09 D0 01 C0 08
ID: 05103203
Speed Limit Byte 1/0 : C4 09 -> 0x09C4 = 2500 => 25.00km/h
Wheel Size Byte 3/2 : D0 01 -> 0x01D0 -> 0x01D . 0 = 29 . 0 => 29.0"
Circumference Byte 5/4 : E8 08 -> 0x08E8 = 2280 => 2280mm

Little-Endian byte order!

We had an issue with this 3203 command in the canable tool, it was not executed, if the speed limit wasn't changed. I don't know, if @mdi fixed that. Perhaps you can check my code, if you find a bug:
saving the received data from the canable tool to the MP struct and then to the virtual EEPROM:

Sending the data from the MP struct to the canable tool:
 
We had an issue with this 3203 command in the canable tool, it was not executed, if the speed limit wasn't changed. I don't know, if @mdi fixed that.
I rolled back to older and even very old versions of Ebics. I also still have previous releases of Bafang Canable Pro, and that didn’t change anything either. That’s why I’m considering a damaged CAN board as the main cause. An EEPROM controller fault is possible, but it’s much less likely — the issue appeared on both of my motors.
By the way, I successfully tested Ebics in mountainous terrain. Ebics is much safer on steep climbs because, even at high power, it is better controlled. To fall over backward, you would need to very diligently simulate mental retardation.
Also, I rode the M510 for about a week with the current limited to 25 A. I expected to break the PEEK gear in the gearbox. However, on the last day, the HFL1426 coupling failed — it got so jammed that the bike could still be used. I replaced the HFL1426 with a higher‑quality part from NBS. During this time, the plastic gear in the gearbox didn’t show any visually noticeable damage.
No overheating issues were observed, but there are some important nuances: the air temperature didn’t exceed 25 °C, and I didn’t climb more than 400 meters in a single continuous stretch. The motor got hot, but it wasn’t hot enough to burn your hand.
 
Back
Top