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

I tested the PAS, found that I did some errors and corrected them. Now works, I tested the PAS code as also the final setup running a motor.

Direction works well as you can see from the log, where although ui16_pas_pwm_cycles_ticks have a valid timing value while ui8_pas_direction = 1, the ui8_pas_cadence_rpm is zero only on that state (ui8_pas_direction = 1):

 
See my 2nd last message, just before the one you wrote just now.
 
@usertogo bms battery can sell you 72v 40A 12fet kunteng for 35$ + 25$ dhl shipping if you ask them. Also if you are in the EU they can declare lower value. If you need more power/ want to run cooler second cheapest 72v kunteng is this 18fet 50A http://s.aliexpress.com/byyQjUjU but you can get 24fet 70A for almost the same price but its about 34cm long
http://s.aliexpress.com/aeuaMZZZ (ask about 72v and sine wave. They have it) and take lcd3 with it.
 
honya96 said:
@usertogo bms battery can sell you 72v 40A 12fet kunteng for 35$ + 25$ dhl shipping if you ask them. Also if you are in the EU they can declare lower value. If you need more power/ want to run cooler second cheapest 72v kunteng is this 18fet 50A http://s.aliexpress.com/byyQjUjU but you can get 24fet 70A for almost the same price but its about 34cm long
http://s.aliexpress.com/aeuaMZZZ (ask about 72v and sine wave. They have it) and take lcd3 with it.
honya96 said:
I found a good picture of all base kunteng controllers 6,9,12,18,24Fet. Its from Risunmotor.com they have best prices I found yet and duty free shipping, If you take whole kits, not just single controller.

Maybe you want to add this picture to the project page. :)
Just added the picture and that links, including that details about the mosfets number and power - thanks!!
 
You are welcome, I want to help as I can.. yesterday I had an idea. What about modifying this display
http://s.aliexpress.com/EFfiMfAf to work with "OUR" firmware, while still compatible with kt-lcd series? It will open really endless possibilities. I will try to find some info about it like the chip inside or if it can be programed by the usb on it. The are many suppliers which have their logo at startup or in background so it should be easy?
 
We are now at a state of our OpenSource firmware that we can get out the most efficiency possible from the controller!!
We now can tune and verify that we are using the least battery/motor current for the same motor mechanical load -- and how do we know that the original firmware is tunned for our motor get out the most efficiency possible?? We can't, but we can with our OpenSource firmware :)

I just implemented and tested #16 Motor FOC angle offset adjustment.

Before we were adjusting ui8_adc_id_current, to be in a lower or higher interval than 127, that way like adjusting the zero cross value that should be near 127.
Code:
      if (ui8_adc_id_current > 127) { ui8_angle_correction++; }
      else if (ui8_adc_id_current < 125) { ui8_angle_correction--; }
While it works, the thing is that when regen/ebrake, the current flows backwards and the phase B current "sinewave" is inverted in phase and so that zero cross should now be wrong for regen/ebrake. Adjusting the angle to were the zero cross of phase B should happen is the way to go as it should be correct for both motor and regen working mode.

And the code was kind of simple:


And the instructions for the users, to be able to tune/optimize the motor and controller efficiency!!


While doing my tunning process for my Q85 motor, I found that 127 was not the best point but instead 137, which is inline with stancecoke experiments while adjusting ui8_adc_id_current interval.
My motor running with the same mechanical load, at 15km/h | vbat 28V, with FOC_READ_ID_CURRENT_ANGLE_ADJUST = 127, took 2.8A and with FOC_READ_ID_CURRENT_ANGLE_ADJUST = 137, took 2.6A. And improvement of about 7%!!
 
