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

[stancecoke]

Windmeile.com has this CAN sensor and you can get it from AliExpress also.
But I don't own a controller for the CAN sensor. So I have no use for a CAN emulator.
But if someone has interest, I can provide the schematic and the hexfile for a Blackpill board at least.

 

[DPC18RI]

Yes i'm interested so please do. I found one in my box which i had labeled "Blackpill" but never used. It looks like this is a correct one i can use? Probably need to use STM link utility? Special settings needed for transfer the hex file to the Blackpill?

Because when i used Link utility the first (and only time), it got me... Reading a display chip it said read protected, "disable read protection and try read again". And after that the whole chip was erased without a warning lol.

 

[stancecoke]

The first test run with my tinker bike on the roller trainer was successful
For debugging, I send the human power calculated from torque*cadence*2Pi as "calories" to the Drive Data screen.
I have to check some calibration factors, but it runs proper so far.

 

[stancecoke]

i had labeled "Blackpill"

I just checked the Datasheet of the STM32F411, it has no CAN. So we would have to take a "Bluepill" board with the STM32F103.
Would be something like this:

 

[DPC18RI]

That would be great with a header for analog and one for Can sensor. I looked at your CR A101.C controller at Windmeile which has the round connector for the sensor. The strange thing is that Bafang shows this controller with the square / trapezium connector and indicates Can H an Low for it...
There seems to be also an "conversion" cable from "round" to "square" for controllers with "square" plug which then would suggest some of them ? are not using can lines for the sensor itself. I was first under the impression that hub controllers with the "square" sensor plug it ment for torque sensor with can lines...

If you scroll down on that page and below the graph click "view more" then you can see that conversion cable and the pins.

 

[stancecoke]

There seems to be also an "conversion" cable from "round" to "square"

This cable makes no sense at all, if it is just a passive adapter, except you are using a simple cadence sensor without torque sensing function. This might work, if the pins are connected properly. If they are just connected 1 to 1, 2 to 2, .... then even this will not work...

 

[qwerkus]

Can t believe I missed this one: cudos, stancecoke for your dedication to hacking cheap chinese hardware! Although this mean I now HAVE to get myself one of those GD32F303RCT6 board to test your fw...
A quick peek at the code let me wonder though: you don t seem to take advantage of the fpu in your foc code, for a smooth sensorless function for an instance. Why is that ?

 

[stancecoke]

Why is that ?

Because it is easier to just reuse the working EBiCS code with integer math, than writing new code. At points, where I need new approaches anyway, I use float also
For example to get values in physical units, EBiCS does most in ADC values...
There is no general disadvantage in using integers, on processor level it's all just "0" or "1"

BAFANG_HUB_GD32F303RCT6/src/main.c at 9969b9e78baff683269ceb134184e4f2228a4e49 · stancecoke/BAFANG_HUB_GD32F303RCT6

Contribute to stancecoke/BAFANG_HUB_GD32F303RCT6 development by creating an account on GitHub.

github.com

 

[qwerkus]

Because it is easier to just reuse the working EBiCS code with integer math, than writing new code. At points, where I need new approaches anyway, I use float also
For example to get values in physical units, EBiCS does most in ADC values...
There is no general disadvantage in using integers, on processor level it's all just "0" or "1"

BAFANG_HUB_GD32F303RCT6/src/main.c at 9969b9e78baff683269ceb134184e4f2228a4e49 · stancecoke/BAFANG_HUB_GD32F303RCT6

Contribute to stancecoke/BAFANG_HUB_GD32F303RCT6 development by creating an account on GitHub.

github.com

Thanks for your reply. How s sensorless start so far ?

 

[stancecoke]

sensorless start so far

sensorless is not implemented yet. Of course it would be easy to copy-paste the various sensorless start strategies from EBiCS, but maybe I will try HFI some day. But sensorless has no priority at the moment. My focus is on user settable assistance behaviour recently, see the other tread.

 

[stancecoke]

The interface to the Bafang Canable Tool is working now.
I want to define different ride modes next. We can use the "Assist (Full)" Tab for that. But I'm still not sure, which field should be used for what, as the original meaning of the fields in the tab are not transparent to me

 

