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

[casainho]

Had a bit of a disaster with my controller tonight (Master branch, throttle/pas mode). Just recently upgraded to CSD19506 mosfets and it's been running fine until I tried it tonight for the first time with a fully charged battery. Had immediate problems on power up in that the battery bars would climb 1-2-3-4 as normal, but then would immediately reset to zero bars and cycle 1-2-3-4 again and then repeat this ad infinitum. Whilst this cycling was happening the lcd3 brake indicator was activated and there was no response to throttle or pas input.

After a few power up attempts this seemed to stop happening and it powered up as normal but with the motor growling at standstill and sometimes jerking forward at power up. Then suddenly the battery trip switch popped out and a quick meter check showed I had shorted green phase mosfets.

I'm hoping this was just a bad mosfet in the process of breaking down, if so this is disappointing for supposedly high quality TI components from a good supplier.

I'm about to order some replacement CSD19506's, in the meantime I'd just thought I'd run this in front of you guys in case you think this may be a bug in the firmware, or anything else you think I ought to check.... :wink:

That battery bars cycling is normal and is a protection for when you power up the system and battery is over charged. This protection is needed other way the wheel would start running without you pushing the throttle and this would be dangerous!! This is protection is needed because of regen (direct drive motors). The firmware send to LCD the signal of battery charging and brake signal.

About the mosfets, well, it should be an hardware issue since my master branch works ok as you know.
If you want to discover/learn more, you can change the PWM dead time parameter on the firmware - since you changed the mosfets, who knows if that should be adapted for an higher value?? Or also try to enable and disable each mosfet high and low sides, up to found where is the short circuit.
Remember to keep brakes pressed at startup to avoid the short circuit and so being able to program or test.

 

[honya96]

Hmm, strange. Which fork did you use? What max current did you choose? Can you post your config.h?

I never tried more than 6amps yet.

regards
stancecoke

I'm using the current casainho fork of the master branch.

You may be on the right track with max current, I've just remembered I did play around with these numbers. I may have put something stupid in for these, at the time I couldn't remember what the division factor was and was too lazy to look it up - I reckon that may have come back to bite me...

Config.h attached.

Just by the way, I tried master with 14s battery over 100A and 200 phase amp (real world values, not the set ones..)

I am trying to change mosfets for long time but never run them for long, I think now, that it needs a HW mod.

Some gate resistor..

Maybe best to check with osciloscope, stock vs custom FET.

 

[casainho]

Hmm, strange. Which fork did you use? What max current did you choose? Can you post your config.h?

I never tried more than 6amps yet.

regards
stancecoke

I'm using the current casainho fork of the master branch.

You may be on the right track with max current, I've just remembered I did play around with these numbers. I may have put something stupid in for these, at the time I couldn't remember what the division factor was and was too lazy to look it up - I reckon that may have come back to bite me...

Config.h attached.

Just by the way, I tried master with 14s battery over 100A and 200 phase amp (real world values, not the set ones..)

I am trying to change mosfets for long time but never run them for long, I think now, that it needs a HW mod.

Some gate resistor..

Maybe best to check with osciloscope, stock vs custom FET.

I would be very happy to see someone modding this controllers for 100A and share some notes on how to do it.

 

[-dg]

One of my finest virtues is a lot of patience
Would you know how reasonable it is to port the codebase to STM32? Are there any specific unusual features the STM32 version will have to support? Otherwise I studied a lot of controller designs, and I would keep many functions modular (such as using LM2596HVS or XL7005A step downs instead of discreet components). Possibly there are already open source boards such as for Lebowsky (hopefully in KiCAD) that could be simply adapted, layout and routing is a small issue in comparison with the part library capture an packages. I will do some research...
Meanwhile I have a small 350W KT controller on order, so I can familiarize myself with the firmware and the code ideally too, so keep up the good work!

I just bought a few of these controllers and some stm8s and stm32s "blue pill" boards as well as a couple of the official stm discovery and nucleo dev boards. Oh, and a Rigol O-scope. My intent is to help with the firmware. A few observations:

