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

casainho said:
Good that you know all that things, that's great.

Let's focus only in one controller. We need to know if firmware is really working and being flashed.

When it works, should, send to LCD the symbol of brake, throttle and battery status.
Also, motor should be like "blocked" when you push the motor by hand, that is firmware controllong the power mosfets - with controller powered off, motor should rotate freely by hand.
If that things don't happen, so for some reason the firmware is not running. Also make sure when you power on, the brakes are released, other way the firmware simple don't run (this is specific to our firmware).

Please test and confirm. I am now thinking on next step.

I have controller tester connected which will show the mosfets switching, no brake icon. No battery showing. (Empty will flash if lvc)

I would like to focus on 12fet now. The one which failed at "write option bytes"
 
flashed by old tool seems to be all working (batt, brake, wattage, speed.) on 12fet but Icant test much since its a broken controller.

edit: motor is blocking when pushed by hand but no reaction to throttle, no throttle icon. pas is showing icon but does not run the motor or even switch a mosfet without motor connected
 
Old tool working on 6 fet also. I am even getting some mosfet switches but I can rotate the motor freely. Then after holding throttle for a while they stop switching and its hard to turn motor. Weird. Maybe I will test on a fully working 6 fet tomorow :wink: but you can give suggestions anyway. Thanks a lot
 
honya96 said:
Old tool working on 6 fet also. I am even getting some mosfet switches but I can rotate the motor freely. Then after holding throttle for a while they stop switching and its hard to turn motor. Weird. Maybe I will test on a fully working 6 fet tomorow :wink: but you can give suggestions anyway. Thanks a lot
So, for what I can understand, you was able to flash and the firmware is running on the controller. You need to test more and give us more details, like what combination of components are you using when testing. Also some pictures make me happy :)
 
What I can tell now, I think the new tool fails to write option bytes and also to flash firmware. Old one works. I will take photos of the whole setup :wink:
 
Despite dreary weather in the UK got a test ride in earlier today, made a few config changes and the bike now rides in the way I like and very smoothly. Pas and throttle both good, just a couple of details with motor wattmeter and battery indicator to mention.

Motor wattmeter now powers up properly at zero, but is over-reading by a factor of around 2 - 2.5. It is also heavily over damped, taking about 10 secs to return to zero when motor drive is cut. Although it powers up at true zero it also has an annoying habit of 'zeroing' at 22 watts in use.

Battery indicator seems to work well but is reading too high. Have only tested this at 12s and under 30% state of charge, but is generally showing 1 bar too high. Battery cell voltage is currently 3.71v (about 15%) but showing 2 bars, not quite right.

Controller felt fairly warm (but not hot) after the ride, but is inside saddlebag whereas the stock controller is under the rack in the air, so difficult to make a comparison. I may try running the stock controller inside the bag when I get time, it will be interesting to see how warm that gets compared with the 'new' firmware.

Later, when you write your feedback, please include what you value that you get with this firmware, comparing to original one.

...for me flexibiliy and user configurability is the key here. It's the ability to add a torque sensor, add ramp up/down, various pas/throttle options/battery config, etc, etc, that will make this more attractive than the manufacturer's firmware. Hopefully once released it would be occasionally updated with bug fixes, code improvements, new features, etc.
Just a little more to do before it's a complete package, but getting closer now.... 8) I'm feeling slightly lonely as the only tester at the moment, it would be good to get other opinions on this. Hopefully soon Honya and others will get up and running and let you know what they think.
 