[aegidius]

To save me reinventing the wheel: if anyone has done it, could they please put up the VESC Tool settings for an M510 running sensorless?

 

[stancecoke]

VESC Tool settings

This thread has nothing to do with the VESC, it's for the original Bafang Hardware.
There is an own thread for tuning the VESC:
https://endless-sphere.com/sphere/threads/vesc-tuning-tips.125527/

 

[stancecoke]

As I understand it, it's already ready, is there any instructions for installing it? I want to install it on my bafang M420

As I don't want to spam the Bafang Canable thread, I'm answering here.

The firmware works in a very basic way, especially the branch for the M510 middrive. Just simple throttle operation is implemented there yet. No display, no torquesensor support.

The master branch for the hub motor controller has more possibilities, the display works and the interface to the Bafang Canable Tool also. I'm working on the assist modes recently.

The most challenging issue is how to use the bootloader to flash a new firmware. I found that the bin files, that are available on the internet are copied 1:1 to the flash memory starting at address 0x08003FE0, so there is no encyption. This are very good news, but I don't know how to make the bootloader update the firmware yet. Any ideas are welcome.

At the moment the firmware has to be flashed by a SWD programmer via the SWD interface.

 

[stancecoke]

I'm working on the assist modes recently

Today I've implemented the phase current- and speed limit scaling per assist level and the "custom ride modes".

https://github.com/stancecoke/BAFANG_HUB_GD32F303RCT6/commits/master/

They can be set by the BAFANG Canable Tool.
With the custom ride modes, you can define different assist characteristics. For mountainbiking you may want high assistance at low speeds. In the city, you don't want much assistance at low speed, to ride carfully through crowded streets.... You can set, what ever you want for each assist level.
Perhaps we can improve the Canable tool to make the custom ride modes settable by drag and drop in the graph, would be a cool gimmik Having one tab for each assist level and then drag the points on the curve by the mouse.
The numbers mean the percentage of the motor power. For example 150 means, if the rider pushes 100W, the motor will give 150W on top. It's limited to max 255 at the moment, due to the 8bit representation, but I will add a user setable multiplier, so you can define any percentage you want.

 

[phobos]

255 is a bit low indeed. At 250w it would be 640w of assistance more or less. DJI has a 8x multiplier so you need to input just 125w to get 1000w of assistance. Neat way of basically having a throttle in your legs and f@%k the rules.

 

[stancecoke]

and f@%k the rules

There is no rule that's limiting the assist factor or the peak power. The only thing, that is limited, is the maximum continuous output power (in Europe). And this is a property of the motor hardware, not of the controller firmware.

 

[Waynemarlow]

Stancecoke, what are your plans to deal with the EMtb requirements ? We need to have no reference to speed. I think that is why the M820 firmware is so poor compared to the M510. At slow speeds it’s really difficult to get max watts and yet on the M510 there seems no speed reference, on the steep sharp climbs on technical single track the M510 can be ridden entirely on the torque of the pedals giving feedback and power modulation. I’ve ridden the later Bosch motors and they too seem not to use speed other than the 15mph top end limit, which if you are not on the road is such a pain when the analogue bikes go past.

The M820 seems to be really dependant on cadence as well and seems to have a really narrow band of useable power whereas the M510 can pushed well into that 110 - 120 rpm and get useable power, even though the torque is decreasing on the pedals.

Adjusting the user profile on the M510 using BESST software and the way it interacts with the engine with its slider bars and simulated power curves at cadence rpm, actually is quite intuitive and works well. On the M820 BESST removes some of the adjustments to only that of the power levels and immediately limits a rider to actually being able to “ tune “ the motor to their needs. It’s a pity that the M820 is so dependant on firmware as it could be quite a good < 600W engine suiting both road and gravel with some cross over to Emtb.

 

[stancecoke]

We need to have no reference to speed

