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

[geofft]

Been trying the last couple of days to install the new firmware using the instructions here:-

https://www.pedelecforum.de/wiki/doku.php?id=elektrotechnikpen_source_firmware_fuer_sxxs_ktxx_-controller

.....but having some issues. Have installed Java, SDCC, C#hrome-B and ST visual dev, all 'seemed' to go ok. Hardware looks ok, I can manually send data from the STV programmer and the leds on ST-link adapter twinkle merrily as it is downloaded to the Kunteng controller. The problem is I can't get the Parameter Configurator to work, it seems to attempt to compile the data but never actually sends to the controller via the ST-link. Looking at the CMD console page afterwards there are lots of errors showing, something in my software installation is clearly not in the right place.

I've attached a copy of the CMD console output page (after attempting to run the Parameter Configurator), perhaps one of you guys could take a look and see if you have any ideas, I seem to have run out of these.....

 

[casainho]

Been trying the last couple of days to install the new firmware using the instructions here:-

https://www.pedelecforum.de/wiki/doku.php?id=elektrotechnikpen_source_firmware_fuer_sxxs_ktxx_-controller

.....but having some issues. Have installed Java, SDCC, C#hrome-B and ST visual dev, all 'seemed' to go ok. Hardware looks ok, I can manually send data from the STV programmer and the leds on ST-link adapter twinkle merrily as it is downloaded to the Kunteng controller. The problem is I can't get the Parameter Configurator to work, it seems to attempt to compile the data but never actually sends to the controller via the ST-link. Looking at the CMD console page afterwards there are lots of errors showing, something in my software installation is clearly not in the right place.

I've attached a copy of the CMD console output page (after attempting to run the Parameter Configurator), perhaps one of you guys could take a look and see if you have any ideas, I seem to have run out of these.....

Hi Geofff.
Great that you want to use our firmware. I am here ready to help you.

That instructions were written by Stancecoke. He uses Windows to build and flash the firmware while I am using Linux and that is why he may be the best person to help you. But meanwhile, let's see if I can help you.

1. Seems that you can flash correctly the firmware on STM8 and the mainly issue is failing to build the firmware
2. On this stage, I am not using the Java tool Parameter Configurator but instead choosing by hand the options on main.h file. Can you please tell what is our hardware, battery pack number of cells/bat voltage, which motor, which motor controller, throttle/PAS/torque sensor, LCD?? -- I can then advice you for the options on the main.h.
Maybe it is the same as you did describe here.
3. Please read the Linux instructions so that you can have an overview of the steps needed to build and flash firmware - should help you understand for WIndows and test/debug build the firmware, to resolve your issue.
4. Os the last days I improved the PAS and throttle code, please make sure you are building the latest code from the github on this link: https://github.com/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware

 

[stancecoke]

Which branch have you used?

there are two bugs:
1. you have to edit the path to the STVP_CmdLine.exe in the start_compiling.bat (just open the Start_Compiling.bat file with any editor, or rightclick-->edit) and change the first line to

PATH = %PATH%;C:\Program Files (x86)\STMicroelectronics\st_toolset\stvp

To use the "write optionbytes" button (to disable the read/write protection) you have to do the same with the WriteOptionBytes.bat.

2. an error in line 225 of the display.c. Please select the Kingmeter-J-LCD Option in the Java Tool, that should work. It doesn't matter if you don't connect a display.

But remember, the Java-Tool will only work with the "torque-simulation" branch. If you want to use casainhos latest code, you can just double-click on the Start_Compiling.bat, after downloading and extracting the "master" branch and editing the first line.

regards
stancecoke

 

[geofft]

Thanks for your help guys, much appreciated.
My brain is past its best tonight, will check out all your suggestions tomorrow and let you know.

 

[stancecoke]

I've just updated the torque-simulation branch, now the option display-->none in the Javatool works without errors. The path to the flashtool in the batch files is set to the default value now, also.
@geofft: the torque-simulation branch should work for you now, without any changes.

regards
stancecoke

 

[casainho]

geofft, please post some pictures of your ebike when you have it running

 

[geofft]

