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

I've tested the maximum electrical speed of the rotor without load (full throttle + chain put off) in dependence of the battery voltage now.
The speed is calculated from the z-signal of the encoder. I increased the voltage from 30V to 50V with the lab power supply:
1774621629408.png

As expected, the dependence is strictly linear. I don't know the mechanical gear ratio of the M510, otherwise we could calculate the cadence from the erps (electrical revolutions per second).
Of course the current stays near zero without load...
Edit: I've measured the chain wheel speed with a simple speedo now and get a motor constant "Kv" of 2.85 rpm/V so the above graph with cadence, not with erps of the rotor looks like this:

1774631855986.png

If the chain wheel spins faster with the original Bafang firmware, it will use field weakening. It's absolute no problem to use field weaking in our project also, but I want to avoid that, as it heats the motor unnecessarily.


Next test: breaking the wheel with full throttle from top speed (smallest sprocket) on the roller trainer. Battery Current limit: 12amps. Battery: old 10s. The maximum dutycycle ist not not reached, as the controller limits the battery current. So in this setup I can't check the issue, that is reported. The max power with this setup is about 400W as the voltage of the old battery drops to about 33V @ 12A. I'm just charging my only 13S battery, but I guess it is not in a much better state than the 10s :eek:


1774624619107.png

Next test: max battery current set to 20 amps, 10s battery. Pedaling additionally to full throttle:
1774628485555.png

So I can see no abnormal behavior. Everything is just like in the textbook.

regards
stancecoke
 
Last edited:
stancecoke said:
So I can see no abnormal behavior. Everything is just like in the textbook.
Click to expand...
I ran a similar test on the "stand" :D
I connected the chainring to the crank to measure chainring RPM using the controller. The maximum RPM without load was 181 (55 volts).
I created a load using the divine Shigur's and connected the throttle. I easily got 20+ amps at high cadence (low cadence is difficult to achieve with braking and throttle).
It seems the problem is with the assist algorithms. The motor is capable of running at high cadence.


UPD. RPM max for chairing = 190 (floating result 181-190)
 
Last edited:
At higher cadense it is more difficult to keep the same strong pressure on the pedals so maybe this is an ussue. The algorithm should increase the torque sensor sensitivity at higher cadense. Higher cadense - - > higher torque sensor sensitivity.
 
Avatarkhorn said:
The maximum RPM without load was 181 (55 volts).
Click to expand...
Then I have to adjust the cadence calculation, at 55V the chainwheel speed should be slightly below 160 rpm, according to my measurements. But perhaps you can check the cadence with a simple speedo also.

Avatarkhorn said:
It seems the problem is with the assist algorithms.
Click to expand...
I will check it step by step. There are just a few lines of code that are relevant....

C: 
MS.p_human=(uint16_t)((float)(MS.cadence*(torque_cumulated>>MS.TQfilter))*0.00342); //in Watt

MS.i_q_setpoint_temp= MP.TS_coeff*MS.p_human*interpolate_assistfactor()/100;

uint8_t interpolate_assistfactor(void){
    uint16_t interval= speedlimitx100_scaled/5 ;
    uint8_t ui8_speedfactor=0;
    uint8_t ui8_speedcase=0;
    if (MS.Speedx100 < interval)ui8_speedcase=0;
    else if (MS.Speedx100 < 2*interval)ui8_speedcase=1;
    else if (MS.Speedx100 < 3*interval)ui8_speedcase=2;
    else if (MS.Speedx100 < 4*interval)ui8_speedcase=3;
    else ui8_speedcase=4;

    ui8_speedfactor = map(
            MS.Speedx100,
            ui8_speedcase*interval,
            (ui8_speedcase+1)*interval,
            MP.assist_profile[level_to_array_element[MS.assist_level]-1][ui8_speedcase],
            MP.assist_profile[level_to_array_element[MS.assist_level]-1][ui8_speedcase+1]);
    return ui8_speedfactor;
}

int32_t map (int32_t x, int32_t in_min, int32_t in_max, int32_t out_min, int32_t out_max)
{
  // if input is smaller/bigger than expected return the min/max out ranges value
  if (x < in_min)
    return out_min;
  else if (x > in_max)
    return out_max;

  // map the input to the output range.
  // round up if mapping bigger ranges to smaller ranges
  else  if ((in_max - in_min) > (out_max - out_min))
    return (x - in_min) * (out_max - out_min + 1) / (in_max - in_min + 1) + out_min;
  // round down if mapping smaller ranges to bigger ranges
  else
    return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}
 
Last edited:
stancecoke said:
You can fork it and run the algorithm with different values for cadence, speed, etc. I have not found any abnomality so far....
Click to expand...
I'm not very familiar with code. Is it normal for the "uint16_t human_power" variable to have no effect?
The formula for determining human_power works. But if you change this parameter to the value "uint16_t human_power," nothing changes.
 
So, today I went out on the bike with the EBiCS firmware and a cadence counter. Because I replaced the stock cranks with shorter ones (152 mm), I was getting an incorrect reading without the counter. The power drop issues started at 125 RPM and became noticeable at 130 RPM. I couldn't accelerate above 140 RPM because I hit the "wall" effect.
 

Attachments

  • IMG_20260328_125557.jpg
    IMG_20260328_125557.jpg
    7.5 MB · Views: 11
stancecoke said:
Хорошо, это в том же диапазоне, что и сообщал @@Waynemarlow для оригинальной прошивки M510 в #123.
Click to expand...
There's one caveat. I tested my M510 with a no-load throttle test using the stock firmware. The maximum cadence on the display was 155 RPM. That's the value you calculated earlier. Could it be that EBiCS is misreading the cadence?
 