Thank you for the feedback, it is really important!!
Quick changes I did based on your feedback but I didn't tested, would be great to have your feedback about them.
geofft said:
Motor wattmeter now powers up properly at zero, but is over-reading by a factor of around 2 - 2.5. It is also heavily over damped, taking about 10 secs to return to zero when motor drive is cut. Although it powers up at true zero it also has an annoying habit of 'zeroing' at 22 watts in use.
- reduced by half the current value sent to display (I always din't trust much in my experimental values)
- reduced damping
- reduce 1 unit of current value, in the hope LCD will show 0 watts when motor is stopped
Lines in red were removed and green ones added, so you can review the changes:


geofft said:
Battery indicator seems to work well but is reading too high. Have only tested this at 12s and under 30% state of charge, but is generally showing 1 bar too high. Battery cell voltage is currently 3.71v (about 15%) but showing 2 bars, not quite right.
The table for battery voltages is on main.h, please propose the values that you think are correct. You can even change your main.h and test them:
Code:
#define LI_ION_CELL_VOLTS_MAX 	4.2
#define LI_ION_CELL_VOLTS_100 	4.05
#define LI_ION_CELL_VOLTS_80 	3.93
#define LI_ION_CELL_VOLTS_60 	3.78
#define LI_ION_CELL_VOLTS_40 	3.60
#define LI_ION_CELL_VOLTS_20 	3.38
#define LI_ION_CELL_VOLTS_0 	3.20
#define LI_ION_CELL_VOLTS_MIN 	3.0

And the code that decides which bar to show on LCD, so you can understand:
Code:
#define BATTERY_PACK_VOLTS_100	(LI_ION_CELL_VOLTS_100 * BATTERY_LI_ION_CELLS_NUMBER) * 256
#define BATTERY_PACK_VOLTS_80 	(LI_ION_CELL_VOLTS_80 * BATTERY_LI_ION_CELLS_NUMBER) * 256
#define BATTERY_PACK_VOLTS_60	(LI_ION_CELL_VOLTS_60 * BATTERY_LI_ION_CELLS_NUMBER) * 256
#define BATTERY_PACK_VOLTS_40	(LI_ION_CELL_VOLTS_40 * BATTERY_LI_ION_CELLS_NUMBER) * 256
#define BATTERY_PACK_VOLTS_20	(LI_ION_CELL_VOLTS_20 * BATTERY_LI_ION_CELLS_NUMBER) * 256
#define BATTERY_PACK_VOLTS_0	(LI_ION_CELL_VOLTS_0 * BATTERY_LI_ION_CELLS_NUMBER) * 256


  // calc battery pack state of charge (SOC)
  ui16_battery_volts = motor_get_ADC_battery_voltage_filtered () * ADC_BATTERY_VOLTAGE_K;
  if (ui16_battery_volts > BATTERY_PACK_VOLTS_100) { ui16_battery_soc = 16; } // 4 bars | full
  else if (ui16_battery_volts > BATTERY_PACK_VOLTS_80) { ui16_battery_soc = 12; } // 3 bars
  else if (ui16_battery_volts > BATTERY_PACK_VOLTS_40) { ui16_battery_soc = 8; } // 2 bars
  else if (ui16_battery_volts > BATTERY_PACK_VOLTS_20) { ui16_battery_soc = 4; } // 1 bar
  else { ui16_battery_soc = 3; } // empty

geofft said:
I'm feeling slightly lonely as the only tester at the moment, it would be good to get other opinions on this. Hopefully soon Honya and others will get up and running and let you know what they think.
Please enjoy your EBike and don't take to much time on this project. While it is great to have feedback and being improving it, don't stress about it and enjoy riding your EBike :)
 
My testing setup

https://drive.google.com/folderview?id=1xJ8EBBdFFrLKupt76oNr5TjS7uMtDoD3

Controllers photo: the fully working but oldest 6fet which I will test today is in the middle. Those two others have broken mosfet driver.

Motor is some similar to q100

After running it on table I will try all same components just with 10s3p 18650 battery on an old bike. If it will run and I feel confident that its usable, I want to try 18fet on the first photo bike.
 
honya96 said:
After running it on table I will try all same components just with 10s3p 18650 battery on an old bike. If it will run and I feel confident that its usable, I want to try 18fet on the first photo bike.
The first photo ebike, is a big one :) :) -- I would be really happy to know that you run it with our firmware on the "big" modded controller!!

That is a direct drive motor?? -- I think I am the only running our firmware with a direct drive motor... I am using the BMSBattery Q11 motor. And I am improving the code for Regen ebrake like coast brakes, that only works on direct drive motors...: https://opensourceebikefirmware.bitbucket.io/development/Various--2017.12.01_-_Regen_ebrake_like_coast_brakes.html

For your experience, what would be the max regen current on that Ebike??
 
Hallomotor 1000w, should be very similar build as yours but I can fit bigger phase wires to this one. My friend is running 36v 500w (slower) version with 21S battery and 60Amps :twisted:

I got no idea about the regen current. I can measure how much the stock firmware gives if you want but its strong only at high speed. Under 20km/h unusable. I will use 40A regen current if the firmware/ winding will deliver :lol: (on this setup) thats still safe for my battery for short periods. But I need variable by hall sensor.

Now to the results of todays testing.

