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

We will see tomorrow, if something goes wrong in the code.
Hm, so far no findings. With my 10s battery, everything looks OK. So I have to try my 13s battery now.

Chart with pedaling only, no throttle:

1774787343402.png


Ah, now I got the issue also! But it seems to happen olny sometimes. And I have no idea, what's going wrong :unsure:
The cadence reading continues, but the motor commutation freezes...

1774790102917.png

Edit: OK, the PWM got switched off under certain conditions, I fixed this. But did not test very much with the quick solution.
I show the PWM active/inactive state in the calories field, so you can check in the display, if this bug appears again. I'll publish the bugfix later.

1774793836853.png
 
Last edited:
This behavior is a consistent pattern for my controller.
I've just updated the last release, the file name is the same, but the file is updated. Give it a try!
If your display can show the calories, watch the value carefully. When the motor is not active it shows a zero, if the motor is engaged, it shows a big value. There should not appear a zero while pedaling.

 
Last edited:
I've just updated the last release, the file name is the same, but the file is updated.
I think I've managed to get the logger working on Ubuntu. As a regular Windows user, it was quite a pain :)
However, I'll be able to provide logs now. I'll be able to test the update this evening.
 
Last edited:
I think I've managed to get the logger working on Ubuntu. As a regular Windows user, it was quite a pain :)
The logger works on Windows also. You just have to install Node.js.

Download the repo as zip file and unpack it to your harddrive, open a cmd window, navigate to the unpacked folder and type
Code:
node logger-cli

Stop the logger by pressing CTRL+c.

See the spoiler in the Canable thread: #356

I'm looking forward to get your feedback!
 
Last edited:
I'm looking forward to get your feedback!
You've done something interesting. I'm about to go out for a test drive and I've noticed something strange. When pushing the bike backward, the motor resists the movement. It's similar to the hill-hold feature. It's just that it can't be turned off. I turned on walk assist, and after turning the motor forward, the effect disappeared. After rebooting, this effect reoccurs, and it can be "turned off" in the same way.
4.5 watts of power (58V) consumption, according to my BMS.
 
Last edited:
Much more interesting is, if the power drops at high cadence are gone now ;)
Everything felt the same. But in the logs, I got a lot of inconsistent values. Even after deleting the excessively high values, I still got strange data. I'm attaching the CSV files unchanged.
 

Attachments

  • BOOST.png
    BOOST.png
    485.9 KB · Views: 6
  • ECO.png
    ECO.png
    443.9 KB · Views: 6
  • CSV.zip
    126.6 KB · Views: 4
I got a lot of inconsistent values
this is not inconsistent, but signed 16bit integer values printed as unsigned values. You can convert them into their negative value.
From my first look, you have to do a position sensor calibration from the EBiCS firmware, the default value doesn't work for your motor obviously. The Ud value (last column) is much too high. If the routine doesn't work for your motor, we have to check how we can make it work, perhaps I have to explain my approach and some one else has a better idea than me.
Another thing is to check the phase current offsets, they are hard coded at the moment but may vary from controller to controller...

Thank you for testing!
 
Last edited:
From my first look, you have to do a position sensor calibration from the EBiCS firmware
Done now. As I mentioned earlier, when calibrating EBiCS, the shaft only rotates slightly. Unlike regular firmware, where the motor is quite active.
Another thing is to check the phase current offsets, they are hard coded at the moment but may vary from controller to controller...
It seems that with a compatible Torque Sensor and motor (FC 2.0/FC 3.0), the controllers are significantly different and the different boot code is not just a coincidence.

I can record the trip logs after calibration this evening. The results are expected to be similar to yesterday's.
 
Done now. As I mentioned earlier, when calibrating EBiCS, the shaft only rotates slightly. Unlike regular firmware, where the motor is quite active.
Yes, the motor only turns slightly during the calibration with EBiCS. If there is interest, I can explain, what is happenig during the procedure.

