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

[casainho]

The ramp just should give a smooth start up, but then the motor-torque should stay constant and you can adjust the speed with your human power. That's the origin idea of the "torque-simulation" mode.

I don't know if I understand well. You mean that motor max out the assist power at low pedals RPM and the user will then need to increase his pedal torque to get more speed? that is strange for me... I would expect to get help from the motor up to the defined max wheel speed. And with direct drive that will not work -- in fact I need to work more on the direct drive part as I am not totally happy with the results, like motor blocking/braking/regen when I pedal over the motor max speed...

Perhaps we should give the user the possibility to set the steps of the PAS levels by himself, e.g.
Level 1 = 0%
Level 2 = 10%
Level 3 = 20%
Level 4 = 50%
Level 5 = 100%

I can implement that. Can you please specify that values again as I think you are not considering that we have value for assist level of: 0, 1, 2, 3, 4, 5 and I think is more intuitive to put 0% output with assist of 0.

 

[casainho]

Up to now, before the firmware was ready to be used on our ebikes, I was debugging by printingf some key variables and see them in real time graph and the ebike was sitting near my computer. Now I need to keep getting that data while I ride my ebikes, but this time not to see in real time but log it to see later on PC using the same graph visualization software.

Last time I drove with my direct drive motor, not everything were ok, sometimes when did brake by rotating the pedals backwards, only when up to max regen current, the motor would almost block and just release after a few seconds... really not working as expected. To debug such issues I plan to use printfs and send the variable data to an Arduino + uSDCard and after view the data on the serialplot software.
This debug tool will also be important for log our rides and verify that everything is working as we expect, because sometimes the things works even if on the background something is not working... sometimes we have luck

 

[stancecoke]

You mean that motor max out the assist power at low pedals RPM and the user will then need to increase his pedal torque to get more speed?

Don't think in speed all the time! If you set the motor power to e.g. 100W you will ride 15 km/h with just pseudo pedaling (just as an example) So if you are riding in a group of several bikers you can adjust your speed to the groups speed to e.g. 16,5 km/h with a very small amount of human power. You won't be able to keep the groups speed if the motor power is cadence-dependent, because the sum of human and motor power will never fit to the needed power to keep the speed exactly. You will have to stop and restart pedaling all the time...

I can implement that. Can you please specify that values again as I think you are not considering that we have value for assist level of: 0, 1, 2, 3, 4, 5 and I think is more intuitive to put 0% output with assist of 0.

OK, the J-LCD has no level "0", so I suggestet to set level 1 to zero. You can set the default values to aequidistant steps as you do it actually, but give the user the possibitly to change the value according to his preferences. The Lishui Forerider-App does it this way.

Now I need to keep getting that data while I ride my ebikes

I solved that with a simple bluetooth module, that sends the UART-Data to my smartphone, where a simple terminal app does the logging (and displaying in realtime of course). :wink:

regards
stancecoke

 

[casainho]

You can set the default values to aequidistant steps as you do it actually, but give the user the possibitly to change the value according to his preferences. The Lishui Forerider-App does it this way.

Ok so it is done for now but I will add that as steps as defines, to be customizable on the Java tool. I can't right now think ahead for a possible mobile app, I think is soon yet. We can get that later.

Now I need to keep getting that data while I ride my ebikes

I solved that with a simple bluetooth module, that sends the UART-Data to my smartphone, where a simple terminal app does the logging (and displaying in realtime of course). :wink:

Even better!! Thank you

 

[honya96]

Guys I ordered st-link v2 and a spare controller ready to start testing in 4-6weeks, do I need something else to make it work? (Data logging?, etc...)

 

[casainho]

Guys I ordered st-link v2 and a spare controller ready to start testing in 4-6weeks, do I need something else to make it work? (Data logging?, etc...)

If you are not going to do serious development, then you should not need a lab power supply and an oscilloscope. But I advice you to buy fast fuses and use a BMS with your battery, this 2 things should protect your battery and controller.

And you can use a UART <-> USB cable, the ones used on Arduino, the 5V version -- that will let you do printfs to do some debug.

Also if you can, buy spare units of the controller, LCD, etc. And maybe try to buy the torque sensor, unless you are looking to use throttle.

 

[Buk___]

Four questions:

Is the S12SN controller compatible with your firmware?

If so, having programmed it with your code, can the original code be easily restored?

If so, what is required to upload your code to it?

Finally, would using a DC-DC booster with a settable constant current output between the battery and controller -- ala wturber's thread -- allow testing with lower risk to the controller from programming/algorithm errors?

 

[casainho]

Four questions:

Is the S12SN controller compatible with your firmware?

If so, having programmed it with your code, can the original code be easily restored?

If so, what is required to upload your code to it?

Finally, would using a DC-DC booster with a settable constant current output between the battery and controller -- ala wturber's thread -- allow testing with lower risk to the controller from programming/algorithm errors?