1. The current STM8 part is the bare minimum to do the job, it is limited by memory, speed, 8-bit-ness and lack of floating point. If it had those things then a full FOC controller would be practical (it would also need another current sensor). But it doesn't, so the firmwares do "psuedo FOC" meaning as far as I can tell play back a preset waveform but shift its phase relative to the rotor position in response to the current sensed on one phase. This avoids the math required to do real FOC but is probably less accurate.

2. The current part is STM8S105CT6 which is 16Mhz, 32Kb flash, 2Kb ram in a LQFP48 package. As I understand it, the current firmware barely fits in both flash and ram and is barely fast enough. Replacing the 8S105CT6 with STM8S207C8 (or STM8S207CB) would make it a lot easier as they have 24Mhz, 64 (or 128)Kb flash and 6Kb ram. Too slow still to do real FOC, but would leave a lot of room for feature development. I think these are pretty compatible in both hardware (pinout, limits) and software to the current chip so only minimal adapation would be needed. One could start by replacing the chip in one of the existing controllers.

There is also STM8S208 which adds CAN support, but unfortunately is only 85C temp range unlike the existing 125C rated part. I suspect it gets pretty warm in a controller, which is why I'm suggesting the STM8S207.

3. STM32 is a big family of 32bit ARM cores with lots of peripherals. These are all much more capable and complex devices than the STM8. Unless compatibility with the existing controller is paramount, there is no reason not to use STM32. They even have parts with three timer/pwm units specifically for motor control. Take a look at STM32F303. 72Mhz, 32 bit, floats, 9 timers, FOC libraries, up to 256Kb flash, 80Kb ram. The Discovery board for this STM32F3DISCOVERY is about $16 and has a built in programmer. There are also a selection of Nucleo boards like NUCLEO-F303RE for around $10.

4. There is some compatibility moving from STM8 to STM32 as the basic peripherals are similar, but it's unlikely that a straightforward port of the existing firmware will be easy or optimal. There are however a few open source controllers based on STM32 as well as libraries and app notes from STM so plenty of places to take ideas and inspiration from.

 

[stancecoke]

there are some open source examples for driving a BLDC with FOC on a STM32, so you won't have to start from scratch. I would prefer if we could write an open firmware for the Lishui controllers, they use STM32 processors and offer sensorless sinusodial drive.

regards
stancecoke

 

[geofft]

casainho:
That battery bars cycling is normal and is a protection for when you power up the system and battery is over charged. This protection is needed other way the wheel would start running without you pushing the throttle and this would be dangerous!! This is protection is needed because of regen (direct drive motors). The firmware send to LCD the signal of battery charging and brake signal.

The battery was fully charged (50.0v 12s) but not overcharged, I guess I need to raise the limit a little. Can I do this using the upper LI_ION_CELL_VOLTS settings (config.h) or maybe somewhere else?
It would be good if gearmotor users could disable regen, it does seem to cause some problems.

About the mosfets, well, it should be an hardware issue since my master branch works ok as you know.
If you want to discover/learn more, you can change the PWM dead time parameter on the firmware - since you changed the mosfets, who knows if that should be adapted for an higher value?? Or also try to enable and disable each mosfet high and low sides, up to found where is the short circuit.
Remember to keep brakes pressed at startup to avoid the short circuit and so being able to program or test.

Ok, I'll increase the dead time a little just to be safe. Not sure if it's high side or low side mosfet as yet, will investigate later.
Thanks for your help.

 

[casainho]

casainho:
That battery bars cycling is normal and is a protection for when you power up the system and battery is over charged. This protection is needed other way the wheel would start running without you pushing the throttle and this would be dangerous!! This is protection is needed because of regen (direct drive motors). The firmware send to LCD the signal of battery charging and brake signal.

The battery was fully charged (50.0v 12s) but not overcharged, I guess I need to raise the limit a little. Can I do this using the upper LI_ION_CELL_VOLTS settings (config.h) or maybe somewhere else?

See that the motor controller hardware may be reading with some error offset.
You can change that value and it is on config.h:

#define LI_ION_CELL_VOLTS_MAX 	4.25

