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

[Waynemarlow]

For mountainbiking this profile is suggested here:

Stancecoke the Nyon display was the first gen Bosch attempt at customisable user profiles. Things have moved on a lot since 2021 In the mid motor sector. The speed influence were somewhat questioned by us users at the time. It’s been now superseded by the Smart system which has no such speed influence. The Flo App allows the following to be changed on the smart system.

Motor Assistance Parameters

• Support Level: Adjusts the overall level of assistance the motor provides based on your own power. This can be set from approximately -5 to +5 in the app, with +5 providing about 150% of the standard support level for that mode.
• Dynamics (Acceleration Response): Controls how quickly the motor responds when you start pedaling. A higher value provides an immediate, powerful boost, while a lower value results in gentler, more gradual support.
• Maximum Torque: Sets the peak pulling power (in Nm) the motor can deliver, which is especially useful for steep climbs and rapid acceleration.
• Maximum Power: Affects how quickly you reach and maintain the maximum supported speed. Higher power ensures faster progress on hills.
• Maximum Speed: The top speed at which the motor provides support can be reduced from the legal limit (e.g., 25 km/h or 15.5 mph in the EU, higher for S-pedelecs) down to a lower, safer speed if desired. (Note: Increasing the legal speed limit requires third-party tuning devices and is generally not officially supported by Bosch).

I re looked at the Bafang Go and Fazua Apps I have on my phone and neither has any mention of speed other than max speed in the custom user profiles.

 

[stancecoke]

• Support Level:
• Dynamics (Acceleration Response):
• Maximum Torque:
• Maximum Power:
• Maximum Speed:

What is the problem?! You have to keep in mind, what is behind this parameters, they all are trivial.
Support Level: in the way you describe it, it's just an offset on the assist characteristics defined by the manufacturer, that is speed dependent for sure. Our assist factor is settable per level and per speed range already
Dynamics: p- and i- constant of the iq control loop. Settable in the config.h already, I can make it settable in the CanableTool
Edit: tuning the control loop by the user is too critical (risk of magic smoke ), better tune the filter for the torque signal.
Maximum torque: settable per level already (iq current)
Maximum Power: could be done with the battery current (electrical power) or with iq* motor rpm (mechanical power), but I prefer to get full power in any level with pushing hard enough. I can see no sense in limiting the maximum power per assist level
Maximum speed: settable per level already.

Having a speed dependent assistance is essential for me, if you don't want to use it, just define a constant assist factor for all speed ranges.

Sadly the curves shown here are not speed or cadence dependent, so we can't learn too much from them...

https://www.pedelecforum.de/forum/index.php?threads/unterstuetzungsstufen-bosch-im-detail.116820/

 

[Waynemarlow]

Having a speed dependent assistance is essential for me, if you don't want to use it, just define a constant assist factor for all speed ranges.

Your knowledge is way in advance of mine and I‘m looking forward to trying this concept. If we can dial out the speed factor then it’s up to the user.

 

[stancecoke]

DJI has a 8x multiplier so you need to input just 125w to get 1000w of assistance

I've added the multiplier now, I use the field "Startup angle" for the input.
All values in the torque table are multiplied with this value. The multiplier has no effect on the max current and max speed setting!
So, you can set any amplifying factor you like. With 50W human power you can get 3kW motor power, if you want . And of course everyone has to care himself, what the motor, the controller and the battery is capable of.

https://github.com/stancecoke/BAFAN...mmit/e221275267273dcbd10008f5da52057366f4e986

 

[phobos]

With 50W human power you can get 3kW motor power, if you want .

That would be fun, like a 0-1 switch

Thank you for your effort kind sir.

 

[stancecoke]

One important step forward: I've managed to use the original bootloader to flash the firmware with the canable tool. It was a little tricky, but worked in the end:

GD32F303: Bootloader der Originalfirmware für Open Source Projekt nutzen

www.mikrocontroller.net

 

[phobos]

Thats a big milestone. We need one tool less and its more user friendly this way. Easier to iterate and tinker with the soft as well. In my experience the most popular projects tend to be the ones that are easy to work with

 

[stancecoke]

We need one tool less and its more user friendly this way.

I just found, that the firmware on the hubmotor controller (BOOTLOADER_V38) starts at page 9 (offset 0x4800) while on the M510 (BOOTLOADER_V3) it starts on page 8 (offset 0x4000). This will not matter for the user, but makes it a little more complicated for me, as I have to compile the bin files with different code and linker settings
I guess it will be no matter of the hardware, but simply of the bootloader version....

 