honya96 said:
You are welcome, I want to help as I can.. yesterday I had an idea. What about modifying this display
http://s.aliexpress.com/EFfiMfAf to work with "OUR" firmware, while still compatible with kt-lcd series? It will open really endless possibilities. I will try to find some info about it like the chip inside or if it can be programed by the usb on it. The are many suppliers which have their logo at startup or in background so it should be easy?
That would be another project :) -- I mean, would be for sure time consuming because it would be embedded software/firmware development, for a big color display and with a lot of possibilities. It is hard to find developers for embedded software/firmware development so I guess we would have no one developing.
I prefer to go with a mobile app, since this controllers also have that option. Mobile app development is very strong, it is easy to find advanced development and debug tools, as also developers :)
Also, I would not put that big color display on my ebikes, that is why I prefer LCD5 over LCD3, because is smaller and more discreet, I use and park my ebikes on the street and I don't want anyone looking at display that seems expensive and have the temptation to steal it.
 
casainho said:
It took me some time to understand what you were doing, at least I got it. :wink: I think it will be hard for a "normal" user to do this tunig, as less people have the possibility to put a defined load to the system, but it's good to have the possibility.

honya96 said:
What about modifying this display http://s.aliexpress.com/EFfiMfAf to work with "OUR" firmware,
This is a Bafang compatible display, so I assume that it uses the Bafang communication protocol. It is much easier to make our firmware "speak" the Bafang protocol (it can speak Kunteng and Kingmeter already :wink: ) than to make the display speak Kunteng...
For the details of the Bafang protocol see this link e.g.

The eggrider speaks all three protocols also!

regards
stancecoke
 
stancecoke said:
casainho said:
It took me some time to understand what you were doing, at least I got it. :wink: I think it will be hard for a "normal" user to do this tunig, as less people have the possibility to put a defined load to the system, but it's good to have the possibility.
Yes, and that is why I think is safe to try go with the same components: controller and motor from BMSBattery as I think that values should not change much. As also for instance the wiring of motor phases and hall sensors -- with all the motors I tested from BMSBattery, if I keep the same colors for the wires, it just works.
Maybe someone with a big motor and power controller may want to optimize the max possible.

stancecoke said:
honya96 said:
What about modifying this display http://s.aliexpress.com/EFfiMfAf to work with "OUR" firmware,
This is a Bafang compatible display, so I assume that it uses the Bafang communication protocol. It is much easier to make our firmware "speak" the Bafang protocol (it can speak Kunteng and Kingmeter already :wink: ) than to make the display speak Kunteng...
For the details of the Bafang protocol see this link e.g.

The eggrider speaks all three protocols also!
For now, I prefer to keep simple with BMSBattery/Kunteng displays. The number of users of firmware is very small, I see no reason to get the things more complex in terms of development and testing.
 
I updated:
1. the main thread title to: Flexible OpenSource firmware for BMSBattery S/Kunteng KT motor controllers (0.5kW up to 5kW)
-- Yes, the firmware is even more than customizable, it is flexible in the sense anyone adapt for some specific needs
-- 5kW are the controllers of 72V 70A
2. main thread description with project status
3. added the page with photos: "How to open the controller and solder the programming header", that is useful for users and for developers.
 
casainho said:
0.5kW up to 5kW
Can you please write 0.25kW up to 5kW. For everything higher than 250W you need an insurance and you have to wear a helmet in Germany :oops:

casainho said:
3. added the page with photos: "How to open the controller and solder the programming header", that is useful for users and for developers.
Why do you suggest to not connect the VCC wire?! I use it and have no problems at all, you don't have to handle the battery voltage in this case while flashing.
See https://www.pedelecforum.de/wiki/do...ik:open_source_firmware_vorbereitung_hardware

regards
stancecoke
 
stancecoke said:
casainho said:
0.5kW up to 5kW
Can you please write 0.25kW up to 5kW. For everything higher than 250W you need an insurance and you have to wear a helmet in Germany :oops:
Done.

stancecoke said:
casainho said:
3. added the page with photos: "How to open the controller and solder the programming header", that is useful for users and for developers.
Why do you suggest to not connect the VCC wire?! I use it and have no problems at all, you don't have to handle the battery voltage in this case while flashing.
See https://www.pedelecforum.de/wiki/do...ik:open_source_firmware_vorbereitung_hardware
Done and I put that note, that is optional to use the VCC or not.
 