Motor is running. :wink:
But, PAS not working now while flashing assist.
Wattage is still 20% off for me. (No big deal)
No load current 0.8A at 35v (looks ok, will finetune anyway)
Standby 180mA
The biggest problems I saw allready on table is the pwm rampup and down set to 25 and also if set to 2 takes like 5 seconds atleast to get to full speed or down to zero. (It should stop giving the motor current right after releasing throttle) but on the other side, when lvc cuts in the motor stops way too fast (it stops it by power)

Will try to get more time to look at it tomorow so those are just first impressions

And a question, 6fet has 1 shunt and 12fet has 2 of them, I wonder, isnt there a need to change something in firmware so they both measure correctly? (I want to use 4 of them in 18fet)
 
casainho said:
I think I am the only running our firmware with a direct drive motor...

I've tested it with BionX direct drive successfully, too.


@honya96:Great, that the firmware works with this old PCB-layout, too!

honya96 said:
I will use 40A regen current if the firmware/ winding will deliver :lol: (on this setup) thats still safe for my battery for short periods. But I need variable by hall sensor.
So we have to copy the code from the torque-simulation fork and use the X4 pad for the analogue brake signal

honya96 said:
The biggest problems I saw allready on table is the pwm rampup and down set to 25 and also if set to 2 takes like 5 seconds atleast to get to full speed or down to zero.
That's only a problem on the table. The current is controlled to be zero if you release the throttle. If there is no load, the current is near zero and the control loop reduces the duty cycle very slowly due to small delta between target and actual value. The ramp parameters can't help a this point.

regards
stancecoke
 
honya96 said:
The biggest problems I saw allready on table is the pwm rampup and down set to 25 and also if set to 2 takes like 5 seconds atleast to get to full speed or down to zero.
That's only a problem on the table.

Yes, this works better out on the road. Was going to mention pas ramp up though, I've got the ramp value set to just 5 at the moment and it's still too slow to build up, this may eventually need some adjustment in the code.

Will give you more info on the other stuff (battery ind, wattmeter) later.
 
geofft said:
Yes, this works better out on the road. Was going to mention pas ramp up though, I've got the ramp value set to just 5 at the moment and it's still too slow to build up, this may eventually need some adjustment in the code.
Please be more detailed in on your explanations. You mention ramp up and PAS and some value of 5, it doesn't make sense. You need to say which values for which option variable.
If we don't understand, we can't help.
 
Please be more detailed in on your explanations. You mention ramp up and PAS and some value of 5, it doesn't make sense. You need to say which values for which option variable.
If we don't understand, we can't help.

Sorry.....! :cry:

Was referring to the 'PWM duty cycle ramp up step' as in the configurators and config.h.
 
stancecoke said:
honya96 said:
The biggest problems I saw allready on table is the pwm rampup and down set to 25 and also if set to 2 takes like 5 seconds atleast to get to full speed or down to zero.
That's only a problem on the table. The current is controlled to be zero if you release the throttle. If there is no load, the current is near zero and the control loop reduces the duty cycle very slowly due to small delta between target and actual value. The ramp parameters can't help a this point.
Stancecoke, I remember you told about let the current controller do it's job.

I am now facing this thing, with my direct drive motor. Here is the code when when I apply regular brakes:
Code:
// Brake signal
void EXTI_PORTA_IRQHandler(void) __interrupt(EXTI_PORTA_IRQHANDLER)
{
  if (brake_is_set())
  {
    motor_controller_set_state (MOTOR_CONTROLLER_STATE_BRAKE); // enable brake state
    motor_set_regen_current_max (ADC_MOTOR_REGEN_CURRENT_MAX); // enable the strongest possible ebrake/regen
    motor_set_pwm_duty_cycle_target (0); // target 0 PWM duty_cycle and the motor will stop/block
    ebike_app_cruise_control_stop ();
  }
  else
  {
    motor_controller_reset_state (MOTOR_CONTROLLER_STATE_BRAKE); // disable brake state, this will make throttle to setup the new value for target PWM duty_cycle
    motor_set_regen_current_max (0); // disable ebrake/regen
  }
}
So, when applying brakes on geared motor motor, the motor should stop fast while the bicycle wheel will rotate freely because of the clutch inside the geared motor. When releasing brakes, the throttle will accelerate the motor and will engage on the bicycle wheel (at his current speed) thanks to the clutch.