Have to agree that very very few riders can spin over any short period of time above 100rpm. Most EBike riders operate in that 50 -80 rpm cadence where the human body can actually covert torque into rotation. A few like myself like that 80 - 100 rpm from historical reasons of riding analogue bikes where a constant spin rate using very close ratio gears was the most efficient.

With EBikes using the additional torque available we can now have less number of gear ratios, spin much slower conserving energy losses from the need to rotate our legs at a rapid rate and enjoy riding trails at speeds which on analogue bikes were unachievable other than to Olympic athletes.
 
Waynemarlow said:
Most EBike riders operate in that 50 -80 rpm cadence where the human body can actually covert torque into rotation. A few like myself like that 80 - 100 rpm from historical reasons of riding analogue bikes where a constant spin rate using very close ratio gears was the most efficient.
Click to expand...
The cardiovascular system recovers faster than muscles. Therefore, for most people, a high cadence is more beneficial over long distances.
In the E-MTB world, there's a recent trend toward short cranks, partly to support a high cadence.

140 RPM is high, especially without clipless pedals. This is one reason to question the accuracy of the display on the EBiCS.
 
Avatarkhorn said:
The cardiovascular system recovers faster than muscles. Therefore, for most people, a high cadence is more beneficial over long distances.
In the E-MTB world, there's a recent trend toward short cranks, partly to support a high cadence.

140 RPM is high, especially without clipless pedals. This is one reason to question the accuracy of the display on the EBiCS.
Click to expand...
Shorter cranks are now the norm but perhaps they were not introduced for higher cadence as you perhaps think. Some years ago a few of us were reporting striking the ground ( pedal strikes ) on pedalling in rough ground with full suspension bikes. To get around this the bottom bracket height was both raised and crank lengths shortened. About the same time 48volt motors ( over volt ing 36volt motors ) were beginning to make an appearance in the likes of the TSDZ2 project. Benefits were felt immediately in that the motors now spun into that sweet rpm most analogue riders were used to and short cranks were now needed.

At the end of the day any motor designer can design to achieve a certain rpm with any voltage. Bafang seem to have a design limit of about 120rpm. Then the likes of us here come along and over volt the motor and get another 10% or so. Riding the Bosch series of mid motors, they seem to like max torque much lower in the rpm as this then makes the rider feel that the motor is much more powerful than it really is ( most rider think acceleration is the same as torque ). We do fairly often drag races up a long hill here locally and until the Avionox motor arrived, all motors were pretty similar ( all seem to peak in that 750 - 800 W’s )
 
Last edited:
stancecoke said:
You could try to follow the traces from the opamp to the processor with the multimeter. There will be some resistors and/or ferrite balls on the way :)
Click to expand...
It looks like:
Out A - Phase A
Out B - ADC Battery
Out C - Phase C
Out D - Phase B
I'm ready to test it on M560 as soon as I order the fuse :D
 
stancecoke said:
I've just published V0.006:

github.com

Release EBiCS_for_M510_BL3+38_V0.006 · EBiCS/BAFANG_GD32F303RCT6

change log: V0.006: add battery indicator based on pack voltage add trip indicator adjust cadence calculation bugfix for power drops bugfix for PWM on at startup increased frequency for cadence fra...
github.com github.com

I've added the bin files for both bootloader versions, 3 and 38.

regards
stancecoke
Click to expand...
I did a few short rides:
1) The cadence counter works more accurately.
2) Now the wall effect occurs at ~90-100+ RPM (essentially, the same as before, the numbers on the display have changed). Even active pedaling while standing doesn't help.
3) At the start and at low RPMs, the power is high, just like before.

Could this be due to the missing function described in #229?
 
Can I suggest that amplification of human power should not be linear with cadence rpm ? At higher rpms the ability of our legs to produce torque on the pedals gets diminished, I’m presuming the torque sensor sensitivity needs to rise as rpm rises so that we the rider can get response at higher revs with a lot less torque on the pedals. Does the amplification factor also have to rise as rpm rises.

@mbrusa did a lot of the development in this area on the TSDZ2 FOC and ended up with a pretty nice development, it maybe worth contacting him to see how he handled this.
 
Waynemarlow said:
At higher rpms the ability of our legs to produce torque on the pedals gets diminished
Click to expand...
Sure, but the torque has not to be high if the cadence is high. I've tested a lot of algorithms for calculating the motor current setpoint and of course I tried exponential approaches. But I ended in this quite simple logic, as it gives the most natural feeling and sensitive response over the whole cadence range. We will see tomorrow, if something goes wrong in the code.
You don't have to ask @mbrusa how the calculation is done in the TSDZ2 project. You can simply check the code ;)

github.com

TSDZ2-Smart-EBike-1/src/ebike_app.c at 2d14b3f0bb0cf191a1fc04f0a54cf0e727540766 · emmebrusa/TSDZ2-Smart-EBike-1

TSDZ2 Open Source Firmware adapted to VLCD5-VLCD6-XH18 displays - emmebrusa/TSDZ2-Smart-EBike-1
github.com github.com
 
Last edited:
You must log in or register to reply here.

Similar threads

DaDo.Bzz
K1 Flash - simple Firmware update and Calibration for Bafang CAN motors. Speed Limit and Power adjustment settings (M510, M560, M820, M620 ...)
Replies
18
Views
14,311
DaDo.Bzz
DaDo.Bzz
Back
Top