I just updated the first page, making the focus on the main advantages and unique selling propositions, but I kept the project status and in the end the history and motivation. Here it is:

-----

controllers.png


This OpenSource firmware/embedded software runs on the BMSBattery S/Kunteng KT motor controllers.
The main advantages of this controllers are:
1. sine wave/"FOC": motors run silent and very efficient
2. cheap: starting at 20€
3. widely available: many online shops sell them and ship to worldwide
4. various sizes e powers: from 0.25kW up to 5kW (72V, 70A, 24 mosfets)
5. supports LCD and Bluetooth mobile app
6. schematic available: important if you want to mod/hack, repair or even build your own controller

The main advantages of our OpenSource firmware/embedded software are:
1. sine wave/"FOC" max efficiency: motors run silent and very efficient and is possible to tune a parameter to get the best efficiency possible for a specific motor
2. flexible and OpenSource: more than customization, any feature for some specific need can be easily implemented and for free (no need to pay any commercial license)
3. throttle, PAS and torque sensor: all of them are supported
4. LCD3 and LCD5: all of them are supported
5. regen/ebrake: works very well on the direct drive motors
6. motor torque controller/motor current controller
7. motor speed controller

The firmware sources are available on github and the developers and users communicate together on the Endless forum message.

Project status
As of 14 December 2017, the firmware is still experimental however we already use it on our EBikes :)
See some videos on youtube by searching on youtube for “OpenSource firmware Ebike BMSBattery”.

Current state:
1. Tested on:
1) S06S and S12S motor controllers
2) Q85, Q100 and Q11 (direct drive) motors
3) 24V and 48V batteries
4) LCD3 and LCD5
5) throttle; PAS and pedal torque sensor
2. Features:
1) motor works well: starts with block commutation and then changes to sinewave
1- implemented “very low resolution FOC” that gives good efficiency (see next point)
2- efficiency is good, at least equal to original firmware and near to Lishui 12 fets FOC controller
1> there is one parameter that can be tweaked to make sure firmware is getting out the most efficiency possible from the controller
4- regen ebrake (see this video showing regen ebake working and Regen ebrake like coast brakes)
5- torque controller/motor current controller
6- motor speed controller
2) LCD3 and LCD5 works (not all features are implemented yet). What works:
8- shows:
1> motor speed
2> battery state
3> motor power usage
4> throttle active
5> brake active
6> some errors
9- changes:
7> assist level
8> max motor speed
9> P3: Power Assist Control Mode
10> C5: Controller Maximum Current Adjustment Mode
3) Throttle: works
4) Brakes: works
5) PAS: works
6) Torque sensor: works