1. Should be but no one tested it yet
2. Original will be erased so not possible to restore. Anyway, the controller is cheap, buy 2 units!
3. In terms of hardware, you will need what is listed here: https://opensourceebikefirmware.bitbucket.io/Development_tools--Linux--Step-by-step_tutorial_development_tools--Hardware_tools_to_flash_and_debug_the_firmware.html#h1-2
For software: https://opensourceebikefirmware.bitbucket.io/Development_tools--Linux--Step-by-step_tutorial_development_tools--Tools_to_flash_the_firmware.html
If you are on Windows, there is a tutorial written by stancecoke, see the file on github
4. Sorry don't know to what are you referring about

 

[honya96]

Thanks, will look for that cabel. On stock firmware I am using basicaly just throttle (full power at PAS: 0) and I have kt-v12 pas sensor which gives me 300w at PAS: 1 for "legal purposes" sometimes I use it when I want to pedal, which doesnt help much on my heavy bike. I will be testing on 18 or 12 fet with lcd3.

 

[Buk___]

2. Original will be erased so not possible to restore. Anyway, the controller is cheap, buy 2 units!

So, no way to take a copy of the existing firmware before uploading yours and then put it back if things aren't working out?

4. Sorry don't know to what are you referring about

This thread covers it in detail.

Executive summary:

A DC-DC boost converter(example) can be used between the battery and controller to step up the battery voltage to present a higher voltage to the controller. (A 36V battery can be used to drive a controller&motor with 48V.)

