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

[geofft]

The settings in the config.h seem to be OK, now.

regards
stancecoke

Ok, thanks. The main issues I had with the current Master branch (throttle/pas mode, tested on training stand only) were:-

1) Controller powers up ok but once forward pas is triggered the motor runs on strongly after stopping pedalling and can only be stopped by switching off the controller. Even with the brake input triggered the motor still continues to run at a reduced level, returning to higher level when brake released.

2) Throttle seems to operate ok but when released the motor takes several seconds to decay to a stop.

3) When reverse pedalling after power up the motor gives one short (but strong) forward pulse, lasting about a second. This happens just once, further reverse pedalling after this doesn't cause this problem. This didn't happen previously with the updated pas detection.

...if there's any other tests you want done just let me know.. :wink:

 

[casainho]

...if there's any other tests you want done just let me know.. :wink:

I hope you are also testing the battery SOC.
And give a look at the power LCD measurements, see if is more stable and the delay.
For both power LCD and battery voltage SOC filter, you can now adjust the filter coefficients in main.h.

 

[geofft]

I hope you are also testing the battery SOC.

I'm waiting to completely discharge the battery so I can check this through a complete charge cycle.

And give a look at the power LCD measurements, see if is more stable and the delay.
For both power LCD and battery voltage SOC filter, you can now adjust the filter coefficients in main.h.

Wattmeter now looks much more stable, haven't as yet played with filter coefficients but will give this a try.

 

[stancecoke]

It seems, that the timeout of PAS is only active if regen mode ist enabled.

// limit min PAS cadence
    if (ui16_pas1_counter > ((uint16_t) PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS))
    {
      ui16_pas1_pwm_cycles_ticks = (uint16_t) PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS;
      ui16_pas1_counter = 0;
      ui16_pas1_on_time_counter = 0;
      ui16_pas1_off_time_counter = 0;
      ui8_pas1_direction = 1;
      PAS_act=3;

Maybe this was a bug at my branch already?!

regards
stancecoke

 

[casainho]

It seems, that the timeout of PAS is only active if regen mode ist enabled.

Maybe this was a bug at my branch already?!

When did the merge, the code didn't built for some reason and I had to add an extra "}". Would be great if you could solve the issue and test.

 

[geofft]

Just a small update on a couple of things:-

2) Throttle seems to operate ok but when released the motor takes several seconds to decay to a stop

I notice that there are now adjustments for this in main.h, which will probably resolve this. TBH the throttle decay is difficult to assess on the training roller, best ignore this until pas is ok and I can try it on the road.

Wattmeter damping as stated is working well, I find filter coefficients of 2 or 3 (main.h) suit my preference, it's nice that we can now adjust this. Wattmeter calibration is reading rather low, with an ammeter in battery supply the wattmeter shows around 2/3 (67%) of the 'correct' value. Is there still a user 'tweak' available so we can play with this?

 

[stancecoke]

Would be great if you could solve the issue and test.

I've just commited the bugfix at github, but not tested it in hardware. Perhaps geofft can try it

regards
stancecoke

 

[casainho]

Just a small update on a couple of things:-

2) Throttle seems to operate ok but when released the motor takes several seconds to decay to a stop

I notice that there are now adjustments for this in main.h, which will probably resolve this. TBH the throttle decay is difficult to assess on the training roller, best ignore this until pas is ok and I can try it on the road.

For throttle filter you have also on main.h: THROTTLE_FILTER_COEFFICIENT

Wattmeter calibration is reading rather low, with an ammeter in battery supply the wattmeter shows around 2/3 (67%) of the 'correct' value. Is there still a user 'tweak' available so we can play with this?

There isn't yet a coefficient for amp meter as it is not supposed that we need it, as hardware is stable.

Can you follow the same process I did? measure with wheel blocked?? -- would be great even if you could share a video:
[youtube]if195JSfAVI[/youtube]

 

[geofft]

Would be great if you could solve the issue and test.