I've just updated the torque-simulation branch, now the option display-->none in the Javatool works without errors. The path to the flashtool in the batch files is set to the default value now, also.
@geofft: the torque-simulation branch should work for you now, without any changes.

....I've just downloaded and installed your revised files and pleased to say all now looks good and the data is being sent to the controller via the ST-link. Just a couple of small questions:-

1) The CMD screen output still shows some 'could not find' etc errors. I'm guessing that this is normal but could you just confirm, I've attached a copy of the cmd screen below.

2) The data transfer to the controller happens very quickly, taking just 2-3 seconds. Is that ok, seems very quick..!

....all probably me worrying unneccessarily (as usual). Once again many thanks for your help.

Casainho: No problem with photos, will post later this week.

Geoff.

 

[casainho]

2) The data transfer to the controller happens very quickly, taking just 2-3 seconds. Is that ok, seems very quick..!

Yes, should be that quick. And the log messages indicates that everything went well.

When you get the motor running ok as you expect, please report

 

[casainho]

Stancecoke, can you please explain what is the sequence of "cheat mode"? I could understand it uses only brakes. It is always running trying to "read the cheat code" or just once after startup?

Did you thought in a way to give feedback to user that "cheat mode" is enable?

 

[stancecoke]

pleased to say all now looks good

Congratulation!

Stancecoke, can you please explain what is the sequence of "cheat mode"? ... It is always running trying to "read the cheat code" or just once after startup?

The cheat function is described in the german wiki, here a revised translation:

Cheat-time 1: Is the first duration of the "Morse code" in 1 / 50s. The value 50 thus means one second. The cheat works like this: Hold brake lever for cheat-time 1, then release for cheat-time 2, then pull again for cheat-time 3, then release again. In each step there is a tolerance period of half a second, this means for step 1, with value 50, the release of the brake lever is recognized as valid in the period of 1 to 1.5 seconds after the pulling and continues with step 2. If the lever is released too early or too late, the complete procedure is reset and you have to start from the beginning. Currently, the user gets no feedback on whether the cheat has been activated.

Cheat-time 2 and cheat-time 3: see cheat-time 1

With each valid change of the break state the value of ui8_cheat_state is incremented. If ui8_cheat_state reaches the value "4", the speed limiting function gets disabled until the restart of the whole system.

The break lever state is checked every slow loop run in the main.c as long as the ui8_cheat_state != 4 . So you can do the cheat when ever you want.
I thought about giving the rider a feedback of sucessful disabling the speedlimit by e.g. sending a speedvalue of 99km/h to the display for two seconds, but I haven't done it yet...

regards
stancecoke

 

[casainho]

The break lever state is checked every slow loop run in the main.c as long as the ui8_cheat_state != 4 . So you can do the cheat when ever you want.
I thought about giving the rider a feedback of sucessful disabling the speedlimit by e.g. sending a speedvalue of 99km/h to the display for two seconds, but I haven't done it yet...

I am thinking in implementing this feature, as I think it is distinctive and seems popular as you told before.
In future, with the mobile, we can enable/disable the feature in realtime. Now that the firmware is more or less finished, my version uses 27kbytes (and 20kbytes with compiler optimizations enabled, although not tested), so I think we have some space to have optional features during run time of firmware.

1. I am thinking that I would prefer to read the cheat code only once at startup because other way it can be erratically typed by the user
2. For feedback, I think is also important due to safety. I was thinking in using ebrake LCD signal, and invert the signal while on cheat mode. When user is typing the cheap mode, will see the brake signal on LCD working as expected and start working inversely after entering correctly on cheat mode. This way would be a persistent feedback.

What do you think?

 

[1N4001]

Very nice summary in the starting post, Casa. I applaud your efforts at making this project accessible!

The phone app also looks very nice. Will it be open-source aswell?

I would suggest using BLE to reduce phone battery drain. Also please make sure that the connection to the phone is authenticated and encrypted, afaik the BMSBattery isn't and anybody can watch or modify settings.

And one final question, do you know, or can you estimate the max commutation frequency of this firmware? Also called eRPM

 

[stancecoke]

the max commutation frequency of this firmware?

We discussed that in the german forum already, the maximum erps are set to 520 at the moment, so the maximum erpm are 60*520=31200.