On a direct drive motor, the motor will brake and reduce is speed at a rate depending on the max regen current and also the speed and mass of the bicycle + rider.
NOTE: On the Regen ebrake like coast brakes, the regen current is increased/decreased depending on the pedals backwards movement and that way the rider can control the rate of reduce speed / brake.
When releasing brakes, the throttle will accelerate again the motor (will increase target PWM duty_cycle).

The throttle and brakes control the target PWM duty_cycle and the real PWM duty_cycle, is then controlled by the motor current and motor regen current controllers. When we put target PWM duty_cycle = 0, we are braking the motor and it will brake faster with an higher regen current. When we put target PWM duty_cycle = 255, we are accelerating the motor and it will accelerate faster with an higher defined motor current.

What about when we have defined 0 regen current + max motor current on a direct drive motor? From my experience, the controllers will try to keep the motor PWM duty_cycle constant, if I am currently at 20km/h on a flat land and stop pedaling (throttle = 0 --> target PWM duty_cycle = 0), the motor will not brake nor accelerate and I can feel the motor pushing, which is very strange...
What about if instead of flat, I start on a slight descent? -- the bicycle will even accelerate fast, because motor will push it forward... really unpleasant experience (the PWM duty_cycle keeps constant but now the bicycle would need an lower value to keep his speed).
-- what to do here??
I think we need to define regen current to some low value and not 0, so every time I stop pedal, the motor will brake slowly (reduce his PWM duty_cycle) and I will not feel the motor keep pushing and instead I will need to keep pedaling. A to strong regen current and should also feel strange... I think I experienced this with the original firmware.

What do you guys think?? I think we can try keep the same firmware for both direct drive and geared motors, but the result is clear different.
 
geofft said:
Please be more detailed in on your explanations. You mention ramp up and PAS and some value of 5, it doesn't make sense. You need to say which values for which option variable.
If we don't understand, we can't help.
Was referring to the 'PWM duty cycle ramp up step' as in the configurators and config.h.
WARNING to everyone: a too low value of PWM duty cycle ramp up/down step will make the "FOC algorithm" fail and probably make short circuit on the controller!! Please start with a high value like 250 and reduce slowly.
With a battery pack of 24V and low amperage, this value can be lower than for instance with a 48V battery pack, because each change on PWM duty_cycle step represents higher energy step change to the motor and so will accelerate faster than what the "FOC algorithm" can do. In resume: this controller can only do moderate fast accelerations/decelerations because of "FOC algorithm".

I will write this on the firmware configuration tool help, for the corresponding field.
 
Casainho: I seem to have got the problem back with flashing empty battery signal and no motor functions (LVC triggered..?)
You fixed this a couple of days ago, could it have sneaked back into the github download?
 
geofft said:
Casainho: I seem to have got the problem back with flashing empty battery signal and no motor functions (LVC triggered..?)
You fixed this a couple of days ago, could it have sneaked back into the github download?
Yes, I see the changes on the log: https://github.com/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/commits/master

You can click on each commit title (like: "Bug correction for ADC battery med value"), then on next window click on Browse files and you can then download the zip file for that specific commit / point in time. Here the link for the version that seems to work for you:

https://github.com/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/tree/81d5fdbd37f2ab8d50b66d3719872a8b50e8ff2e

On the after commit with log "Small improvement on battery ADC values", I changed again but shouldn't make it fail. On the afterward commits, I didn't touch the ADC battery values...
Would be great if you could test the commit that works and the one right after, to see if the changes I did is breaking the firmware. I am being using the firmware, it works for me...
 
casainho said:
Stancecoke, I remember you told about let the current controller do it's job.

That's right :), but I can't follow your code and your further argumentation.
You are mixing current target and dutycycle target?! That can't be good.
BTW, your control loop isn't a classical PI-control...

69072d4013ea8f14ab59a8283ef216fb958870b2


You can take a look at the code in the update_setpoint.c of the torque-simulation fork. There the integral part of the dutycycle value is calculated from a floatingpoint variable and the dutycyle is controlled to one central current-target-value. For riding and for regen, always the same algorithm is used for calculating the duty cycle, except undervoltage shut down. Sorry for using german expressions as variable names: "soll" = target value, "ist" = actual value. Perhaps the name ui32setpoint is a little confusing, also. This is the dutycycle, not the current target.
The "ramp up" and "ramp down" values are hardcoded to the value "3" but please note, this is the maximum step per (slow-) loop run, not the delay-factor as in your code.
The setpoint_old variable is not used, I have to delete it from the code some day ;)

