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

Firstly ,Thank you to everyone who worked on this project.

I bought hc05 for BluOSEC Android App.
but, Data connection could not be established.

for testing ,I used powerbank for 5 volts

check the picture on the link



why can't i connect?

hc05 connecting to BluOSEC,no problem

but,hc05 not connecting to controller


I saw on the internet that they use resistors between Arduino and HC-05

see the picture in the link



The reason for using this resistor is this;Arduino tx output is 5 volts. The hc05 rx input is 3.3 volts.

Is there such a volt difference in our example(stm8 between hc05).
Or is the communication frequency incompatible?
 
Hello Guys.

I own a 18 fet KT labeled as 56V-90V, 50A max with a 16S (67V max) battery.

IMG_20210418_222547.jpg


One of the 2 resistors here is getting VERY hot, like burning finger when touching it and it smells heat a lot. I highly doubt it will be fine at long term so has anyone replaced them by a buck DC/DC and can provide a scheme showing what to get rid of and where to connect it. Since battery voltage will be within 67V and 55V is there a risk that the voltage output of the buck converter is too low that it affects other components ?

@stancecoke there is something that would be relevant to mention in the wiki, for 18fet voltage calib must be around 150.
I couldnt get the controller working, but thanks to diagnostic mode I figured out that it was in "Undervoltage state".

Also, with wheel in the air the wheel doesnt stop and keep spinning a bit (10rpm/min) even with throttle fully closed. I tried to play with throttle min / max but still. Any clue ? I'm not using P.A.S.


EDIT :

I've burned couple of fets, when I power the controller (throttle isnt even connected) New fets Fry and sparks...
 
:warn: Has anyone else noticed that these latest problems with the firmware seem to have a pattern of correlation? Could the code have a bug that has been added with some new(<1 year) update?

Symptoms seem to be; wheel spinning on it's own after throttle or pas. Burned mosfets. Overheating big resistor and LM317. BluOsec related problems with commutation.

I have used the firmware over 3 years and uploaded the master branch many many times within that time but I haven't managed to get it to work the same in 6 months that it has been with the same motors etc.

What could have changed with the code so drastically? And no, I'm not complaining about anything because this is a hobby project and free. It just feels odd. Are there any old branches and Bluosec versions archived somewhere to see if there's something that could work better?
 
Valopallo said:
What could have changed with the code so drastically?
You can see the history at github
https://github.com/stancecoke/BMSBattery_S_controllers_firmware/commits/Master

And you can download the Repo at any commit. But we haven't changed critical code for many years now. If this is really a problem and not just wrong settings, it could be caused by changes in Kunteng hardware or newer Android versions. You should use the diagnostics mode instead of the BluOSEC for troubleshooting.

regards
stancecoke
 
stancecoke said:
Valopallo said:
What could have changed with the code so drastically?
You can see the history at github
https://github.com/stancecoke/BMSBattery_S_controllers_firmware/commits/Master

Thanks, I will try some of the older ones before the WALK_ASSIST changes because that would fit to my timeline of working master branches.

stancecoke said:
endlessolli said:
But when actually using the setup / driving, it does not work properly.

Yes, the app is known to freeze the system sometimes. We have the bugfix in the branch "torque from X4" already...
... It's just half an hour of work to port the solutions of the "torque from X4" branch to the master, but nobody have done this job so far.

May I please ask if someone capable of fixing the BluOSEC app problem to take the time and do that? It would really help to cancel those problems out when I try again with new controllers.
 
I think you are right, the walkassist seems to be operating by default when I turn on the controller, and I don't know why but that causes fets to burn. Components near the fets were damaged by the "explosion". Sorry stancecoke I cannot provide diagnostics log as the board is 100% dead now. I've attached the parameters. I'm using a 16S battery and a fat 3KW MXUS motor.

173585511_2911612249109299_8631520215388978961_n.jpg


178352873_1174898152936688_3134772898195550535_n.png
 
atkforever said:
I think you are right, the walkassist seems to be operating by default when I turn on the controller,

Your undervoltage is 67V!
Code:
 67 x (256/200) = 85

atkforever said:
I own a 18 fet KT labeled as 56V-90V, 50A max with a 16S (67V max) battery.
 
Ah sorry it's not the latest config, volt calib was set to 150, so undervoltage and overvoltage were fine.
 
Hi ,Thank you to everyone who worked on this project.

How do I activate P.A.S?( without a screen)

I could not get information in the Blueosec application. I could not establish a connection.
Also I don't have a screen.
 