regards
stancecoke

 

[casainho]

Very nice summary in the starting post, Casa. I applaud your efforts at making this project accessible!

The phone app also looks very nice. Will it be open-source aswell?

I would suggest using BLE to reduce phone battery drain. Also please make sure that the connection to the phone is authenticated and encrypted, afaik the BMSBattery isn't and anybody can watch or modify settings.

And one final question, do you know, or can you estimate the max commutation frequency of this firmware? Also called eRPM

Thank you for the feedback.
1. Will be OpenSource. I want to collaborate on OpenSource projects because of my mission, I want to help getting a greener environment.
2. I will not build/develop hardware or physical product so I will use what works well, is widely available and cheap.
3. About encryption, we also had that issue on electric unicycle boards. Wouldn't be ok to use a custom Bleutooth pair pin?
4. As Stancecoke already told:

#define MOTOR_OVER_SPEED_ERPS 520 // motor max speed, protection max value | 30 points for the sinewave at max speed

The original firmware does a MAX ERPS similar value. Also Lishui controller we tested, did fail to work at lower MAX ERPS value than that.

 

[1N4001]

We discussed that in the german forum already, the maximum erps are set to 520 at the moment, so the maximum erpm are 60*520=31200.

Whoops, you're right, I completely forgot about that :lol:

Thanks for your answers, Casa.

3. About encryption, we also had that issue on electric unicycle boards. Wouldn't be ok to use a custom Bleutooth pair pin?

From what I understand, once you're paired, communication is encrypted. The pairing pin is only used during the initial key exchange. The cheap BT apps don't pair at all, but simply send data packets out in the open.

 

[casainho]

From what I understand, once you're paired, communication is encrypted. The pairing pin is only used during the initial key exchange. The cheap BT apps don't pair at all, but simply send data packets out in the open.

Must say I am not motivated to research about this topic. A google search pointed me to some pages that mention encryption: https://www.itead.cc/wiki/Serial_Port_Bluetooth_Module_(Master/Slave)_:_HC-05

I Davis wrote 02/17/2016 at 07:06

Here are a couple that I used with my HC-05:

AT+SENM=3,2 Full Encryption.
This sets the HC-05 module to use full encryption. My phone can connect using a secure connection, but it seems that my Nook HD+ can only use the non-secure connection.

Param1 - 3----sec_mode3_link

Param2 - 2----hci_enc_mode_pt_to_pt_and_bcast

And to make the HC-05 take the settings:

AT+INIT

https://hackaday.io/project/9276-hc-05-hc-06-bluetooth-notes/discussion-47862

 

[stancecoke]

@geofft: I just tested my latest commit in hardware, for some reason, the option display-->none doesn't work, please choose the option display-->kingmeter J-LCD.

Edit: I checked it again, it works I just connected my UART-USB-converter to a wrong pin
So you can use the display-->none option.

regards
stancecoke

 

[geofft]

@geofft: I just tested my latest commit in hardware, for some reason, the option display-->none doesn't work, please choose the option display-->kingmeter J-LCD.

Edit: I checked it again, it works I just connected my UART-USB-converter to a wrong pin
So you can use the display-->none option.

Ok, thanks. I'm using a BMS LCD3 display so I guess the Kingmeter j-lcd display option is the most suitable.

I've been trying out your firmware for a short time on the road today, I've a few early observations, will give some more detail when I get a bit more time.
Geoff.

 

[stancecoke]

1. I am thinking that I would prefer to read the cheat code only once at startup because other way it can be erratically typed by the user

Hmm, I'm not afraid, that the user get in trouble. I had to excercise several times to find the right rhythm to activate the cheat. And even if the cheat is activated unintended, there's no danger for the rider.... (OK, perhaps the danger of a big grin in the face )

I was thinking in using ebrake LCD signal, and invert the signal while on cheat mode.

OK, that may work, but I would prefer just a short acknowledgement of the controller.

I'm using a BMS LCD3 display

The LCD3 doesn't work with the recent "torque-simulation"-branch.

I've been trying out your firmware for a short time on the road today

That sounds as the motor ran at least :wink:

regards
stancecoke

 

[casainho]

