BAFANG M215 (BBS01 CAN bus), M315 (BBS02 CAN bus), M510, M560, M820, CR-A101 FOC Open Source EBiCS Firmware for GD32F303 processors

We'll do the math this evening. I have a disassembled M560.
@stancecoke
Five pairs of poles.

Upd.
I was able to upload the old firmware build v0.006 to my M560 without any problems. It calibrates the same way as my M510, with varying success. However, I noticed some unusual behavior. The controller starts freezing after 2-3 attempts to enter walk mode (with the throttle not connected). Operation is extremely unstable, and sometimes it tries to start the motor with a short pulse. In my opinion, any number of things could happen with this behavior.
 

Attachments

  • IMG20260409175433.jpg
    IMG20260409175433.jpg
    6.4 MB · Views: 18
  • IMG20260409175455.jpg
    IMG20260409175455.jpg
    4.2 MB · Views: 18
Last edited:
Five pairs of poles.
Thank you for checking! Then there is no difference in pole pairs to the M510.

I've added the motor stop with pedaling backwards now. This function uses the same timeout as forward pedaling. So if you want to overrule the throttle signal or the overdrive duration with back pedaling for a longer period, you have to keep pedaling backwards slowly. I thought about canceling the break with forward pedaling only, but I think, this would confuse many users, if they pushed their bike backwards and want to start by throttle then. This won't work.

I've prepared a file for the M560 also, I wonder why you can flash the V0.006 but not the V0.0074. Perhaps flashing the V0.0075 works...
I guess, we have to crosscheck all pin functions on the M560, if the behavior is that unpredictable, there must be differences to the M510...
 

Attachments

  • EBiCS_for_M510+M560_BL38_v0.0075.zip
    54.5 KB · Views: 3
Last edited:
I guess, we have to crosscheck all pin functions on the M560, if the behavior is that unpredictable, there must be differences to the M510
Well, the M560 is out of testing because it's bricked. Firmware v0.0075 was successfully loaded. However, due to the settings in v0.006, which was loaded earlier, the motor wouldn't spin in reverse. After I performed a master reset, the controller went to the depths of Valhalla and no longer responds to firmware uploads, neither through BESST nor Canable.
 
Flash it with ST-Link V2
The brown alarm is canceled. The fuse has tripped. I didn't think about it because I didn't see any signs of a large current flowing. I was confused by the lack of the typical spark from a DC-DC converter when the connector is connected to the battery.
However, the EBiCS on the M560 controller has a problem.
The M510 is running firmware v0.0075. The PAS Timeout and Overrun functions are configured and will be tested tomorrow and over the weekend. However, I'd still like to configure the overrun function as a separate assist mode for difficult climbs. There are a whole bunch of unused values in the "Assist" section. Although, perhaps you've already figured out what to do with them.
 

Attachments

  • IMG20260409233217.jpg
    IMG20260409233217.jpg
    7.2 MB · Views: 11
  • IMG20260409233233.jpg
    IMG20260409233233.jpg
    2 MB · Views: 11
Last edited:
I'd still like to configure the overrun function as a separate assist mode for difficult climbs.
You can configure it for each level already by the override thresholds. Only the duration is the same for all levels. But you are right, there are enough fields left in the torque table. But using them will be confusing for the users, as they are not per level, but per speed range in the GUI. Of course we can use them for anything we want, but if the use is too unintuitive, potential users will be put off :unsure:
Perhaps you can make a suggestion, how the overdrive should be settable in the GUI.

Good to hear, that the M560 is not dead, thank you for testing! But I will have to get a M560. Development from the distance will not work...
 
Last edited:
Perhaps you can make a suggestion, how the overdrive should be settable in the GUI.
I'll think about it when I have a graphical interface in front of me.
But I'm surprised this feature has generated the most active discussion and interest. I just remembered it when making the feature list. There's no immediate need for it.
In fact, I rarely use overrun because it's poorly implemented in the stock firmware and can be unpredictable. It's much better when it's disabled in the stock firmware. But with good implementation and customization, it's a powerful feature, in my humble opinion.
 
You can configure it for each level already by the override thresholds. Only the duration is the same for all levels. But you are right, there are enough fields left in the torque table. But using them will be confusing for the users, as they are not per level, but per speed range in the GUI. Of course we can use them for anything we want, but if the use is too unintuitive, potential users will be put off :unsure:
Perhaps you can make a suggestion, how the overdrive should be settable in the GUI.