atkforever said:
the walkassist seems to be operating by default when I turn on the controller, and I don't know why but that causes fets to burn.

Please don't blame the push assist for your problem if you can't prove it 100%. Users are unsettled by such statements.
Even if the push assist is activated by mistake, the battery current in this function is so low that it should not kill any mosfet.

Mosfets are burning due to wrong motorspecific angle, too big GainP / GainI settings, to high max. current settings...

mehmetoz1980 said:
How do I activate P.A.S?
PAS is active by default, as long as you don't have activated the torquesensor option. You have to set the right PAS threshold according to your PAS sensor.

regards
stancecoke
 
stancecoke said:
atkforever said:
the walkassist seems to be operating by default when I turn on the controller, and I don't know why but that causes fets to burn.

Please don't blame the push assist for your problem if you can't prove it 100%. Users are unsettled by such statements.
Even if the push assist is activated by mistake, the battery current in this function is so low that it should not kill any mosfet.

Mosfets are burning due to wrong motorspecific angle, too big GainP / GainI settings, to high max. current settings...

mehmetoz1980 said:
How do I activate P.A.S?
PAS is active by default, as long as you don't have activated the torquesensor option. You have to set the right PAS threshold according to your PAS sensor.

regards
stancecoke

thanks you stancecoke

ı accord PAS threshold. (1.9 change to 1.5)
now,it working

but 25km/s speed limit
 
Hello. I want to share my 2WD bike's KT24/36-SVP -controller case mod and my frame casing with alarm.

IMG_20210510_181938.jpg

I drilled a hole to the side of the casing, sealed the lm317 with kapton tape and the big resistor with heat resistant tubing from touching the screw and clamp.

IMG_20210508_130645.jpg

IMG_20210508_130637.jpg

This setup keeps the controller(s) cool at 58.8V. I also used 2 old controller cases to seal the connection points and the dc-dc converter/bluetooth from weather. I bolted them to metal sheets to keep the cases cool.

IMG_20210510_085810.jpg

I also made the top of the whole frame casing from insulated Lg smartphone with a prepaid sim and preconfigured Tasker app to operate as an alarm. The bike calls me and launches loud alarm sound if someone moves the bike when engaged. I can toggle the alarm on and off by calling to it. It also sends sms messages in case of a boot operation and low battery. The phone is charged from the dc-dc converter at the bluetooth box.

162066253666850956388.jpg

Does ayone know how many amps can be safely drawn from the display connector/dc-dc converter?
 

Attachments

  • IMG_20210510_085806.jpg
    IMG_20210510_085806.jpg
    210.5 KB · Views: 1,136
I drilled a hole to the side of the casing, sealed the lm317 with kapton tape and the big resistor with heat resistant tubing from touching the screw and clamp.

...I've been running a similar arrangement on my controllers for some time now, with no issues. The end caps of of the big resistors are usually metal (under the paint) so make sure they don't touch the metalwork or you could end up with 58v on the case... :shock:
I managed to find some TO220 resistors to use here, but they weren't easy to source.

Nice work though, I'm glad I didn't have to wire that lot up.... :?
 
stancecoke said:
The Kunteng hardware is very limited, a poor 8bit processor with no possibility to do "real" FOC. Therefore I concentrate on the Lishui hardware for about two years now. The Lishui firmware is ported to the very cheap an widely available controller of the Xiaomi M365 scooter, also.

I'm working at making use of this controller on bike with a small space for a controller, waiting on Ali shipping now. A few basic questions, if you don't mind: does the firmware use torque or speed-based throttle control (I know torque is the default on ebics), and after adjusting the BATTERY_LEVEL_1-5 and VOLTAGE_MIN values do I need to make any changes to the calibration factors (like to the CAL_BAT_V or CAL_V) to use it at 52V, if the m365 board is stock? Thank you!
 
Orange_Crush said:
does the firmware use torque or speed-based throttle control
It's torque-control by default. In the Lishui-firmware, you can switch to speed control in the configurator, but it is not well tested.

68747470733a2f2f7777772e706564656c6563666f72756d2e64652f77696b692f6c69622f6578652f66657463682e7068703f63616368653d26773d39303026683d35343726746f6b3d353130393336266d656469613d656c656b74726f746563686e696b3a677569616476616e63656473657474696e67732e706e67


Orange_Crush said:
do I need to make any changes to the calibration factors
no, you don't need to adjust the parameters for a basic functionality.

If you have further questions, please start a new thread, as this topic has nothing to do with the kunteng project :wink:

regards
stancecoke
 