Code:
uint32_t PI_control (uint16_t ist, uint16_t soll)
{
  float float_p;
  static float float_i;
  float_p=((float)soll - (float)ist)*P_FACTOR;
  if (float_p>3)float_p=3;
  if (float_p<-3)float_p=-3;
  float_i+=((float)soll - (float)ist)*I_FACTOR;
  if (float_i>255)float_i=255;
  if (float_i<0)float_i=0;
  return ((uint32_t)(float_p+float_i));
}

regards
stancecoke
 
geofft said:
Casainho: I seem to have got the problem back with flashing empty battery signal and no motor functions (LVC triggered..?)
You fixed this a couple of days ago, could it have sneaked back into the github download?

Casainho, forget this, looks like my laptop software installation has got corrupted, I've cocked-up somewhere.
No more time now, will re-install it later, sorry to bother you.
 
honya96 said:
And a question, 6fet has 1 shunt and 12fet has 2 of them, I wonder, isnt there a need to change something in firmware so they both measure correctly? (I want to use 4 of them in 18fet)
There isn't yet. On my S06S, I did measured each 8 bits ADC step (20mV) to be equal to 0.5A: 5V / 256 = 0.02V.
My S12S had 2 shunts but I cut one, so I can't now measure the real value for S12S.

Please measure for your controller and say the value, then I can put on the firmware as an option.
 
I am not really happy with riding experience with my direct drive motor.
The torque sensor outputs a value that is a peak signal every pedals rotation and I feel that peak on the motor, if I control directly the motor duty_cycle. Ideally, the torque signal would be stable continuous over a pedals rotaion and I think that would be veey good for the motor....

I need to think more about this...

honya96 said:
I got no idea about the regen current. I can measure how much the stock firmware gives if you want but its strong only at high speed. Under 20km/h unusable.
The electric unicycles I did ride, had motors similar to Q11 and the same PWM control scheme our firmware uses, and they do break almost at to spto point -- it must, other Segways, hoverboards and electric unicycles could not exist.
 
casainho said:
honya96 said:
I got no idea about the regen current. I can measure how much the stock firmware gives if you want but its strong only at high speed. Under 20km/h unusable.
The electric unicycles I did ride, had motors similar to Q11 and the same PWM control scheme our firmware uses, and they do break almost at to spto point -- it must, other Segways, hoverboards and electric unicycles could not exist.

You might want to read this reply by AmberWolf to my question about regen.

In particular, I think this para may be relevant to you:
--complex and more common way is the controller repeatedly "shorts" the motor windings to create pulses of much higher voltage to be able to cause current flow even at motor speeds which would not otherwise be able to do it, so it can brake down to much lower speeds. Some are better at this than others, and some are more efficient at it (the less efficient ones make the motor and controller hotter from the waste heat than the more efficient ones).

On my KT S12SN controller, there is an option, C13, that is described in the manual as:
Code:
 C13 ABS brakes of the controller and parameters of anti-charge control 

C13 parameter definition table: 
C13 Value      ABS braking strength           Energy recovery efficiency 
       0           None                                   None 
       1           Class 1 braking strength       Best energy recovery efficiency   
       2           Class 2 braking strength       General energy recovery efficiency 
       3           Class 3 braking strength       Weaker energy recovery efficiency 
       4           Class 4 braking strength       Poor energy recovery efficiency   
       5           Class 5 braking strength       Bad energy recovery efficiency 
       
The recommended value of C13 is 1; other values need to be chosen with caution for 
use.   
Be  sure  to  note:  the  higher  is  the  braking  intensity  level,  and  the  braking  strength 
will be greater, the greater damage to the motor shaft accordingly.

Until I read AmberWolf's para above the weaker braking == better energy recovery & Stronger breaking == least energy recovery didn't make sense to me; now it seems clear that this controller can be configured to either feed whatever is generated by the motor on overrun back to the battery (C13=1) or actively feed reverse polarity power to the windings to slow the motor down (C13=5); or (somehow) a mixture of the two (C13=2..4).

Note:I have no real knowledge of this, I'm just passing along some info that seems it might be relevant to what you are doing, that you might otherwise miss.

I'm going to buy a wattmeter(or perhaps 2), and if I can work out how to put one in circuit with one of the phase windings, I will try to work out what the standard firmware does with that settings value.
 
Back
Top