Good to hear, that the M560 is not dead, thank you for testing! But I will have to get a M560. Development from the distance will not work...
Do you need to get a 560, the early motors had M510 controllers. Why not get a M560 controller and fit it to your M510, the mechanicals of the two motors must be similar in layout. If you want to go down that route I have a new M560 controller here you can test ( I had intended to fit it to my M510 as some have already done to get the higher hard coded Amps ). With your FOC we can set the amps via Canable.
 
Last edited:
( I had intended to fit it to my M510 as some have already done to get the higher hard coded Amps )
I wanted to do the same thing when I bought the M510. I thought the maximum current was hardcoded into the M510 firmware. However, this isn't the case, and I set it to 20A in the stock firmware (Canable, old BESST) without any problems. Now I'm not sure about replacing the controller, as the M510's power is limited by its smaller physical size, peek gear, and overheating, not the controller.
 
and I set it to 20A in the stock firmware (Canable, old BESST) without any problems.
Mmmm I tried that but didn't seem to work. I'll revisit.

Both M510's I have are now not working ( always the same problem in our slop and winter mud the seal at the crank side wears out and lets water in ) and the M820 stopped last night showing ERR09. I'm having a really bad run with equipment this year already, 4 tyres, 3 derailleurs, 2 motors and numerous other odds and ends. I've spent more time fixing stuff than riding at the moment. Really really caught up in a work project and my free time is limited, not what I need just at the moment.
 
Do you need to get a 560
I got a M560 on my workbench now. I had to disable the shut off algorithm (as I have no display connected and the controller switched off randomly) and increased the deadtime of the PWM a little (just because both testers reported random high current peaks), but the position sensor calibration went fine and the motor runs without load with the throttle flawlessly. I've flashed the firmware with the STLink directly to the standard start adress 0x08000000. Maybe the bootloader causes some trouble. We have to test much more, but there are first positive indications with the M560! :)

 
Maybe the bootloader causes some trouble
I checked most signals now, flashed by the canable tool with the Bootloader 38 and found no abnormal behaviour. Position sensor calibration worked, throttle works, cadence and torque reading works. But I have not tested under load so far, as I have not assembled the M560 on my test bike yet.
I've pushed the last changes to a new M560 branch, but beside the slightly higher deadtime, there is no difference to the M510 branch. I have to check the motor- and battery current calibration under load, if the motor runs on the roller trainer.
https://github.com/stancecoke/BAFANG_HUB_GD32F303RCT6/tree/M560

regards
stancecoke

Edit: Installed the motor on the test bike now. The first test run on the roller trainer went well. Only switching on is tricky, if you push to On/Off button too long, the system shuts down immediately. So you have to release the button, before the Bafang Logo appears on the display :)

The current calibration is slightly off, but not much. This log shows pedaling first, then a short boost with the throttle.

1775920896189.png
 

Attachments

  • EBiCS_for_M560_BL38_v0.0076.bin.zip
    27 KB · Views: 2
Last edited:
Testing #7
Bafang M510 FC 3.0 | Throttle – not used. | Battery – 52v (14S).
DPC245 Screen | FW - EBiCS_for_M510_BL38_v0.0075

@stancecoke, hello! Today I rode EBiCS for the first time in real-world riding conditions. I rode about 10 km through a flat forest with some small bumps, and I have some comments.
1) Perhaps the support level is too progressive. I've written about this repeatedly, and about the operating range of ~30-100 units. At 30, the controller barely begins to deliver power, but at 75, I easily reach maximum power. Maybe formula is linear, in which case you should pay special attention to point #2.
2) The power output is too dependent on cadence. I haven't looked at the formula, but it's definitely too progressive. The motor is quite weak at the start, but at a high cadence, you don't need to put any power into the pedals at all – the power output will be maximum. Just pedal quickly, like on a BBS :)
Of course, the torque sensor is noticeable, but cadence is the priority.
I'm comparing EBiCS to the original FC 3.0 firmware, where the assist works very well. There's also an overreliance on cadence there, but it's within reasonable limits. The most important thing is that I get power peaks where I need them. The range I use in the original firmware is 50-260%, based on the motor's maximum power (300W_human + 260% = ~1080W). And it works roughly as expected.
3) Overrun doesn't work properly. Quite often, the PAS timeout triggers and the motor dies, followed by a sharp overrun. Overrun should work like a long PAS timeout, in my humble opinion.
4) PAS timeout – works great.
5) The voltage map is acting strangely. I lowered it from 58+V to 57V, and the display still shows 99%.