[DPC18RI]

Good work! i follow reading

 

[stancecoke]

Update: 0x4800 is not the start of the firmware itself, but still a part of the bootloader in BOOTLOADER_V38. The firmware starts at Page 21 (offset 0xA800). I was able to flash it with the Canable Tool and it is running now. I will try to extract the firmware from the original flash dump and make an update bin file out of it, to check if I can flash back the original firmware from my open firmware. Then it's safe to play around with it for beta users, as they can always fall back on the original firmware...

 

[stancecoke]

I will try to extract the firmware from the original flash dump

Worked . I was able to flash the original Bafang firmware with the Canable Tool from my open firmware! I've added the original firmware update file to the repo:

BAFANG_HUB_GD32F303RCT6/documentation/CRA101.C1.1CRA.C3615F801308.bin at master · stancecoke/BAFANG_HUB_GD32F303RCT6

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

github.com

Edit: new finding, the bootloader seems to calculate the checksum over a certain flash memory area at start up and keeps rebooting, if it doesn't match. So I have to shift the virtual EEPROM to a memory area, that is not watched, otherwise the processor doesn't boot the firmware itself anymore after changing values in the Canable Tool....

 

[danandrei96]

Hello!
I have been following the development of firmware for a while for the KT, Lishui and now the Bafang controllers and I really have to thank you for all your work, it's an awesome project.

Can I please ask, which controller would you recommend now and in the future for running the open source firmware?
I have a KT controller at the moment which I was going to flash but decided to buy something better instead so I can experience true FOC and more flexibility while keeping the stock KT as a fall-back.
For reference, I'm just looking for a small controller (6FET) for a hub motor to run 15-20A at 52V, using throttle and basic PAS (no torque sensor)

For Lishui, it seems a bit difficult to find a suitable model (with the "F" number) for sale so I would really appreciate if anyone can provide an Aliexpress link or similar.
Alternatively if you believe the Bafang A101 is the better model, that one seems much easier for me to source.

I appreciate any advice you can offer. Thank you

 

[stancecoke]

I'm just looking for a small controller (6FET) for a hub motor to run 15-20A at 52V, using throttle and basic PAS (no torque sensor)

Why do you want to use an open firmware then?
My favourite controller is the battery holder integrated JYTCon at the moment, as it allows very clean and stealthy setup.
The Lishuis are in the Phoebe Liu EV parts shop again, but they are not shipped to Germany
They are offered here also, but quite expensive.

The open Bafang firmware has no simple PAS implementation at the moment. That has no priority for me, so it will take some more month...

 

[danandrei96]

Why do you want to use an open firmware then?
My favourite controller is the battery holder integrated JYTCon at the moment, as it allows very clean and stealthy setup.
The Lishuis are in the Phoebe Liu EV parts shop again, but they are not shipped to Germany
They are offered here also, but quite expensive.

The open Bafang firmware has no simple PAS implementation at the moment. That has no priority for me, so it will take some more month...