It seems that with a compatible Torque Sensor and motor (FC 2.0/FC 3.0), the controllers are significantly different and the different boot code is not just a coincidence.
I don't think, that your issue is caused by the torquesensor reading, but I can simply put the calculated motor current setpoint to the debug data, then we can see, if the setpoint is dropping. I'll provide a bin file tonight.
 
I'm attaching the CSV files unchanged.
I've updated my Python script for dealing with the log files from the Canable logger. So you can create the graphs just by a mouse click and zoom/scroll in the graphs easily.
This is the graph of your "Tour" log. You can see, U_d is bigger than U_q. That's not OK at all.

1774945969272.png

It's already bad in my graphs in #251, as I have not run the calibration since the last full chip erase. I have to check it how it looks, after executing the calibration :)
 

Attachments

  • Logaufbereitung.zip
    1.3 KB · Views: 6
I have not run the calibration
After running the calibration, U_d is significantly lower. (y)

1774975790133.png


But I had to run the calibration several times, to end in a good behavoiur. You can check the success by the idle current (full throttle without load), it is about 1.25A @ 53V with the chain off for my motor. If the calibration fails, the value is much higher...
So we have to improve the calibration procedure, but I have no idea, why it works sometimes, and sometimes not.

During the procedure the motor turns for 15 electrical revolutions in open loop. The motor has 5 pole pairs, so this are 3 full mechanical revolutions of the rotor and 3 z pulses have to appear during the procedure. The quadrature counter for the decoder A-B-signal is set to zero at electrical 180°. The quadrature counter value that is reached, if the z-pulse happens is the relevant value for the calibration. The timer is set to this value, if the z-pulse interrupt is fired during the normal motor operation.
During the calibration debug data is sent, so we can get this kind of chart:
1774978397926.png

I got a calibration value of 480 in this run (green curve). The default value in the repo is 450.

Following murphies law, I was not able to log a failed calibration, everytime I logged it, it went fine :ROFLMAO:

I've updated the V0.006 release again, so the PWM is off now on startup and the frequency for the cadence/trip information update on the display is higher now.
 
Last edited:
I've updated my Python script for dealing with the log files from the Canable logger.
OMG. I thought this was a general-purpose CSV visualization tool for Ebics. I've been tinkering with Python and installing matlibplot, only to discover it's a very limited script for visualizing specific data. Honestly, you're forgetting I'm just an M510 user :D
Now, having spent a lot of time, I will proceed directly to testing.
 
it's a very limited script for visualizing specific data
It's a script that generates the graph from the logged data with one mouse click. Not more, but not less.

So we have to improve the calibration procedure
Any ideas? I will try "by hand" if a "better" (less battery current at idle run) calibration value can be found. If so, I will try to find an algorithm, that detects this optimum calibration value automatically...
 
Maybe the original algorithm can be reverse-engineered?
Not by me, decompiling the original firmware is not my approach :)

But the VESC does it quite in the same way like I do it. Answer of the AI:
The VESC (Vedder Electronic Speed Controller) performs encoder calibration to align the mechanical position of the sensor with the electrical position of the motor’s magnetic field. This is critical for Field Oriented Control (FOC) to ensure the controller knows exactly when to fire each phase.
How the Calibration Works
Open-Loop Rotation: When you click "Detect Encoder," the VESC ignores the sensor at first. It applies a set amount of current to the motor phases to force the rotor to spin at a constant, slow speed (Open-Loop).
Mapping the Signal: As the motor spins, the VESC records the raw values coming from the encoder (whether it’s SPI, ABI, or Sin/Cos).
Calculating the Offset: The firmware compares the electrical angle (where the magnetic field is being pushed) to the mechanical angle (what the encoder reports). The difference between these two is the Encoder Offset.
Direction Check: It also determines if the encoder is "Inverted." If the encoder count increases while the motor is commanded to move in a positive electrical direction, it’s normal; otherwise, it marks it as inverted.
Key Parameters Obtained
Offset: The angular correction factor (usually in degrees).
Ratio/Counts: Confirms the pulses per revolution or the relationship between one mechanical turn and the number of motor pole pairs.
Inverted: A boolean (True/False) that ensures the software doesn't fight against the hardware direction.
Common Requirements for Success
No Load: The motor must spin freely. If there is a belt or gearbox attached, the "drag" can cause the rotor to lag behind the magnetic field, resulting in an inaccurate offset.
Sufficient Current: The "Calibration Current" must be high enough to overcome the motor's cogging torque, ensuring a smooth, steady rotation during the test.