Now when I apply throttle, acceleration comes in bursts like 1 per second rather than smooth. To be honest, this firmware is a dead horse we have all been flogging for years and getting little progress, the github repo hardly gets updated and the only answers we really get are 'mi mi mi read the wiki' or 'mimimi i am not your plotting service' Stop wasting time on this, get a good soldering station and build the cheap foccer controller as it doesn't seem to be plagued with all these issues and also doesn't require a degree in electrical engineering to set up.
 
stancecoke said:
no, you don't need to adjust the parameters for a basic functionality.

If you have further questions, please start a new thread, as this topic has nothing to do with the kunteng project :wink:

regards
stancecoke

Perfect, thank you very much for the reply and clarification -I wasn't aware the configurator was working for the m365 board yet, that's great.

I'll start another thread- I do have a few other questions, sorry for the minor hijacking.
 
Orange_Crush said:
I wasn't aware the configurator was working for the m365 board yet,

It works on the Lishui project, but it should be no problem to make the configurator run on the M365 project also, if there is a bigger user-community for the M365 firmware...

sdobbie said:
To be honest, this firmware is a dead horse
This firmware has 62 stars and 50 forks at github. You will hardly find a more successful project for E-Bike controllers. You should think about whether the problem might not be sitting in front of your screen. :wink:

regards
stancecoke
 
I've had no issue with my 6fet KT, it's working like a charm and as I understood this FW has been dev based on those small boards.

I'm having a lot of issues with a 60V+ 18fet controller, and many users here had the same issues with 18fets : resistors + LM getting VERY hot that it needs to be replaced by a DC/DC buck, controller not powering up due to wrong volt cal (the wiki is wrong for this part, as I said above).
I've read the wiki 10times if no more, and still, I burned couple of fets and I'm not the only one and trust me, I've followed EVERY step of the programming process.
You should mention in the wiki that it's not yet 100% compatible with high voltage KT controllers.

Please understand we don't have your knowledge in programing. If you need more informations about the issues I had, lmk.
 
atkforever said:
the wiki is wrong for this part, as I said above

Feel free to edit the wiki, everyone with a github account can write to the wiki. You can even add an own page for high voltage 18 FET controllers, if they need special actions. I have never used Kunteng controllers with more than 6 FETs and I don't use Kunteng controllers at all at the moment.

regards
stancecoke
 
I'm having a lot of issues with a 60V+ 18fet controller, and many users here had the same issues with 18fets : resistors + LM getting VERY hot that it needs to be replaced by a DC/DC buck, controller not powering up due to wrong volt cal (the wiki is wrong for this part, as I said above).
I've read the wiki 10times if no more, and still, I burned couple of fets and I'm not the only one and trust me, I've followed EVERY step of the programming process.

Even with the 6-fet version the resistor and LM317 get pretty hot, I'm currently using the method I posted back on page 126 of this thread which has proved to be reliable. Not sure if this kind of setup would work with the 12 and 18 fet units however, I've only ever used the 6 fet.

Be careful using buck convertors to provide these internal supplies, I experimented with these (admittedly cheapo chinese types) some time ago and like yourself was getting random mosfet fails. Eventually went back to the stock setup (with the mods as above) and all has been ok since. I think the 15v line needs to be very stable and reliable, I guess the buck o/p just isn't good enough, maybe some experimentation with other high quality dc-dc supplies is needed,
 
Hi all,