I'm using a BMS LCD3 display

The LCD3 doesn't work with the recent "torque-simulation"-branch.

Geoffft, this firmware have LCD3 and LCD5 working. For LCD3, I even found 2 different versions and had to make some relevante changes to work with both. I am adopting BMSBattery components, I being developing and testing with them.

    // see if CRC is ok
    if (((ui8_crc ^ 10) == ui8_rx_buffer [7]) 	|| // some versions of CRC LCD5 (??)
	((ui8_crc ^ 9) == ui8_rx_buffer [7]) 	|| // CRC LCD5
	((ui8_crc ^ 2) == ui8_rx_buffer [7])) 	   // CRC LCD3

 

[geofft]

Geoffft, this firmware have LCD3 and LCD5 working. For LCD3, I even found 2 different versions and had to make some relevante changes to work with both. I am adopting BMSBattery components, I being developing and testing with them.

Ok, thanks. I'm playing with stancecoke's firmware just now but will definitely be giving that a try next, I'll let you know how it goes... :wink:

 

[geofft]

I've been trying out your firmware for a short time on the road today, I've a few early observations, will give some more detail when I get a bit more time.
Geoff.

Stancecoke, a bit more info on what I found today with the Torque Simulation firmware branch. My setup is Q128H, S06S, SLCD3, 48v 12s lipo. I'm using the PSWpower version of the S06S, this is very similar to the BMS version and seems to operate in exactly the same way. I tried three of the four modes:-

Ride Mode Throttle.
This worked very well, noticed some oscillation in motor assist during acceleration but once up to speed was smooth and quiet.

Throttle and PAS
This not so good - motor gave no response to either throttle or PAS input. Whilst trying smelt something burning and realised controller was seriously hot and hit the battery switch before any damage done, definitely something not right here. A bit of a disappointment as this is the mode I normally like to ride.

Torque Simulation
This mode worked but with some rather fierce and alarming motor surges. These happened 1) At initial switch on from the SLCD3, 2) If pedals rotated even slightly backwards, 3) If the cycle was pushed backwards. These surges were quite short (around 1 sec duration) but were powerful and could pull the bike from your hands if you weren't expecting them. When finally out on the road however it worked well, and the torque simulation feature built the motor power up in a pleasantly gradual manner as you increased cadence.

Didn't try the Torque Sensor mode as I don't have one fitted.

...so a bit of a mixed bag, some good, some not so good. Obviously early days though and shows great promise but clearly needs a little more developement and testing, which I'm sure is what you expected....

 

[casainho]

You really need go with my firmware as you seem to mention issues that seem potential deadly to your controller and that I improved already and I think Stancecoke version lacks behind:
- some small issues on the motor controller, like on startup and while accelerating
- motor protection to avoid being stuck and powered
- PAS and throttle works well with PAS detection of backward pedals rotation

And I am using almost the same components as you: Q85, 24v battery, LCD3 and S06S. I can fast help you getting a main.h file for your hardware configuration.

 

[KingQueenWong]

MCU：STM32F103C8T6
OP：LM324
MOSFET：FBM100N80
DRIVER：FAN7842
LINK：https://detail.1688.com/offer/559010270938.html?spm=a360q.9889319.0.0.B5qtH0
LINK：http://www.nerch.xin/

 

[stancecoke]

Stancecoke, a bit more info on what I found today with the Torque Simulation firmware branch.

Thank you for your feedback! I think that's a great success!
It took me several days/weeks to get the motor turning the first time, you did it at just one day .

Due to the missing direction detection it's normal, that the motor starts running forewards if you push your bike backwards. In torque-sensor-mode this will be no problem, as the motor power will be zero as long as the torque is zero.
The only strange thing is the THROTTLE+PAS behaviour. In this mode, the motor should behave in the same way as in THROTTLE mode, the only difference is, that the motor should stop, if you are not pedaling. I never tried that mode on the street.

I think Stancecoke version lacks behind

That's right for some safety issues and the direction detection, but it's miles in front in easy and intuitive usage and in documentation/parameter explanation.

We should work on that, if you put all user relevant parameters in the config.h I can update the Javatool for the master branch, as I have offered before.

regards
stancecoke