@Avatarkhorn: Have you tested the idle current and the riding behaviour after calibration already?
 
Last edited:
Have you tested the idle current and the riding behaviour after calibration already?
No. After fiddling around with Python, I decided to quickly fix some mechanical issues on my bike. We all know what that "quickly" leads to :D

Today I'll hook up the throttle and test it out. I'll also try to do a load test.
 
@Avatarkhorn: Have you tested the idle current and the riding behaviour after calibration already?
Testing #4 – success :)
Bafang M510 FC 3.0 | Throttle – not used. | Battery – 52v (14S).
DPC245 Screen | FW - EBiCS_for_M510_BL38_v0.006

1) The motor was calibrated using EBiCS. The idle current with the throttle was no more than 1.2A at 57V.



2) After calibration, the main problem with my M510 was solved. Acceleration is smooth and proportional.
3) I need to review my settings because I'm reaching the maximum current quite easily. Similar values on the original firmware work differently.
4) I might have to ask you to compile a separate bin for 52V.
 

Attachments

  • Testing#4.png
    Testing#4.png
    353.6 KB · Views: 4
  • Tour-Boost-Sport.zip
    558.9 KB · Views: 1
4) I might have to ask you to compile a separate bin for 52V.
There is no need for an extra compiled bin file, the system voltage is simply set by the Canable/BESST tool. But I don't know, if @mdi has already fixed the issue, that no 52V can be chosen from the drop down...

After calibration, the main problem with my M510 was solved. Acceleration is smooth and proportional.
🥳 This are great news!

Similar values on the original firmware work differently.
Sure, the EBiCS firmware has nothing to do with the original firmware. I can't compare the behaviour, as I only rode about 100m with the Bafang firmware ;)
But there are a lot of parameters for finetuning, so I hope you will find a personally preferenced setup :es:
 
But I don't know, if @mdi has already fixed the issue, that no 52V can be chosen from the drop down...
Any voltage setting I select is instantly reset to 36V. This happens in Windows and Linux, in any browser. If a 52V option were added, I'd hardly be able to select it. :D
 
I've tested with various encoder calibration values now.
480 was found by the calibration routine. But this is not optimal
500:
1775063023222.png
520:
1775061462309.png540:
1775061279659.png

The idle current has not changed, the FOC control can compensate this offset obviously. But U_d stays near zero with 540 and we are not in trouble with hitting the U_d limit value, that would prevent the FOC control to keep i_d at zero for optimum efficiency.
I don't know, if it's a good idea to add a constant 60 to the found value in the calibration, of if other motors have different behaviour. We could simply try it :)

One last graph: Smallest sprocket, throttle only, slow acceleration to max speed on the roller trainer, about 50V battery voltage, 20 amps --> 1kW power :cool:
1775063735470.png
 
This happens in Windows and Linux, in any browser. If a 52V option were added, I'd hardly be able to select it.
OK, as long, as @mdi has not fixed it, I can prepare a bin file with 52V as default, but you have to do a torquesensor calibration then to reset the Virtual EEPROM to the default values and have to run the position sensor calibration again. Perhaps, I'll add the offset of 60 to the position calibration, then you can test this workaround also!
 
Back
Top