Project history and motivation
I started this project on 25 April 2017 because I would like develop an OpenSource firmware for the EBike controllers. Why I am wanted to do that? because I wanted to use a well know controller that it is easy to repair/mod/adapt for my specific projects. I am developing the firmware for it, as OpenSource and I would like to share with others that have the same needs. My mission is similar to the Tesla mission (https://www.tesla.com/blog/mission-tesla): "to accelerate the advent of sustainable transport" and innovation on personal light electric vehicles.

The idea was to found a cheap and widely available EBike controller that could be programmable. I was developing, since 2015, firmware for the controllers of electric unicyles and they use the microcontroller STM32F103, that is very cheap and popular - the board is also cheap and widely available on market, that comes from China. By the way, the hoverboards controllers use the same STM32F103 microcontroller.

For EBikes, I found the most recent BMSBattery S series controllers like S06S sinewave use the STM8S105C6T6 microcontroller that is programmable, easy and cheap to develop for. There are OpenSource and cheap development tools for it.

BMSBattery sells the S series controllers, starting with S06S of 24/36V 15A (0.5kW, 6 mosfets) up to S12S of 72V 40A (2.9kW, 12 mosfets).
This controllers are developed by Kuteng (http://www.szktdz.com/en/ | http://minshine.cn/). There are available on the market in many different versions of Kuteng controllers, from 24V, 36V, 48V and 72V, with max currents of 70A (5kW, 18 mosfets).

Over the time, more and more users/developers did join the project and it was not anymore my project but a community project as I wished since the begin! You can find their nicknames and contributions on the forum message or git commits.
 
So, I think firmware is almost finished but at about 80%, missing mainly things like some the commands from the LCD. I am not motivated to implement them as I do not use them and I don't know if anyone will use them, I don't want to put my precious time in something that no one will use.

But there are things that I want to finish, like the Speed sensor #19.

And I am now start thinking about the mobile app. But for start, looking at the bootloader option of STM8. Seems that if bootloader is enable on the options bytes (which I think it is not on the original firmware), the user can flash the firmware using the UART -- this would mean that users would need to use only 1 first time the STLinkV2 to erase the original firmware and enable the UART bootloader, after they could flash our firmware by UART...
And if we have a mobile app, the app could flash the firmware, so the user would just need to hit a button to update the firmware -- but this could work on the mobile app or even the Java tool :)

For the interested, here is the ST documentastion for the STM8 bootloader: https://opensourceebikefirmware.bitbucket.io/EmbeddedFiles/9-STM8_bootloader.pdf
 
I just implemented the Speed sensor #19.

The display will show the wheel calculated for the external sensor only if it is connected, otherwise will calculate from the motor erps (hall sensors signal). And works as expected, just tested with my geared Q85 motor and with an external wheel speed sensor I bought on BMSBattery site.

Here is a log from tests, the green line is the final wheel speed value that is shown on the display. The other two are from that two sources. At middle of my test, I just disconnected he external sensor (purple line) and as we can see, the green line switches to use the signal from motor erps/hall sensors (red line).
Please note that I was printing integers and the printf is not printing float values. I use float values and the speed shown on the LCD is not scattered, is good as the original firmware.



The external speed sensor is like the PAS sensor in terms of firmware, I just put the code on the PWM cycle code:


And the code on the slow loop, that calculates first the speed from the external sensor and if it is less than 1 (the same as no sensor connected), will calculate the speed from the motor erps/hall sensors and use it instead:
 
Mobile Android app

I challenged my girlfriend to develop the Android app. She already developed one, 1 year ago, for the EGG firmware electric unicycle. And I think the app for our ebike firmware would be more or less the same. A small app (short to develop so we can finish the project!!) with the main parts:
1. Bluetooth communications, to send and receive the data
2. Configurations menus: to configure the options of the firmware, like number of power level assist of each step selected on the LCD.
3. Real time data dashboard: the same as the LCD main functions like show the speed, motor current, etc.
4. Update/flash new version of firmware

After having this working, we would have a structured Android app that we could then expand to add things like more configuration options. Then I could do it easily or others, like stancecoke, I guess.

Some pictures of the EEG firmware electric unicycle app:
205e1ce6-6fae-11e6-9f73-742421c3959f.png


5ebc2fdc-ac49-11e6-8f91-294b2bfe9982.png


5eb8acfe-ac49-11e6-9328-51c411b36ab1.png
 
Although most of this is way over my head as I'm just a simple mechanic, I do like this development very much so I'll subscribe to learn more. Thanks for all the work you're putting in!
 
usertogo said:
I thank you for this great initiative! I also think it is very wise to choose STM32 processor based products as they should have plenty of processing power to run the most sophisticated algorithms we could come up with! I am looking forward to work myself into this and operate such an open source development on one of my prototypes very soon!
Thanks. And please use it and we are here to help!

usertogo said:
Just as the STM32 probably can run circles around the STM8 I wonder how to make sure to get the 32 bit platform when ordering one? I was a little disappointed to find a huge 18 FET controller using the 8 bit version... what is the design criteria the makers of these use?
Price, almost for sure. And we can see this STM8 is up to the task. Would not be if using FOC and sensorless.

usertogo said:
Here is another field that you all should find interesting and the BMSbattery name implies you might want to get into very soon too? RFC:https://prezi.com/qibqej3sqqy1/open-source-battery/
I don't know if you mean a BMS. There is a popular chinese cheap bluetooth BMs that uses standard ICs, like the AVR 8 bits use on the Arduino :) :) --- would be easy to make a firmware for it:
https://opensourceebikefirmware.bitbucket.io/Smart_BMS_with_bluetooth.html
 
SlowCo said:
Although most of this is way over my head as I'm just a simple mechanic, I do like this development very much so I'll subscribe to learn more. Thanks for all the work you're putting in!
Thank you. And it is really important to have feedback.
 
What kind of BT-Module do you plan to use with the App? The old standard bluetooth, like the HC-05, or BLE like the HM-10? Or do you plan to use the original Kunteng-Module?
Do you want to use the app for switching the system On/Off?

regards
stancecoke
 
stancecoke said:
What kind of BT-Module do you plan to use with the App? The old standard bluetooth, like the HC-05, or BLE like the HM-10? Or do you plan to use the original Kunteng-Module?
I think it is easy to use the one that BMSBattery sells (Kunteng module), and yes, them sell them at unit ($9) if we ask them.
But maybe it will be easy to add support to Android app for the other modules, as they are famous with Arduino/Android and there should be a lot of examples.
 
Have you tested your Kunteng module/app already?
I'm still looking for someone who sniffes the communication between the App and the controller and posts the traffic, to learn how it works. Logging the traffic with the HCI snoop log and analyze it with wireshark is quite easy, for the Lishui-module I did it this way.

regards
stancecoke
 
stancecoke said:
Have you tested your Kunteng module/app already?
I'm still looking for someone who sniffes the communication between the App and the controller and posts the traffic, to learn how it works. Logging the traffic with the HCI snoop log and analyze it with wireshark is quite easy, for the Lishui-module I did it this way.
Hmmm, I wasn't expect such work.... :-(
Well, I hope to have something that I get the same data on Android that I sent to UART on STM8. I am not looking to do an app that is compatible with original firmware, instead an app that works for our firmware, so, I hope we don't have to deal with all that work you did mention. What do you think? do you think will be possible or that module "changes" the "payload" in some way?
Must say that I like your notes about the DIY module :)
https://opensourceebikefirmware.bitbucket.io/Motor_controllers--BMSBattery_S_series--Bluetooh--DIY_Bluetooth_module.html
 