I bought bluetooth module JDY-31 (still on it's way from china). Online I found the following:

One significant difference between the HC-05 and the JDY-31 is that the HC-05 sends data when you stop sending it data through the UART (for a programmable amount of time, usually a few mS). The JDY-31 sends data when it receives newline characters \n\r. That means you cannot reliably send random binary data

Is this a problem and should I order a different module? (i.e. does the app rely on sending binary data or data without newlines?).

Thanks
 
I just want to voice how happy I am with this firmware. Especially after reading the criticism from a certain user.

I've been running this firmware on my 18 mosfet kunteng controller for the past >5000km, and I couldn't be happier!

It has been extremely reliable, even clocked to +-3000W peak.

Thank you Stancecoke :D
 
Corrida victim said:
I've been running this firmware on my 18 mosfet kunteng controller for the past >5000km, and I couldn't be happier!

:bigthumb:

You're welcome! :)

regards
stancecoke
 
geofft said:
I'm having a lot of issues with a 60V+ 18fet controller, and many users here had the same issues with 18fets : resistors + LM getting VERY hot that it needs to be replaced by a DC/DC buck, controller not powering up due to wrong volt cal (the wiki is wrong for this part, as I said above).
I've read the wiki 10times if no more, and still, I burned couple of fets and I'm not the only one and trust me, I've followed EVERY step of the programming process.

Even with the 6-fet version the resistor and LM317 get pretty hot, I'm currently using the method I posted back on page 126 of this thread which has proved to be reliable. Not sure if this kind of setup would work with the 12 and 18 fet units however, I've only ever used the 6 fet.

Be careful using buck convertors to provide these internal supplies, I experimented with these (admittedly cheapo chinese types) some time ago and like yourself was getting random mosfet fails. Eventually went back to the stock setup (with the mods as above) and all has been ok since. I think the 15v line needs to be very stable and reliable, I guess the buck o/p just isn't good enough, maybe some experimentation with other high quality dc-dc supplies is needed,

I myself am running four 18 fet KT controllers (two at 52v, two at 72v) with this firmware and could not be happier! First of all, again many thanks to Stancecoke, Casainho and Xnyle for this amazing work. I can't thank you enough; you are heroes.

Now here are some insights that I had to learn to get these controllers to work at high voltages and power levels:

- I advice to always replace the 15V line (resistor + LM317) with a buck converter. Both for the 48V as well as the 72V version of the 18 fet Kt controller. Not only can you eliminate the scary temperatures of the resistor and LM317, but equally important I have found that at lower battery voltage levels and high power usage (but critically ABOVE lvc voltage levels), the LM317 setup cuts out prematurely, leading to an effect that resembles LVC but is not LVC. So my recommendation is to always replace the 15v line by a buck converter; this leads to much more consistent performance at lower voltage levels. I use the 120V (or 90v) -> 12V converters of Aliexpress and modify the resistors on this converter (change 12k to 15k resistors) to provide some 15,5v (the controller mosfets can take up to +/- 20v input). The 5V line on the controller is fine, you don't need to modify that part.
- Somehow the firmware only allows the voltage calibration factor up to a value of 100 instead of 255. So I have found that in order to make 84V (or higher) work with this firmware, you still need to modify the LVC resistor on the board even with a stock 72v controller. You need to find the set of a small and bigger smd resistors, and then replace only the bigger SMD resistor (15k or higher depending on the controller you have) by a trim resistor (30 or 50k) so that you can modify the LVC manually. Just remove the old LVC resistor from the board, solder 2 extension wires to get some working space and connect the trim resistor to the end. For a 72V controller I set the voltage calibration factor in the firmware to 89 (255*89/255=89V -> this would be the highest voltage you would ever reasonably need to be able measure when using regenerative braking, in case the BMS decides to turn off and you need the firmware to stop voltage flying to the moon) and then use the trim resistor to modify the resistance in such a way that the shown voltage in the bluosec app is the same as the voltage that you measure with a multimeter on your battery. You need to do this while the controller is turned on, so you can see the effect of what you are doing. Works like a charm, regenerative braking even with a full battery!
- These controllers are very versatile. This amazing firmware makes them the best controllers available for an ebike; I like them more than the sabvoton + CAv3 combination. I have modified 48V 18 fet kt controllers to 72v (other caps, mosfets, lvc) and also bought stock 72v versions. I have heavily improved the traces with lots of solder and additional thick wires + lots of 100V 1000 uF caps. Now I run these 18 fet controllers at 300 phase amps and 100 battery amps, so at 72v - 84v that is some 7000 - 8000 watts flowing through these bad boys. Not bad for such a cheap controller, and even with torque sensor functionality!! They can handle the bigger motors as well: 50mm magnets, 3T, 6mm2 phase wires, ferrofluid. All run fine!

The bluosec app from Xnyle is a piece of art in itself. It has everything one could ever whish for! I have multiple x4 connectors on my bike, so I can switch from torque sensor mode to motor temperature reading by switching to another connector. Amazing functionality!
 

Attachments

  • LVCextension.jpg
    LVCextension.jpg
    313.8 KB · Views: 1,448
  • IMG-7536.jpg
    IMG-7536.jpg
    81.1 KB · Views: 1,447
  • IMG-7533.jpg
    IMG-7533.jpg
    79.7 KB · Views: 1,447
  • 15vBuck.jpg
    15vBuck.jpg
    152.2 KB · Views: 1,448
  • unnamed.jpg
    unnamed.jpg
    154.5 KB · Views: 1,448
  • IMG-5564.JPG
    IMG-5564.JPG
    279.1 KB · Views: 1,448
  • IMG-5565.JPG
    IMG-5565.JPG
    325.5 KB · Views: 1,448
Back
Top