KT motor controllers -- Flexible OpenSource firmware for BMSBattery S/Kunteng KT motor controllers (0.25kW up to 5kW)

[casainho]

@Stancecoke, I need to put a link on main page to your branch - it has some advanced features and advantages. To where should I link?? maybe some place where you are putting instructions?

 

[ThierryGTLTS]

14S battery with 60V MOSFETs is not possible, you'll blow them, that's normal

Spikes of 60V to 75V will occur depending on your wiring and capacitor value and quality.

So for 60V MOSFETs, maximum 12S for safety.

14S needs 80V or 100V MOSFETs.

Have a Nice Day.

Thierry

 

[stancecoke]

@Stancecoke, I need to put a link on main page to your branch - it has some advanced features and advantages. To where should I link?? maybe some place where you are putting instructions?

I've just added the description to the "Alternative Fork" Page. It is a not revised translation by deepl.com.
We can improve the description, if needed. Some smaller details are currently missing.

regards
stancecoke

 

[honya96]

Guys I am sorry for the misunderstanding, I know its normal to blow 60v mosfet with 14s. (I did not know its just 60v in that controller) Was just saying I cant test the big bike with 6fet. But 18fet is okay with that voltage since it has 85v mosfets.

 

[geofft]

I've tried this with an old-fashioned crt 'scope :-
..this gave a 'rough' result for my (Q128H) motor of about 150 degrees.

I am not sure about that process of scope, I never validated, but it is interesting to see different results. Now that you have the bike training roller, you can put a constant load on the motor and adjust:

...didn't have much success with this, problem is that even with a fixed steady load (on bike training roller) the current draw from the battery is not steady and is constantly moving, making it difficult to estimate an average. In the end both 'scope and meter methods indicated an FOC_READ_ID_CURRENT_ANGLE_ADJUST of 148-152 was correct so I've settled at 150 (Q128H motor).

 

[honya96]

the current draw from the battery is not steady and is constantly moving.

You can try something like this
http://s.aliexpress.com/77bUNzEf?fromSns=Copy

And measure Wh consumed in 2 minutes to get more acurate. Stable vollage input will help.

 

[geofft]

the current draw from the battery is not steady and is constantly moving.

You can try something like this
http://s.aliexpress.com/77bUNzEf?fromSns=Copy

And measure Wh consumed in 2 minutes to get more acurate. Stable vollage input will help.

Maybe one for the future, I think my 'hobby funds' have all been used up for some time....

 

[casainho]

...didn't have much success with this, problem is that even with a fixed steady load (on bike training roller) the current draw from the battery is not steady and is constantly moving, making it difficult to estimate an average. In the end both 'scope and meter methods indicated an FOC_READ_ID_CURRENT_ANGLE_ADJUST of 148-152 was correct so I've settled at 150 (Q128H motor).

Great, thank you!!!

Yes, for me the current also fluctuates - I did used the value shown by the power supply, that may average it already.
I think you are now more confident that you are taking most possible efficiency for your motor.

So, that is great that we now have 2 methods to get that value!

So, 150 (150 - 127) is 23 is 32 degrees angle, a lot!! I wounder if now your controller have lower temperature while running.

Also, with such big fluctuations from motor to motor, I wounder if we running our motors with bad efficiency with original firmware.

 

[geofft]

Also, with such big fluctuations from motor to motor, I wounder if we running our motors with bad efficiency with original firmware.

I'm intending to do some comparison testing (between stock and 'new' firmware) today or tomorrow, should hopefully be able to give you some meaningful information. At this early stage I think I can say the new fw runs no hotter that stock, and maybe just a little cooler... 8)

 

[geofft]

I've got my 'new' firmware installation working well now, so recently reconnected the the 'stock' controller just to see how things compared. My setup is as per Q128H installation in signature line. Some observations:-

Idle current draw (stock) is 80-90mA, new fw 130-140mA, no big deal.

