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

[honya96]

I know all these things.. takes no power. power resistors at 72v controller are around 300Ohm but I was not trying 72v controller... now Iam..( 12fet) but its all modified to 48v and also lcd3 is 48v now so Its all like your setup?.. and it fails at "write option bytes" now.

first one I tried still acts like no firmware in it basicaly.

[casainho]

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.

[casainho]

and it fails at "write option bytes" now.

On the log we can see the optionbytes.hex is not found, maybe the path to the file on the scrip is wrong, I think Stancecoke is the one that can help you here.

[casainho]

and it fails at "write option bytes" now.

On the log we can see the optionbytes.hex is not found, maybe the path to the file on the scrip is wrong, I think Stancecoke is the one that can help you here.

Comparing with the script file for building, seems that script for write option bytes misses the line:

Code: Select all

cd firmware

Makes sense, without that, optionbytes.hex file is not found.

[honya96]

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"

[honya96]

"write option bytes" succesfull with "old" tool bat file

[honya96]

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

[honya96]

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 but you can give suggestions anyway. Thanks a lot

[casainho]

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 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

[honya96]

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

[geofft]

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.... 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.

[casainho]

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.

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:

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: Select all

#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: Select all

#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

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

[honya96]

My testing setup

https://drive.google.com/folderview?id= ... jS7uMtDoD3

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.

[casainho]

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.bitbuck ... rakes.html

For your experience, what would be the max regen current on that Ebike??

[honya96]

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

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 (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.
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)

[honya96]

BTW this is "the big one" ..waiting for some controller

[stancecoke]

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!

I will use 40A regen current if the firmware/ winding will deliver (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

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

[geofft]

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.

[casainho]

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.

[geofft]

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.....!

Was referring to the 'PWM duty cycle ramp up step' as in the configurators and config.h.

[casainho]

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: Select all

// 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.

[casainho]

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.

[geofft]

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]

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-fir ... its/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-fir ... 8b50e8ff2e

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...

[stancecoke]

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...



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: Select all

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