Hi and thank you very much for your reply.
I want to use open firmware so I can try true FOC and generally more customisation. I might also try to measure motor temperature and do some other modifications in the future, maybe even experiment with (a very small amount of) field weakening.
Also I get bored and like to tinker with stuff (I'm an electronics engineer by trade) so the open firmware sounds like a lot of fun.

To me it looks like the Phoebe Liu page is out of stock, but maybe that's because I'm in the UK.
I had another search on AliExpress and had a bit more luck finding the new Lishui with the green label (I think you said most of the new ones are FOC and therefore compatible?)

My bike has a dedicated space for the controller (big enough for the KT 6FET but probably not the 9) so I'd like to keep the controller in there if I can.

How hard would it be to port sections of the main firmware to the bafang controller, such as the PAS? I'm definitely not a firmware expert but I've dabbled here and there so I could maybe give that a try

 

[stancecoke]

How hard would it be to port sections of the main firmware to the bafang controller, such as the PAS?

The firmware for the hubmotor controller is about 90% before publishing a first beta version.
The simple PAS is mainly one line of additional code, but I am initially focusing on making the most important parameters adjustable via the Canable Tool so that users do not have to compile themselves.

 

[stancecoke]

The firmware for the hubmotor controller is about 90%

I've spend some time for documentation now and updated the readme in the github repo. The first release needs some more time, as I want to test the firmware on my tinker bike first. On the test stand it works properly with torquesensor (emulator) and throttle operation.

BAFANG_HUB_GD32F303RCT6/README.md at master · stancecoke/BAFANG_HUB_GD32F303RCT6

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

github.com

 

[stancecoke]

I found a further difference in the processor pinout between the M510 and the CRA101 hubmotor controller. PAS1 and PAS2 are on different pins. On the hubmotor controller this pins are on the torquesensor header, but the wires from the 6pin Higo torquesensor connector are not connected to the PCB. Interesting, that both controlles have UART function on the PAS pins. Maybe there is a hidden function like the possibility of doing firmware updates for the torquesensor over the PAS1/PAS2 pins.

 

[stancecoke]

that both controlles have UART function on the PAS pins

I'm sending debug data on UART4 (unused PAS pin on the hub motor controller) now, that's quite useful in several situations. Just for testing I've plotted the i_q current (green) and i_q current setpoint (blue) (in ADC values), the battery current in mA measured by the DC rail shunt (black) and calculated from motor current * duty cycle (red). This is the Shengyi Middrive as motor and the BionX IGH as generator/load on my testbench.
UART4 has no DMA channel, so the data has to be send byte by byte by software, but it works better than expected, it doesn't mess up the FOC control...

 

[Deko]

I'm sending debug data on UART4 (unused PAS pin on the hub motor controller) now, that's quite useful in several situations. Just for testing I've plotted the i_q current (green) and i_q current setpoint (blue) (in ADC values), the battery current in mA measured by the DC rail shunt (black) and calculated from motor current * duty cycle (red). This is the Shengyi Middrive as motor and the BionX IGH as generator/load on my testbench.
UART4 has no DMA channel, so the data has to be send byte by byte by software, but it works better than expected, it doesn't mess up the FOC control...

View attachment 383645

That's cool. Unfortunately, the focus is on the motor wheel, and I understand that what you use is primarily this product for your needs. But most people here have modern M510, M560, M820, M500, M600, M420 card motors, etc.. It would be cool if this project didn't end with just a motor wheel, the previous age of technology.

 

[Deko]

It makes no sense to you, I understand, but we still hope that there will be software for the m510, 560, 820, and so on.

 

[Deko]

Unfortunately, if this is a motor-wheel-only product, it's a disappointment and we'll have to make do with what we have.

 

[stancecoke]

the previous age of technology.

Please don't start a religious war here. A mid-drive has only a very limited range of applications in which it can play to its strengths, steep long ascents, that nearly nowhere exist on public roads. In the vast majority of cases, the hub motor is the better choice.
The M510 is already running with this firmware, but I'm concentrating on the hub motor controller for developing the interface to the Canable Tool at the moment.
With the Shengyi middrive I'm facing an issue. The motor starts to rattle and draw a lot of power at a (very) high speed when unloaded. This is not a duty cycle issue; it always occurs at exactly the same speed about 27000 erpm, regardless of the battery voltage. Perhaps the hardware has filters that are too strong on the Hall inputs. This issue doesn't appear on hubmotors, as they don't reach this critical speed.

 

[DPC18RI]

With the Shengyi middrive...

I understand you use the BionX IGH as "load" but how about the Shengyi mid motor? Is the CRA110 hub controller connected to it omitting the Shengyi controller or does the Shengyi controller also have a GD 32 processor and you test your firmware this way on the Shengyi?

To be honest, I don't know anything about Shengyi but as mid motor i suppose it has his own internal controller? Does it?
So i was wondering how to picture it regarding how it is used with the CRA110 hub controller.

 

[stancecoke]

So i was wondering how to picture it regarding how it is used with the CRA110 hub controller.

The Shengyi middrive uses an internal Lishui controller originally, but I routed out the phase and hallsensor wires and fire it withever controller I'm tinkering actually. I did some research, 27000 erpm is not that much for a geared hub motor, I will try if the original firmware works with this motor and if yes, if this rattle appears with this also.

 

[phobos]

In the vast majority of cases, the hub motor is the better choice

I agree here, the problem is the torque sensing hubs are way less popular than torque sensing mid drives. I think that people who prefer the torque sensor bicycle-like feel get attracted to mid drives for that reason. Marrying a hub drive with a torque sensor requires more effort than buying an off the shelf mid drive product that offers this out of the box.