I've just commited the bugfix at github, but not tested it in hardware. Perhaps geofft can try it

regards
stancecoke

Yup, pas now looks to be working fine on the training roller. Nice work guys.. :wink:
Will try it on the road shortly and let you know the outcome.

 

[geofft]

Will try it on the road shortly and let you know the outcome.

....all working really nicely now, certainly the best of your efforts so far.

Throttle decay seems ok on the road, if I was being really fussy I would say the pas decay is a little slow, takes around 2 secs to quit after stopping pedalling, just a bit too long. Other than that, pretty much faultless...

I was doing this test with an almost totally depleted battery, probably need to retest when fully charged but hopefully no new issues will show up.

@casainho - My battery is now pretty much fully drained, will hopefully play with SOC indicator and other stuff over the weekend.

 

[stancecoke]

Some interesting findings concerning regen:
You can find a motor specific function that calculates the necessary duty-cycle to keep the battery current zero when the motor is spinning free from the erps. You can call it some kind of Kv with an offset.
This function can be found by measuring some points at different speeds. I did it for three points and the function seems to be linear in the range i looked at.

As long as the duty cycle doesn't drop under the half of the dutycycle that's corresponding to zero amps at the recent erps, the simplified FOC is stable and regen current is at it's optimum for the speed.
If DC goes under this threshold, the FOC doesn't work any more and the advane angle runs to nirvana.

So, we can just make sure, that the DC never drops under the limit at regen....

if(ui8_regen_throttle>2){

    if (ui16_motor_speed_erps*2/3>14){ // avoid negative results of the substraction

	 float_temp=(float)ui8_regen_throttle*(float)(REGEN_CURRENT_MAX_VALUE-ui16_current_cal_b)/255.0+(float)ui16_current_cal_b;

	 ui32_setpoint= PI_control(ui16_BatteryCurrent, (uint16_t) float_temp);

	 if (ui32_setpoint<(ui16_motor_speed_erps*2/3-14)/2)ui32_setpoint=(ui16_motor_speed_erps*2/3-14)/2;
  }
    else ui32_setpoint= PI_control(ui16_BatteryCurrent, ui16_current_cal_b); //if erps are too low, control current to zero
    if (ui32_setpoint<5)ui32_setpoint=0;
    if (ui32_setpoint>255)ui32_setpoint=255;
  }

The function is hardcoded for my Sanyo Dynamotor on the testbench at the moment, of course we have to make it user-setable or even self-learning.
This finding is completly empiric, I have no physical explanation for it.

regards
stancecoke

 

[lqbweb]

Ey, this is a great job. I will try it out on my second controller

Perhaps someone here can help me on something related.

I am trying to swap the lm317t regulator with a custom made switch regulator board. But I am failing to understand the schematic that you guys are point to at:

https://github.com/KingQueenWong/bmsbattery_s06s_controller_hardware/blob/master/S06S-Controller.PDF

Why is the input of the lm317t connected to the output? how can that make any sense? the same with the 7805 regulator.

I have opened an issue at the repo of KingQueenWong, but I am not sure if he has time or if he is following it up:

https://github.com/KingQueenWong/bmsbattery_s06s_controller_hardware/issues/3

Does someone here understand that?

I have checked the design myself several times and seems to match with what KingQueenWong did.

 

[casainho]

That is a power resistor that's get hot while controller is running.
The power dissipated on resistor would otherwise need to be dissipated on that linear regulator... I guess that power resistors are kuch cheaper that an expensive regulator to handle that big voltage input...

 

[lqbweb]

yes, I understand it is meant to be a resistor divider to drop the voltage, as the max voltage of the lm317 is already 40volts, but why is it going that net to the output, and not to ground. I still dont understand how can that possible work (it clearly does ehehe).

I will post the schematics of my switch board once it is fully working

Thanks

 

[casainho]

yes, I understand it is meant to be a resistor divider to drop the voltage, as the max voltage of the lm317 is already 40volts, but why is it going that net to the output, and not to ground. I still dont understand how can that possible work (it clearly does ehehe).