It would be good if gearmotor users could disable regen, it does seem to cause some problems.

It is not so easy to disable regen, as the code would need to be more complex and that needs more development and testing time.

About the mosfets, well, it should be an hardware issue since my master branch works ok as you know.
If you want to discover/learn more, you can change the PWM dead time parameter on the firmware - since you changed the mosfets, who knows if that should be adapted for an higher value?? Or also try to enable and disable each mosfet high and low sides, up to found where is the short circuit.
Remember to keep brakes pressed at startup to avoid the short circuit and so being able to program or test.

Ok, I'll increase the dead time a little just to be safe. Not sure if it's high side or low side mosfet as yet, will investigate later.
Thanks for your help.
[/quote]
Change dead time and enable/disable a specific PWM channel that enables the power mosfets:

Go to:

void pwm_init_bipolar_4q (void)

Dead time:

// break, dead time and lock configuration
  TIM1_BDTRConfig(TIM1_OSSISTATE_ENABLE,
		  TIM1_LOCKLEVEL_OFF,
		  // hardware nees a dead time of 1us
		  16, // DTG = 0; dead time in 62.5 ns steps; 1us/62.5ns = 16

PWM signal, on the same function, there are the configurations for TIM1_OC1Init, TIM1_OC2Init and TIM1_OC3Init (channels 1, 2 and 3 of PWM):

  TIM1_OC2Init(TIM1_OCMODE_PWM1,
	       TIM1_OUTPUTSTATE_ENABLE,
	       TIM1_OUTPUTNSTATE_ENABLE,

TIM1_OUTPUTSTATE_ENABLE: enable PWM positive channel
TIM1_OUTPUTSTATE_DISABLE: disable PWM positive channel

TIM1_OUTPUTNSTATE_ENABLE: enable PWM negative channel
TIM1_OUTPUTNSTATE_DISABLE: disable PWM negative channel

Before adjust dead time, I would first disable all the channels first and then enable one by one up to happen the short circuit.

 

[-dg]

there are some open source examples for driving a BLDC with FOC on a STM32, so you won't have to start from scratch. I would prefer if we could write an open firmware for the Lishui controllers, they use STM32 processors and offer sensorless sinusodial drive.

I agree, but the only one of those that seems readily available in the US is the one sold by BMSBattery and it is only 36 volts. Also, it is unclear to me at least if it can be programmed and of course we don't have the wealth of data we have for the KT controllers, ie BOM, schematics etc. So my thought was to work with the most active project, ie this one. It is a bit of a disappointment that casainho (who has done so much) is less interested now. I think the project was just starting to pick up some momentum.

If there was a project to work on the Lishui controllers I'd be interested, but as it is, I have a half dozen of the KT just waiting for me to practice on.

 

[stancecoke]

I think the project was just starting to pick up some momentum.

Sadly, we are just a handful of users worldwide. I think we could reach much more people if we would use a less exotic toolchain like STM32duino for the project. But you are right, we need an easy available and well documented hardware. I think the Lishui controllers are available on the US-market too, but they are branded with different names mostly, so it's not easy to identify it. It's the only low-price sensorless sinusodial wave controller that I know...

regards
stancecoke

 

[geofft]

geofft:
Not sure if it's high side or low side mosfet as yet, will investigate later.

...the damage is worse than I thought, both yellow phase mosfets shorted plus green phase low side.

Never had this trouble with the 'crappy' Chinese mosfets.....

 

[honya96]

Hmm, strange. Which fork did you use? What max current did you choose? Can you post your config.h?

I never tried more than 6amps yet.

regards
stancecoke

I'm using the current casainho fork of the master branch.

You may be on the right track with max current, I've just remembered I did play around with these numbers. I may have put something stupid in for these, at the time I couldn't remember what the division factor was and was too lazy to look it up - I reckon that may have come back to bite me...

Config.h attached.

Just by the way, I tried master with 14s battery over 100A and 200 phase amp (real world values, not the set ones..)

I am trying to change mosfets for long time but never run them for long, I think now, that it needs a HW mod.

Some gate resistor..

Maybe best to check with osciloscope, stock vs custom FET.

I would be very happy to see someone modding this controllers for 100A and share some notes on how to do it.

Nothing, it was with stock 18FET, but it will overheat soon. I mean wires, connectors, traces.. simple modding. FETs are harder... but 18FET has better than 6FET even stock.

 

[honya96]

geofft:
Not sure if it's high side or low side mosfet as yet, will investigate later.

...the damage is worse than I thought, both yellow phase mosfets shorted plus green phase low side.

Never had this trouble with the 'crappy' Chinese mosfets.....

I believe it's not fault of the Mosfet, it's the driver which keeps them open in short circuit.

I'd like to be able to get osciloscope and take a look what's happening there but it's not priority for me now.

Until then I have to go with stock mosfets.

 

[geofft]

geofft:
Not sure if it's high side or low side mosfet as yet, will investigate later.

...the damage is worse than I thought, both yellow phase mosfets shorted plus green phase low side.

Never had this trouble with the 'crappy' Chinese mosfets.....

I believe it's not fault of the Mosfet, it's the driver which keeps them open in short circuit.

I'd like to be able to get osciloscope and take a look what's happening there but it's not priority for me now.

Until then I have to go with stock mosfets.

Yes, I'm beginning to think you're correct, there's some issue using these 'better' mosfets in the Kunteng controllers and maybe some further hardware changes need to be made to keep mosfet operation inside safe parameters. Despite all the abuse the Chinese FET's received during my testing sessions I never had a single failure, but with the TI FET's I've experienced a fail quite quickly.

It's probably fair to assume that the TI FET's are much more durable when correctly operated, so something is wrong here. I'm guessing it just needs a small component change somewhere in the driver stage but unfortunately my electronics abilities aren't good enough to evaluate this. Also, with surface mount technology small component changes are not easy...

 

[honya96]

Yes, I'm beginning to think you're correct, there's some issue using these 'better' mosfets in the Kunteng controllers and maybe some further hardware changes need to be made to keep mosfet operation inside safe parameters. Despite all the abuse the Chinese FET's received during my testing sessions I never had a single failure, but with the TI FET's I've experienced a fail quite quickly.

It's probably fair to assume that the TI FET's are much more durable when correctly operated, so something is wrong here. I'm guessing it just needs a small component change somewhere in the driver stage but unfortunately my electronics abilities aren't good enough to evaluate this. Also, with surface mount technology small component changes are not easy...

Without HW change, it may be a good idea to start with much higher dead time and look at osciloscope how much you can decrease it to still be OK.

But if those FETs have much higher gate charge, I don't know if power, efficiency, etc will be OK with high dead time

 

[1N4001]

I don't think the dead time was the issue. Someone in this thread claimed that the 18FET KT controllers simply parallel 3 MOSFETs with the same gate driver, so that's a lot of gate capacity dealt with easily.

One way to be sure would be to grab CSD19505 instead of CSD19506. They have worse RDS(on) but the same gate capacity as the original STP80NF70.

 

[geofft]

I had a play with my second test controller today, this also has the CSD19605 fets but seemed to work normally with the fully charged battery, no motor growling or other strange behaviour.

I experimented a little with the deadtime settings, default is 1 microsec, I stretched this right out to 6 microsecs (using casainho's instructions) but couldn't detect any real difference, it seemed to run just the same with the mosfets still getting a little hotter than stock. Eventually I left it at 2 microsecs.

So all a bit inconclusive really, it will be interesting to see what effect the replacements mosfets have on the failed controller. This controller has also been fitted with a 12v/5v buck converter, I'm starting to wonder if this isn't having some effect on the driver stages. I think I might remove this and refit the LM317 with a bigger input resistor.

Sometimes things just get too complicated...

 

[honya96]

I don't think the dead time was the issue. Someone in this thread claimed that the 18FET KT controllers simply parallel 3 MOSFETs with the same gate driver, so that's a lot of gate capacity dealt with easily.

One way to be sure would be to grab CSD19505 instead of CSD19506. They have worse RDS(on) but the same gate capacity as the original STP80NF70.

That was me. They are parallel but the driver may be different or at least some resistors.

 

[geofft]

I don't think the dead time was the issue. Someone in this thread claimed that the 18FET KT controllers simply parallel 3 MOSFETs with the same gate driver, so that's a lot of gate capacity dealt with easily.

One way to be sure would be to grab CSD19505 instead of CSD19506. They have worse RDS(on) but the same gate capacity as the original STP80NF70.

Problem is that my main reason to use the CSD19506 was hoping the very low RDS would reduce mosfet temperature a little (which they have.. )

In fact the original fets in my controller were marked K150E09NE. The genuine versions of these are made by Toshiba and aren't too badly specified (other than a higher RDS), mine may be Chinese copies of course. In hindsight I should have left them alone, they worked pretty well and I just seem to have made more problems for myself.

 

[honya96]

I don't think the dead time was the issue. Someone in this thread claimed that the 18FET KT controllers simply parallel 3 MOSFETs with the same gate driver, so that's a lot of gate capacity dealt with easily.

One way to be sure would be to grab CSD19505 instead of CSD19506. They have worse RDS(on) but the same gate capacity as the original STP80NF70.

Problem is that my main reason to use the CSD19506 was hoping the very low RDS would reduce mosfet temperature a little.

In fact the original fets in my controller were marked K150E09NE. The genuine versions of these are made by Toshiba and aren't too badly specified (other than a higher RDS), mine may be Chinese copies of course. In hindsight I should have left them alone, they worked pretty well and I just seem to have made more problems for myself.

Those are in my 18FET and handle 14s 100A (really short) peaks, never got "hot" controller.

 

[honya96]

there are some open source examples for driving a BLDC with FOC on a STM32, so you won't have to start from scratch. I would prefer if we could write an open firmware for the Lishui controllers, they use STM32 processors and offer sensorless sinusodial drive.

regards
stancecoke

Are there any more powerfull lishui controllers?

Do you think there's a need for true FOC with gear motor at 500w? I believe Kunteng is enough for this power, and with a bit more FW work it can be for higher..

 

[stancecoke]

Are there any more powerfull lishui controllers?

They have several 48V 500W E-Bike-controller also. For even more power they have motorcycle-controllers up to 5kW.

Do you think there's a need for true FOC with gear motor at 500w? I believe Kunteng is enough for this power, and with a bit more FW work it can be for higher..

Hmm, I don't know, if you get much better efficiency with "true" FOC. The main advantage is that we could do sensorless motor control with this hardware.

regards
stancecoke

 

[casainho]

Are there any more powerfull lishui controllers?

They have several 48V 500W E-Bike-controller also. For even more power they have motorcycle-controllers up to 5kW.

But they are totally different in hardware between that models, unlike the KT controllers.

 

[geofft]

A small thing I've noticed with the firmware is that when initially powered up the bike can be pushed in reverse with no resistance from the motor (as with stock fw) but if any throttle or pas input is made then afterwards the bike always resists being moved in reverse. This condition can then only be reset by power down and back up.

I mention this only as a point of interest, it's not something that desperately needs any sort of 'fix' - I realise casainho is busy on other projects just now...

 

[stancecoke]

But they are totally different in hardware between that models, unlike the KT controllers.

are you sure?! The housing is different of course, but the pinning of the processor will be the same I think.

when initially powered up the bike can be pushed in reverse with no resistance from the motor (as with stock fw) but if any throttle or pas input is made then afterwards the bike always resists being moved in reverse

This is normal, as the center aligned PWM is disabled at startup and gets enabled with the first ask for power. With a freewheeled motor this does't matter, with a direct drive this is necessary for doing regen...

regards
stancecoke

 

[casainho]

But they are totally different in hardware between that models, unlike the KT controllers.

are you sure?! The housing is different of course, but the pinning of the processor will be the same I think.

I remember to look at some information that pointed me to that. But since is harder/expensive to get the different models, and also I didn't found online detailed pictures of them, I think is not possible unless buy and see inside.