But! This is already usable!

I've pushed the last changes to a new M560 branch
I'll go get my M560 ready for roasting.
 

Attachments

  • 1775923315044.jpg
    18.2 MB · Views: 7
  • 1775923315185.jpg
    17 MB · Views: 4
  • Setting_v1_00075.png
    Setting_v1_00075.png
    61.8 KB · Views: 8
Last edited:
I'll go get my M560 ready for roasting.
This time, nothing burned out. The controller freezes. Calibration was successful, Cal = 0. Short pulses are periodically sent to the motor. This is due to the controller sometimes reading more than 750 mV from the torque sensor. It also draws current when idle. None of this happens in the original firmware.
 
The controller freezes.
Thank you for testing! What do you mean with "freezes"?

What is your setting for the override thresholds?
The motor shouldn't engage, if the torque rises above 750mV, when the torque override threshold is set to a higher value.

The calories field doesn't show the position sensor calibration any more. At the moment it shows the backwards pedaling flag ;)
 
Thank you for testing! What do you mean with "freezes"?
This happens a short time after power-on. It doesn't switch support modes. It doesn't switch information displays for ODO, Cadence, etc. Only power-off works normally.
What is your setting for the override thresholds?
Not less than 2000 mV. Most modes = 3400 mV.
The motor shouldn't engage, if the torque rises above 750mV, when the torque override threshold is set to a higher value.
It seems the motor doesn't know about this restriction :)
A cause-and-effect relationship has been established: exceeding 750 mV = engine activation (you can hear this in my video). This all looks like some kind of interference or a lack of filtering. With the original firmware, the torque sensor value is stable at 750 mV. Controller consumption at idle = 0.
 
It doesn't switch support modes. It doesn't switch information displays for ODO, Cadence, etc. Only power-off works normally.
Strange, this doesn't happen with my system.
Can you attach a throttle? I wonder if this motor jerks happen because of an open throttle connector.

Regarding the cadence dependence: normally on a middrive you don't need the cadence information for the calculation of the iq setpoint at all, because cadence and motor speed has a fixed ratio. So at the the moment the assist factor increases linear with the cadence. I can make it settable with an exponential function, so you can choose, how much the cadence influences the setpoint. From almost zero to linear.
C:
i_q_setpoint = assist level * filtered torque * cadence^(1/(1+value))
So the higher the value, the less influence the cadence has.
 
Last edited:
Can you attach a throttle? I wonder if this motor jerks happen because of an open throttle connector.
This will be difficult, since the only cable supporting throttle is on the bike with the M510. I'll be able to answer this question tomorrow morning.
 
Do you have a different display on the M510 bike also? This freezing may be a matter of the displays firmware also.
The displays are identical. I'll test the M560 first with a different cable, and then with the throttle handle.
 

Attachments

  • IMG20260411230048.jpg
    IMG20260411230048.jpg
    875.9 KB · Views: 3
The displays are identical. I'll test the M560 first with a different cable, and then with the throttle handle.
@stancecoke,
Through trial and error, I discovered something strange. The freezing and fake engine starts are related to the DPC245 display. Connecting my display to the M560 eliminates the problem. I also have a spare, third DPC245. It switches display modes several times and freezes before shutting down. However, it doesn't cause fake engine starts. Note that all these displays are functional and work with the official controller firmware. it works exactly the same way with my M510 motor. There's likely some interesting issue with the controller-display communication. Also, neither of my two third-party displays (SW102T, DZ41) display the EBiCS battery readings, although they work correctly with the Bafang firmware.
For now, I will postpone testing the M560 until the situation with the CAN protocol is clarified.
 

Attachments

  • Main245.png
    Main245.png
    12.4 KB · Views: 10
  • Second245.png
    Second245.png
    12.8 KB · Views: 10
Last edited:
Back
Top