But, those boost converters also have the possibility of supply their output voltage (settable to any voltage higher than the input up to some limit (80v in the case of the unit linked above) at a preset constant current from 0.5A up to their maximum (20A above). My random thought was that if during testing the firmware with a new version, you fed it via the boost converter, you could preset the current available to the controller to some low value initially and then once things appear to be working okay gradually step it up, thus protecting the controller output stages.

The booster simply won't let the controller draw more current than the value you preset, and if it attempts to, automatically falls back to some low value -- 5A is mentioned the linked modules blurb. That way, if anything goes wrong in the logic and the controller attempts to draw big current, you would get a heads up and avoid blowing your FETS.

Just a thought for those with greater knowledge (and investment) than I to consider.

 

[casainho]

So, no way to take a copy of the existing firmware before uploading yours and then put it back if things aren't working out?

Not possible, that is a protection as we should not be able to copy the original firmware.

This thread covers it in detail.

Executive summary:

I could not image such hardware, so cheap (15€), could exist
Well, what you want is using that hardware as we use our lab power supplies while we are developing and limiting the power supply output current -- and that saved A LOT TO ME!!!
So, that is a very good idea!! I just put this info on the project notes file because this can be an important tool!!

The disadvantages I see:
• efficiency is listed as 95%, so at least 5% of power will be lost but this value can be even higher in worst conditions
• no regen: will not be possible to use ebrake/regen when using a direct drive motor

 

[casainho]

You can set the default values to aequidistant steps as you do it actually, but give the user the possibitly to change the value according to his preferences. The Lishui Forerider-App does it this way.

Ok so it is done for now but I will add that as steps as defines, to be customizable on the Java tool. I can't right now think ahead for a possible mobile app, I think is soon yet. We can get that later.

Done!

 

[stancecoke]

OK, I solved that with an array, but it works with a switch/case structure also, of course.

regards
stancecoke

 

[Buk___]

So, no way to take a copy of the existing firmware before uploading yours and then put it back if things aren't working out?

Not possible, that is a protection as we should not be able to copy the original firmware.

Hm. Having briefly scanned the ST-LINK documentation, including the license agreement, they seem quite happy that you can use it to create binary copies for backup purposes; and the

Save file as… Saves the content of the memory panel into a binary, Intel Hex or Motorola S-record.

option seems to make that both possible and simple.

Is your statement that its "not possible" based on having tried and failed? Or having read that you shouldn't? Your own ethics?

Perhaps I should just buy the ST-LINK and try it for myself. I'd be a whole lot more likely to get involved in testing your software -- maybe even helping development; I was a programmer for 30 years before retiring -- if I knew I could put the controller back to a know good state if things go wrong.

 

[casainho]

Is your statement that its "not possible" based on having tried and failed? Or having read that you shouldn't? Your own ethics?

Perhaps I should just buy the ST-LINK and try it for myself. I'd be a whole lot more likely to get involved in testing your software -- maybe even helping development; I was a programmer for 30 years before retiring -- if I knew I could put the controller back to a know good state if things go wrong.

I had by now flashed our OpenSource firmware to about 10 units and all of them were read protected. Please read my notes:
- https://opensourceebikefirmware.bitbucket.io/Development_tools--Linux--Step-by-step_tutorial_development_tools--Tools_to_flash_the_firmware.html
- https://opensourceebikefirmware.bitbucket.io/Development_tools--Linux--Step-by-step_tutorial_development_tools--Tools_to_flash_the_firmware--How_to_unlock_protected_read_memory.html

Please join us and help develop technology and knowledge about brushless motors, that are key technology for electric vehicles, and that way you will be helping us working toward a green environment!!

 

[daffy99]

Is your statement that its "not possible" based on having tried and failed?

Read-out protection is an integral part of the STM chip architecture. This is a hardware-based copy protection scheme that no one seems to have been able to overcome so far, using generally available methods.

"Am I able to roll back?" was also the first question I asked, when it came to looking into flashing

 

[casainho]

I had by now flashed our OpenSource firmware to about 10 units and all of them were read protected. Please read my notes:
- https://opensourceebikefirmware.bitbucket.io/Development_tools--Linux--Step-by-step_tutorial_development_tools--Tools_to_flash_the_firmware.html
- https://opensourceebikefirmware.bitbucket.io/Development_tools--Linux--Step-by-step_tutorial_development_tools--Tools_to_flash_the_firmware--How_to_unlock_protected_read_memory.html

And to be clear, I changed the name of that page to: "How to erase and unlock protected read memory" and wrote this note: "Please note that memory will be erased and the original firmware will be lost."

 

[Buk___]

Is your statement that its "not possible" based on having tried and failed?

Read-out protection is an integral part of the STM chip architecture. This is a hardware-based copy protection scheme that no one seems to have been able to overcome so far, using generally available methods.

According to the STM32 ST-LINK utility docs, it can perform a memory checksum, which means IT must be able to read memory; "Compare device
memory with file", again, must be able to read; "Program & Verify…", it needs to read back to verify.

But then, there's nothing worse than an internet learned expert. The ST-LINK is cheap enough, I'll buy one and play, and keep my "expertise" to myself (until I actually have some)

 

[casainho]

According to the STM32 ST-LINK utility docs, it can perform a memory checksum, which means IT must be able to read memory; "Compare device
memory with file", again, must be able to read; "Program & Verify…", it needs to read back to verify.

That will apply while we are developing and debugging and flash memory is not read protected. After the firmware/product goes to production and then flash memory will the read protected to protect the company IP -- read here from an application note of ST.

 

[Alan B]

Most all micros have a protection system to keep the firmware safe from copiers. Once this feature is enabled the ability to read the firmware from outside the chip is lost (until after a complete erasure is done). Companies who value their firmware will enable this protection to keep their intellectual property safe. This will prevent getting a copy of the original firmware to reload later. You can try it of course, but the feature is explicitly designed to prevent exactly this.

 

[Buk___]

3. In terms of hardware, you will need what is listed here: https://opensourceebikefirmware.bitbucket.io/Development_tools--Linux--Step-by-step_tutorial_development_tools--Hardware_tools_to_flash_and_debug_the_firmware.html#h1-2

Are you guys using the £100+ STMICROELECTRONICS - ST-LINK/V2-ISOL - DEBUGGER/PROGRAMMER, STM8, STM32 MCU ST-LINK units, or one of what I assume are clones that can be had for as little as a couple of quid?

(And if you are using/have used a clone, any recommendations for models known to work correctly?)

 

[casainho]

See the notes site, on the page about development tools - I listed there the one I am using as others are aslo using, I think.

 

[casainho]

Yes thats how I found the schematic while searching for that cpu in image search!

Can you please tell:
1. what would be the advantages of that greentime controllers over BMSBattery/Kunteng controllers?
2. what is exactly the reference of the microcontroller?

 

[stancecoke]

I think this is a chinese clone of the Renesas (formerly NEC) D79F9211, sometimes branded as a X8M06, well known from the old KU63 controllers. 44 Pin LQFP package.
https://de.aliexpress.com/item/Elec...ntroller-X8M06-C-Battery-Car/32826350022.html

https://github.com/stancecoke/Param...b/master/related-documents/UPD79F9211-NEC.pdf

There is no cheap programmer available for this processor. I tried to build one on my own some month ago, but I stopped that project.
https://github.com/stancecoke/Parameter-Setting-Tool-for-EBike-Controller

regards
stancecoke

 

[casainho]

I think this is a chinese clone of the Renesas (formerly NEC) D79F9211, sometimes branded as a X8M06, well known from the old KU63 controllers. 44 Pin LQFP package.
https://de.aliexpress.com/item/Elec...ntroller-X8M06-C-Battery-Car/32826350022.html

https://github.com/stancecoke/Param...b/master/related-documents/UPD79F9211-NEC.pdf

There is no cheap programmer available for this processor. I tried to build one on my own some month ago, but I stopped that project.
https://github.com/stancecoke/Parameter-Setting-Tool-for-EBike-Controller

regards
stancecoke

usertogo, so seems that controller is by no way compatible with our firmware, that runs on BMSBattery S series controllers/Kunteng <-- this controllers are also cheap and powerful, I suggest you to buy and use them if you are looking to use our OpenSource firmware.