I will post the schematics of my switch board once it is fully working

It is not a voltage divider, it is just a resistor were a voltage drop happens due to the current that passes over it. If you measure the average voltage at his terminals, you will calculate how much current passes over it.

 

[geofft]

I am trying to swap the lm317t regulator with a custom made switch regulator board.

Not sure if you're aware of these:-
https://www.ebay.co.uk/itm/DC-DC-St...entrq:0bce0f7d1630abc5a68e90d8fff783c1|iid:1

It's basically a buck converter to provide the (adjustable) 12v line with (I think) a 7805 linear regulator added to provide 5v. Very small dimensions, should fit inside the S06S case once the redundant on-board smoothing caps are removed. I've got a couple on the way, I'll post something up when I get round to trying one.

(Thanks to honya96 for originally finding these converters)

 

[lqbweb]

ok, here is my question solved:

https://electronics.stackexchange.com/questions/371143/lm317-input-connected-to-output/371158#371158

thanks anyway.

those cheap dc switch regulator are a bit too big (specially if like me, you have switch the capacitors to bigger ones). Also the switching frequency is pretty low. My board I designed it with an mp4560.

I will keep you updated with pics maybe tomorrow.

 

[geofft]

...if there's any other tests you want done just let me know.. :wink:

I hope you are also testing the battery SOC.
And give a look at the power LCD measurements, see if is more stable and the delay.
For both power LCD and battery voltage SOC filter, you can now adjust the filter coefficients in main.h.

Did a cell voltage vs lcd3 battery bars check today during a battery charge cycle, results below. This table shows the actual cell voltages at the change point of the lcd3 battery bars:-

...lcd3 bars.................Cell voltage
3 bars <--> 4 bars............4.08 (4.02)
2 bars <--> 3 bars............3.93 (3.87)
1 bar <--> 2 bars.............3.85 (3.80)
0 bars <--> 1 bar..............3.79 (3.73)
Flashing <--> 0 bars..........3.75 (3.69)


...numbers in brackets are 'expected' change point voltages from lookup table (main.h). Seems the actual result doesn't agree with what you would expect from the figures in the lookup table (which look 'correct'). This gives a noticeable error in the lcd3 battery bars - not sure what's happening here.

Did a road test with the fully charged battery which threw up a couple of issues with throttle operation:-

1) Full throttle is only giving about 50% power from the motor. Noticed this previously but thought maybe due to almost flat battery - this seems not to be the case.

2) If throttle gently operated at standstill bike pushes forward as expected, when throttle released bike stops but motor 'growls' as if small amount of drive remains, then often gives an '06' error after a few seconds.

PAS works well and seems to give much stronger acceleration from a standstill than previous fw versions. Wattmeter nice and stable, haven't rechecked calibration as yet, will do so next week.

 

[honya96]

seems to give much stronger acceleration from a standstill than previous fw versions.

Maybe the new phase current limiting thats a good sign for me.

I had problem 1) and 2) also...

 

[honya96]

For problem 2) I would suggest a check box if using direct or gear motor and then for gear motor it can be set that motor "never" spins (regen slightly to a stop) without throttle input. This way no one gets this problem with gear motor (most people)

For direct motor its harder to do coast with zero current for sure.. :?

 

[casainho]

I did a refactor/update to motor code FOC angle. Now the angle values have as reference phase B BEMF max value, were rotor position has 90 degrees. Phase B as reference because we will use signal from phase B current sensor to implement the very low resolution FOC algorithm.

I hope this will help me (and other to read and better understand the motor code) to understand and improve the FOC while on regen mode.

Current defines about the motor now are only this:

// *************************************************************************** //
// MOTOR

// Choose some parameters for your motor (if you don't know, just keep the following original values because they should work ok)
//
// This value should be near 0. When measured with an oscilloscope, for a Q85 motor, the offset is -5 which probably will
// not make  any big difference im terms of efficiency
#define MOTOR_ROTOR_OFFSET_ANGLE 0