I don't know, how the Kunteng-module works. There are hints in the german forum, that you can't switch on/off the system with the Kunteng-app. The Lishui-module uses two GPIO channels of the HM-10, one for switching the system on/off and one for reading the battery voltage. Therefore you need to know the commands the app uses to read/write the HM-10 GPIO channels.
If you want to switch the system manually and send the battery voltage by UART (I think this is not implemented in the Kunteng-protocol), then you don't need to do the sniffing....

regards
stancecoke
 
stancecoke said:
I don't know, how the Kunteng-module works. There are hints in the german forum, that you can't switch on/off the system with the Kunteng-app. The Lishui-module uses two GPIO channels of the HM-10, one for switching the
I remember to read information when I looked at info about the DIY module you built. And yes, the bluetooth module must support that control of GPIO pins and that switch for on/off.
But for what I can understand, the S06S-BL is to be used with a LCD AND Bluetooth module, and maybe the idea is that the on/off is always done with the LCD.

I think the ebike kit for my ebikes would be:
- S06S-BL (or S12S-BL if I can buy it or I would need to mod a S12S to have BL)
- LCD5
- Bluetooth module
- torque sensor
- ebrakes

For a direct drive motor, I would like to have the possibility to ebrake that way I did, "ebrake like coast brakes".

What you be your ebike kit??
 
Back
Top