I don't understand your question. On a middrive, we don't need a cadence information to provide the motor power proportional to the riders power.
With my approach you can define a speed dependent assistance, but you don't have to.
I don't know the BESST tool, but is has exactly the same parameters as the Canable tool.
The maximum cadence depends on the KV constant of the motor and the internal gear ratio of the middrive. That's always the choice of the manufacturer. With a given maximum motor current (quality and number of MOSFETs and possibilities for heat dissipation are limiting here), he can make the motor turn fast with low torque, or he can decide to have a high torque with low maximum speed. The firmware can't change this basic behaviour of an electric motor. It can only do field weakening to get higher rpms, but this causes additional heat and a bad efficiency.

 

[Waynemarlow]

In the early development of the TSDZ2 engine there was a lot of discussion on the relationship of cadence torque, power and speed. After a lot of trial and error the general consensus from memory was that speed became almost ignored other than for speed limiting. Although it’s feasible to get max torque in higher cadences if you are an athlete, the great majority of riders cannot get even close to that as soon as your legs are rotating the pedals in a circular motion. For example I like to ride in that 70 - 90 rpm ( probably from riding analogue bikes for far too many years ), my max torque that I can produce is probably at 0 revs standing on the pedals and pulling on the handlebars, at 90rpm it will be considerably less due to the inefficiency of us humans creating rotary motion together with trying to stay on a moving bike.

The firmware has to be able work out my max torque at 0 rpm and also at 90rpm to give me a proportional feeling at all cadences. For example if I reach a short sharp climb up say an earthen bank, I would change to a higher ratio gear which means a higher cadence, the bank will then mean a loss in speed. To maintain that speed I will need more energy from myself and also proportional from the motor via a torque reading from the pedals. If it’s a very steep bank I would expect to get full power at my upper cadence level but the torque on the pedals may well be quite small. The actual speed is irrelevant and by choice only from the rider.

There is another issue in that rapidly EMtb is changing from its original heritage of Mtb where we climbed only to get back to the top on fire roads to reduce fatigue to begin yet another downhill run. The adrenaline rush was the downhill. Today the EMtbs have become so sophisticated in how they magnify our every torque input that often the uphill on very technical climbs at relatively slow speeds is now an equal adrenaline rush to the downhill. Have the EMtbs now moved entirely to a torque/ cadence only requirement ?

Of all the mid motor manufacturers software I’m aware of, none of them use speed as an input. It maybe worthwhile putting a PM across to @mbrusa as I think the relationship between cadence and torque has been well sorted and is available as OS.

 

[stancecoke]

none of them use speed as an input

Sorry, Bosch does exactly that. And Bosch holds 99% market share with middrives. That was my inspiration to implement it this way. But as written, you don't have to define the assist factor speed dependent. But you can do it.
FOC with control of iq is directly controlling the torque. That's a big difference to controlling the battery current like in the TSDZ2 firmware...

But if you have specific suggestions on how to calculate the target value for the motor current, I'd be happy to incorporate them, of course.

 

[Waynemarlow]

Interesting, I may well be out of date then.

At this stage I would rather let you go down your planned route than to confuse.

 

[Waynemarlow]

Stancecoke a quick question. Are we confusing my “ speed “ over the ground in Kph with motor speed in rpm ?

I get the benefits of FOC but cannot see how actual speed over the ground should be part of the motor torque equation as shown in your Canable chart above as “speed range” ?

 

[stancecoke]

cannot see how actual speed over the ground should be part of the motor torque equation

It's quite simple. Riding resistance increases with speed, rolling resistance increases linearly, and air resistance increases exponentially.
So if you want to ride at 30 kph instead of 15 kph, you don't need twice the power, but several times more. Here you can counteract this with a speed-dependent assistance factor, so that you can ride at a moderate level of effort across the entire speed range without having to fiddle with the buttons to change assist levels.

For mountainbiking this profile is suggested here:

 

[Waynemarlow]

Agree sort of, EMtbers tend not to maintain a set speed at anytime The recently released mid motor with a CVT gearbox strives to maintain cadence power and speed in any combination using the CVT adds another complexion.

Something EMtbers use a lot is momentary acceleration, resistance from external forces can be diminishing and yet we need an increase in speed to say lift the front wheel over an obstacle, something to be aware of.

The M510 motors seem to be programmed differently than the M820, they feel quite different in their response. I think the M820 follows a speed biased arrangement, the M510 is only interested in torque at the pedals.