// This value is ERPS speed after which a transition happens from sinewave no interpolation to have
// interpolation 60 degrees and must be found experimentally but a value of 30 may be good
#define MOTOR_ROTOR_ERPS_START_INTERPOLATION_60_DEGREES 30

 

[casainho]

...if there's any other tests you want done just let me know.. :wink:

I hope you are also testing the battery SOC.
And give a look at the power LCD measurements, see if is more stable and the delay.
For both power LCD and battery voltage SOC filter, you can now adjust the filter coefficients in main.h.

Did a cell voltage vs lcd3 battery bars check today during a battery charge cycle, results below. This table shows the actual cell voltages at the change point of the lcd3 battery bars:-

...lcd3 bars.................Cell voltage
3 bars <--> 4 bars............4.08 (4.02)
2 bars <--> 3 bars............3.93 (3.87)
1 bar <--> 2 bars.............3.85 (3.80)
0 bars <--> 1 bar..............3.79 (3.73)
Flashing <--> 0 bars..........3.75 (3.69)

...numbers in brackets are 'expected' change point voltages from lookup table (main.h). Seems the actual result doesn't agree with what you would expect from the figures in the lookup table (which look 'correct'). This gives a noticeable error in the lcd3 battery bars - not sure what's happening here.

So, for what I understand, the difference from the values you measured to the ones defined on the firmware, has only a difference of 0.06V which seems a very good to me!! I don't think hardware can do much better and even how do we know that your multimeter is not measuring with an error??

I think the firmware is working good. The only thing I am not happy with are the values on the table because I think are to high and so I will need to change them from main.h to config.h, so anyone can adapt for their own needs.

Did a road test with the fully charged battery which threw up a couple of issues with throttle operation:-

1) Full throttle is only giving about 50% power from the motor. Noticed this previously but thought maybe due to almost flat battery - this seems not to be the case.

2) If throttle gently operated at standstill bike pushes forward as expected, when throttle released bike stops but motor 'growls' as if small amount of drive remains, then often gives an '06' error after a few seconds.

1. Please update the firmware from master branch. ONLY choose config.h values taking as reference config-example.h, do not use the firmware configuration tool (at least until we update it).

For instance, assist level should now be higher than 1, something like 2 at least to have max throttle value:

#define ASSIST_LEVEL_0 0.0
#define ASSIST_LEVEL_1 0.25
#define ASSIST_LEVEL_2 0.5
#define ASSIST_LEVEL_3 1.0
#define ASSIST_LEVEL_4 2.0
#define ASSIST_LEVEL_5 4.0

2. May be because of the throttle THROTTLE_FILTER_COEFFICIENT, if is to high will give a delay... please tell which value are you using to THROTTLE_FILTER_COEFFICIENT.

 

[geofft]

So, for what I understand, the difference from the values you measured to the ones defined on the firmware, has only a difference of 0.06V which seems a very good to me!! I don't think hardware can do much better and even how do we know that your multimeter is not measuring with an error??

I think the firmware is working good. The only thing I am not happy with are the values on the table because I think are to high and so I will need to change them from main.h to config.h, so anyone can adapt for their own needs.

Yes, a user defined correction factor for this would be a great addition. I guess this is what the stock fw achieves with the P5 setting.

Will feedback on the other requests later today or tomorrow.

 

[geofft]

For problem 2) I would suggest a check box if using direct or gear motor and then for gear motor it can be set that motor "never" spins (regen slightly to a stop) without throttle input. This way no one gets this problem with gear motor (most people)

Sounds good to me - I think being able to disable regen functions (for gearmotors) would be a good option...

 

[stancecoke]

I did a refactor/update to motor code FOC angle.

Hm, it's good to have the formerly confusing angle definitons in a logical range now. But when I look at the FOC algorithm, it's the same as before, except looking at the rising vs. the falling edge?!

regards
stancecoke