New firmware applies resistance to being pushed backwards, stock firmware does not.

'New' fw is very smooth, quiet and gentle with the motor. Maybe too much so for some tastes, as the stock fw has higher top speed (about 7.5%) and higher torque (I'd guess about 10%). New firmware draws much less max power however, max watts 630 against 850 for stock, so range should be noticeably increased. I'm left with the feeling, however, that the full capability of the motor is not available with the new fw, and some settings within the code could safely be made a little more aggressive.

'New' fw PAS feels really nice, maybe a little slow to build from a standing start but once rolling feels very natural and progressive, and doesn't get ahead of your pedalling like the 'stock' fw tends to do.

'New' fw throttle works generally very well, just a small lag when coming back onto throttle after a brake interruption, but not too bad. I'm now wondering if both this and PAS build up might be improved by decreasing the pwm duty cycle ramp up, I'm currently back to using the default 25.

With 'new' fw, controller was definitely cooler after a ride than 'stock'- I'm not sure if this was down to efficiency gains or simply the fact that the 'new' firmware wasn't able to drive the motor as hard, so not really conclusive at the moment.

Quite a bit of heat is also generated by the LM317 voltage regulators. Probably not a problem at 24v or 36v, but inputting 48v it has to lose a lot of power to get down to 15v and gets very hot in the process, reaching around 90degC. I guess they're designed to run this way but I wonder about their long term reliability at these temperatures. I've fitted them with heatsinks, though I'm not sure how effective they will be inside an enclosed case. Been looking around for possible switch mode replacements for these but space is limited for this, no luck so far.

So overall a positive feeling, as always improvements can be made but considering the complexity of the task you guys have done a great job so far..

 

[casainho]

'New' fw is very smooth, quiet and gentle with the motor. Maybe too much so for some tastes, as the stock fw has higher top speed (about 7.5%) and higher torque (I'd guess about 10%). New firmware draws much less max power however, max watts 630 against 850 for stock, so range should be noticeably increased. I'm left with the feeling, however, that the full capability of the motor is not available with the new fw, and some settings within the code could safely be made a little more aggressive.

Thank you for the feedback, it is really important, since you are not a developer so I think you are not biased.

So original firmware uses more 33% battery energy but gives more ~7.5% speed and ~10% torque.
Can you please tell if you are not hitting the MOTOR_OVER_SPEED_ERPS of 520 ERPs?

I went to look at main, to see if max PWM duty_cycle is defined as max possible, and it is - because could be a bit lower like 245:
#define PWM_DUTY_CYCLE_MAX 254

I have one idea of that more used power, more speed and more torque on original firmware. Do you remember the calcs I did before?

So, 150 (150 - 127) is 23 is 32 degrees angle, a lot!! I wounder if now your controller have lower temperature while running.

I remember to read that motor max speed (over nominal speed) that we can get with advance angle for field weakening is about 30º. And seems that your motor have the hall sensors placed at that +32 degrees as you did measured on that 2 different processes. See here:


In: http://iopscience.iop.org/article/10.1088/1757-899X/100/1/012004/pdf

So, my suggestion is for you to change the FOC_READ_ID_CURRENT_ANGLE_ADJUST (by increasing or even decreasing his value) and see if you get the same higher speed, torque and current. Well, just if you prefer to have higher speed in exchange of less efficiency. You can search on google for "FOC field weakening" to better understand this.

Idle current draw (stock) is 80-90mA, new fw 130-140mA, no big deal.

New firmware applies resistance to being pushed backwards, stock firmware does not.

I think this is related, because that resistance means that motor coils are always energized while motor is stopped... still, the current on them should be 0 because they have the same voltage applied to them (Voltage battery / 2), slight imperfections on the circuit and/or coils, may result on the very small increase of current.
Anyway, I think would be better to have motor without resistance when pushing backwards.... happens that there is a tecnhical issue to make that, that I could not understand yet on how to do that with this motor controllers hardware: start the motor while it is already running freewheeling.

Added this to issue list, so we don't forget: https://github.com/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/issues/27

'New' fw PAS feels really nice, maybe a little slow to build from a standing start but once rolling feels very natural and progressive, and doesn't get ahead of your pedalling like the 'stock' fw tends to do.

'New' fw throttle works generally very well, just a small lag when coming back onto throttle after a brake interruption, but not too bad. I'm now wondering if both this and PAS build up might be improved by decreasing the pwm duty cycle ramp up, I'm currently back to using the default 25.

The slow can also be because of current and speed controllers -- I advice you to play with them first. You should increase:
- MOTOR_CURRENT_CONTROLLER_KP
- MOTOR_SPEED_CONTROLLER_KP

  i16_error = ((int16_t) ui16_target_current_10b) - i16_motor_current;
  i16_output = i16_error * MOTOR_CURRENT_CONTROLLER_KP;

  i16_output = ui8_duty_cycle + i16_output;

You see, the controller output variable (i16_output) is the ui8_duty_cycle + (i16_error * MOTOR_CURRENT_CONTROLLER_KP). If you increase that constant, the response should be faster but if to fast, you may also feel an oscillation on motor torque.

Also, unlike PAS, throttle have a low pass filter that adds lag/delay (YOU SHOULD PLAY HERE FIRST!) -- see void read_throotle (void). You should know by now how to reduce or increase that lag/delay, by changing that ui16_throttle_value_accumulated >> 2.

Quite a bit of heat is also generated by the LM317 voltage regulators. Probably not a problem at 24v or 36v, but inputting 48v it has to lose a lot of power to get down to 15v and gets very hot in the process, reaching around 90degC. I guess they're designed to run this way but I wonder about their long term reliability at these temperatures. I've fitted them with heatsinks, though I'm not sure how effective they will be inside an enclosed case. Been looking around for possible switch mode replacements for these but space is limited for this, no luck so far.

Well, for me, the most heat comes from that power resistor, where I think the most voltage/power drop happens:

https://opensourceebikefirmware.bitbucket.io/development/Motor_controllers--BMSBattery_S_series--Hardware_mods.html#h1-2

 

[geofft]

Thanks Casainho, lots for me to take in there, will get back to you with answers (or more questions...!) when I can.

TBH I'm still struggling to understand the code but have now ordered a book on 'C' programming so hopefully may soon be more proficient. Should make for some fascinating bedtime reading.... :?

 

[casainho]

TBH I'm still struggling to understand the code but have now ordered a book on 'C' programming so hopefully may soon be more proficient. Should make for some fascinating bedtime reading.... :?

That's not my idea for you need to understand C code. Most things I show, like that of delay of throttle signal, are more like tricks of digital electronics and math.

 

[casainho]

I got a contact back from Podride and as expected, for a different vehicle of a bicycle, some specific features are desired and I think our Flexible OpenSource firmware is a great that
Let's see if they need our help. And they are using a central motor, as seen on the videos - that work from Stancecoke for higher frequency PWM, to target this high speed motors, may prove to be important.

PodRide - the 4 wheel ebike that looks like a car

 

[honya96]

@geofft - try if the regulator and resistor is getting hotter than stock fw

Try increasing P1 (250,270) and test if you get higher real speed (gps or external speedometr or noload if you can notice.)

10% lower torque - test if you get the same battery amps, set it in app so you will get the same, if the torque is still lower at same batt. A, then it can be that phase amperage is lower. But that makes some difference only accelerating from lower speed, not top end.

Try searching LM2596HVS on Aliexpress or ebay. It has simple board, you can get rid of the capacitors (they are on controllers board) and replace the petenciometer by resistors. Then It will fit in

@Casainho - I am sure he is not hitting max erps

With hi-end controllers, it is running at max efficiency angle untill the current starts decrease by hitting max erpm then it gradually adds the angle shift (up to some max set) to maintain current draw at a set percentage of max. Battery amps.

With adaptto I am able to get well over 30% higher speed with this function, but I guess its really advanced and hard to implement feature :|
No need for it now.

"" I could not understand yet on how to do that with this motor controllers hardware: start the motor while it is already running freewheeling.""

I think that original firmware with direct motor starts to energize them first so it knows what to do and then adds power, which actualy brakes quite a bit if you are rolling and makes for a really slow response time and overall bad experience with direct motor.

As it is now with your branch the reaction is not faster, maybe changing the values you mentioned will help. :wink:

With Stencecoke's new branch, the throttle reaction is REALLY immediate. Can't immagine an improvement. But on the other side, it has problem starting from standstill - I think its beacuse it does not have square wave start? Or some problem in my settings....

 

[geofft]

@geofft - try if the regulator and resistor is getting hotter than stock fw

..no, it's the same with either firmware and all my controller 'collection' (2 for testing, one stock).

All other comments noted.

 

[casainho]

With hi-end controllers, it is running at max efficiency angle untill the current starts decrease by hitting max erpm then it gradually adds the angle shift (up to some max set) to maintain current draw at a set percentage of max. Battery amps.

With adaptto I am able to get well over 30% higher speed with this function, but I guess its really advanced and hard to implement feature :|
No need for it now.

Hmmm, it is something I think could be done with current firmware, maybe.
That max erpm you refer, it is a value that user must define, right? is the motor max RPM for a specific battery voltage value, right?
FOC_READ_ID_CURRENT_ANGLE_ADJUST is not a variable right now, but we can make it a variable and increase it or decrease to get the desired angle advance dynamically when hitting the motor max ERPM.
Yes, It is not a priority, at least for me. But would be great to document this idea and post on issue list.

"" I could not understand yet on how to do that with this motor controllers hardware: start the motor while it is already running freewheeling.""

I think that original firmware with direct motor starts to energize them first so it knows what to do and then adds power, which actualy brakes quite a bit if you are rolling and makes for a really slow response time and overall bad experience with direct motor.

Good that you describe the original firmware behavior. That is what I don't like with direct drive motors...
I am being thinking on this, and like Stancecoke told before "let the current controller do it's job". I mean, when motor is freewheeling (with coils disabled) and we want to start driving it, we need to apply:
1. phase voltages in phase with BEMF
2. phase voltages with same amplitude as BEMF

1. the start value of phase voltage is done by the hall sensors and if motor current is near zero, the angle correction from FOC should also be near zero, but anyway, FOC algorithm should react faster to this change and setup the correct value.

2. let's say with current motor speed, the BEMF value is 30V for a 36V battery voltage, the desired duty_cycle is 212 (with 255 for the 36V) but we can't know it in advance. We can start with duty_cycle = 0 and the motor will brake!! but if we configure regen current to be minimum like 1A, the regen current controller will fast and automatically increase duty_cycle so the regen current will keep at 1A and not at a max value as would be if duty_cycle = 0. So, how to detect that regen current controller did setup the correct duty_cycle and that end of this phase??

Does this makes sense??

With Stencecoke's new branch, the throttle reaction is REALLY immediate. Can't immagine an improvement. But on the other side, it has problem starting from standstill - I think its beacuse it does not have square wave start? Or some problem in my settings....

I am pretty sure Stancecoke branch is using the same motor controller code but differs on the current and speed controllers -- as he told before, he uses a PID controller and may be using coefficients that makes the response fast.

Unlike original firmware, our motor controller code don't use square wave.

Maybe you need to adjust:

// This value must be found experimenting. Motor should rotate forward and have a good torque,
// a value to much higher or lower will make the motor not having torque while the motor starting up.
// This value can be tested with motor blocked, at startup, to found a value where is does have the best torque at startup
// A value of MOTOR_ROTOR_OFFSET_ANGLE = 202 was found to be a good one for BMSBattery Q85 motor with S06S controller
#define MOTOR_ROTOR_OFFSET_ANGLE 202

 

[honya96]

Sorry by erpm I meant max motor rpm for given battery voltage.

Middle part is too much for my head now, will think about it later


At ALTERNATIVE FORK
what doesn't work:
Block commutation during start-up

= 6 step? = square wave?? Or I am wrong?

I think it tries to start with sine wave but fails after half a turn and iscilates without torque, I have to push It a bit and then it runs ok

 

[casainho]

At ALTERNATIVE FORK
what doesn't work:
Block commutation during start-up

= 6 step? = square wave?? Or I am wrong?

I think it tries to start with sine wave but fails after half a turn and iscilates without torque, I have to push It a bit and then it runs ok

It starts with sinewave values, but 1 point of the sinewave at each hall sensor commutation, so, it is like 6 steps but we can't say it is.

 

[stancecoke]

I think it tries to start with sine wave but fails after half a turn and iscilates without torque, I have to push It a bit and then it runs ok

As casainho already mentioned, please play around with the value of motor specific angle a little. I hope you will find a value, that fixes your problem.

Motor specific angle: with this value the timing of the motor control can be changed. As a result, manufacturing inaccuracies of the Hall sensor positions in the motor can be compensated. Only change if the engine starts badly.

Does the motor start, if you open the throttle more?

I am pretty sure Stancecoke branch is using the same motor controller code but differs on the current and speed controllers -- as he told before, he uses a PID controller and may be using coefficients that makes the response fast.

To be precise, it is a PI controller, there is no differential part. :wink: But you are right, the fork uses the same basics for commutation, the difference is in the way to control the current.

regards
stancecoke

 

[geofft]

'New' fw is very smooth, quiet and gentle with the motor. Maybe too much so for some tastes, as the stock fw has higher top speed (about 7.5%) and higher torque (I'd guess about 10%). New firmware draws much less max power however, max watts 630 against 850 for stock, so range should be noticeably increased. I'm left with the feeling, however, that the full capability of the motor is not available with the new fw, and some settings within the code could safely be made a little more aggressive.

Can you please tell if you are not hitting the MOTOR_OVER_SPEED_ERPS of 520 ERPs?

I don't think this is happening, but I'm not sure how to check it - is there some kind of display (or other) indication?

 

[casainho]

Can you please tell if you are not hitting the MOTOR_OVER_SPEED_ERPS of 520 ERPs?

I don't think this is happening, but I'm not sure how to check it - is there some kind of display (or other) indication?

What is your P1 value ((motor magnets/2) * motor gear ratio) ? What is your wheel size and max wheel speed in km/h are you getting?

 

[geofft]

My P1 is set to 211 (16 magnets x 13.2 gear ratio).
26" wheels
max speed ~ 28kph

 

[casainho]

My P1 is set to 211 (16 magnets x 13.2 gear ratio).
26" wheels
max speed ~ 28kph

So, your wheel should be rotating at about 230RPM. The motor inside will rotate at 230 * 13.2 = 3036RPM; 3036/60 = 50.6 RPSeconds.
16 magnets / 2 = 8 poles; so in ERPS ---> 50.6 * 8 = 405 ERPs.

You will hit the MOTOR_OVER_SPEED_ERPS of 520 ERPs, at ~36km/h.

 

[geofft]

So, your wheel should be rotating at about 230RPM. The motor inside will rotate at 230 * 13.2 = 3036RPM; 3036/60 = 50.6 RPSeconds.
16 magnets / 2 = 8 poles; so in ERPS ---> 50.6 * 8 = 405 ERPs.

You will hit the MOTOR_OVER_SPEED_ERPS of 520 ERPs, at ~36km/h.

Ok, many thanks, that figure seems to make perfect sense.