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

[stancecoke]

I'm probably doing something dumb but I've run out of things to try, any ideas?

I fear there is too much noise on the signal when the motor is running. You can try to fit a split ferrite to the wire next to the controller. I could filter the signal by software, but to be honest, I have no desire to do that :wink:

You can try a normal speedometer sensor also.

regards
stancecoke

 

[geofft]

I'm probably doing something dumb but I've run out of things to try, any ideas?

I fear there is too much noise on the signal when the motor is running. You can try to fit a split ferrite to the wire next to the controller. I could filter the signal by software, but to be honest, I have no desire to do that :wink:

Ok, thanks, that sounds like a very likely explanation.

I think I'll just get an external sensor and give that a try sometime.

 

[apple2]

I have tried to run my motor today - 48v 1000w DD off ebay.
Used the stancecoke firmware off github and managed to compile and flash fine.
Hall and phase wires confirmed to work fine with the stock firmware beforehand.
Controller is 72v 3000w 18fet.
The problem is it runs rough and takes a lot of current.
I tried changing MOTOR_ROTOR_DELTA_PHASE_ANGLE_RIGHT to 250, 220, 180, 100 but I didn't notice much difference.
Initially I used a DC-DC supply because its current limited but when it starts rotating the voltage drops and I see "Low Voltage!" error in the serial stream. Then tried 18s lipo with a 3A fuse and limited "ui16_setpoint" to 25max value. The motor rotates slowly and doesn't blow the fuse.
Has anybody tried running this on 48v 1000w ebay motor or the 18fet controller?
Which parameters should I try to optimise? I have access to an oscilloscope if needed.

 

[Demion]

Sorry, if not exactly on topic.
I have KT48ZWSRMT-LCD-C&D and LED 880. Between LED and controller I connected arduino.
Protocol controller -> LCD (LED) is same, except there is no last 3 bytes (no moving mode, current, temperature);
Protocol LCD (LED) -> controller is same, except 7 bytes and last byte 0x0E (no C settings);
[0] 0C [1] 03 [2] F5 [3] 56 [4] 28 [5] 88 [6] 0E
I tried send LCD3 format, but controller does not answer.
I want to make my own "LCD" on arduino to be able change controller settings and display data over wifi (esp8266).

Update: after using search I guess this is different controller (with no current / temp sensors, as I understand), and sorted out protocol (it is the same, but not complete).

Update2: Code is working fine now with LCD3 protocol (full) as well. Seems like I messed something up first time. Might be useful for someone. By the way controller is sending current (not sure if it is correct) and last rx 2 bytes are 0x80 and 0x23 not 0x00 for my controller.

Spoiler: code

txBuffer[0] = P5;
txBuffer[1] = assistLevel & 0x07;
txBuffer[2] = (((maxSpeed - 10) << 3) & 0xF8) | ((wheelSize >> 2) & 0x07);
txBuffer[4] = ((wheelSize << 6) & 0xC0) | ((maxSpeed - 10) & 0x20) | (P2 & 0x07) | ((P3 << 3) & 0x08) | ((P4 << 4) & 0x10);
txBuffer[3] = P1;
txBuffer[6] = (C2 & 0x07) | ((C1 << 3) & 0x38);
txBuffer[7] = (C5 & 0x0F) | ((C14 << 5) & 0x60);
txBuffer[8] = (C4 << 5) & 0xE0;
txBuffer[9] = C12 & 0x0F;
txBuffer[10] = (C13 << 2) & 0x1C;
txBuffer[11] = 0x32;
txBuffer[12] = 0x0E;

txBuffer[5] = 0;
      
uint8_t crc = 0x02;
      
for (int i = 0; i < 13; ++i)
	crc ^= txBuffer[i];
      
txBuffer[5] = crc;
      
for (int i = 0; i < 13; ++i)
	txSerial.write(txBuffer[i]);
          
batteryLevel = rxBuffer[1];
controllerVoltage = rxBuffer[2];
wheelPeriod = rxBuffer[3] * 256 + rxBuffer[4];
errorCode = rxBuffer[5];
movingMode = rxBuffer[7];
current = rxBuffer[8] * 4;
temperature = (int8_t) rxBuffer[9] + 15;

 

[stancecoke]

Hall and phase wires confirmed to work fine with the stock firmware beforehand.
...
The problem is it runs rough and takes a lot of current.

That was my latest experience, too. You have to swap the wires againg, to make the motor run properly. I added this hint in the FAQ and the tutorial some time ago.

Please make sure to find out the correct phase and Hall sensor assignment on the complete system with the original firmware before deleting. This makes sure, that the controller and the motor work together in principle. Still it can be necessary to swap the wires after flashing the firmware to a different combination. If the motor doesn't start properly with the custom firmware (turns not or only very slowly with noise and high current) try to find the right combination by trial and error.

Please try again to find the right wire assignment!

Good luck!

stancecoke

 

[casainho]

I hope I can use your solution for reading motor temperature and limit it. I just burned my TSDZ2 motor/desmagentized loose torque forever:

My motor did BURN

For the guys that got theirs motors to much hot up to the point that the motor stops for some minutes, did you found after that your motor did loose for ever torque??

No, in my experience if the motor cuts off due to high temps it comes back fine...

So, yesterday I got for the first time the high temperature cut-off of the motor while I was trying to discharge fully my battery and fast so the motor current was almost always over 15 amps.
Today I went to do another battery pack fully discharged and I noted that my motor was asking the same power as 900 watts but it was lacking some force/torque!! After some comparison with other ebike running with same TSDZ2, I found that my motor wasn't working properly and so I decided to open it:





So as we can see, some of the motor phase wires insulation seems that got very hot as also the motor metal parts are clear with a more dark/brown color. I would say the temperature was at least 100 degrees. And I think the magnets inside that motor did suffer some expressive demagnetization and so the loss of the motor torque forever. Here what I found only about this subject:

The Curie temperature of high-grade Neodymium (with added terbium and dysprosium) is 320C / 600F. However, common neo magnets are made from the cheapest grade, and can start to lose some of their magnetism at around 80C (170F).

E-bike motor magnets are a grade that is slightly higher than the cheapest variety, because they are often subjected to higher temps than they should be by unsuspecting customers. Years of posted experiments by real E-bikers on endless-sphere have produced a commonly held rule-of-thumb to avoid heating your E-bike motor to above 95C (200F).

https://www.electricbike.com/motor-tech-learn-the-terms-part-1/

Next I went and exchanged the motor for a new one I had in stock and I got back the full torque of TSDZ2!!!!

So, my question is: how can we avoid motor heating TSDZ2 motor over like 80C to avoid losing forever motor torque/demagnetize the motor magnets??

 

[-dg]

I added CRC16 and went to test with a few rides - now I don't get corrupted data on LCD3 (I mean, it should be ignored and LCD3 is working very well as expected).

Interesting. Could you do an experiment? Create a variable to count total packets and error packet and then try different bit rates?

In other news, I have got the stancecoke tree to build although without debug info. And I have set up to flash the stm8 mini dev board. Some issues as while it appeared to flash the code (not mine yet) is not communicating back. I think this may be my serial hardware, so I'll try some other things this weekend. Once I've got this working I'll take a shot at adding the header to a controller.

 

[stancecoke]

In other news, I have got the stancecoke tree to build although without debug info.

You can try the 3.7.1 sdcc release, with windows, it builds our firmware even with debug infos.
https://sourceforge.net/projects/sdcc/files/snapshot_builds/

regards
stancecoke

 

[-dg]

You can try the 3.7.1 sdcc release, with windows, it builds our firmware even with debug infos.
https://sourceforge.net/projects/sdcc/files/snapshot_builds/

I would rather fix sdcc all by myself than use windows. I've been using GNU/Linux since 1994 and other Unixes since 1988.

Besides which I tried it even with the latest nightly snapshot of sdcc and it was the same. Sdcc developer replied to my bug that it was generating bad debug info. Hmmm, does windows use a different debug info format?

I'm still looking at some other stuff but will have time later this week to investigate this. I'll try to just chop out parts until I get a small test case for the sdcc devs.It's curious that it builds casainhos repos without trouble. Maybe there is something different in yours that it gets wrong.

 

[stancecoke]

Oh, sorry for the confusion. I just tried it with my recent fork. It doesn't compile with debug info. I tried with casainhos TSDZ2 code,that worked. So no difference between windows and linux behavior.

But I think Casainho gave the important hint already:

There is an important issue: we can't use static variables with initial values, liker 5 for instance, other way compilation fails. Because of this I am using a lot of global variables and this makes the code hard to read/understand.

regards
stancecoke

 

[-dg]

Oh, sorry for the confusion. I just tried it with my recent fork. It doesn't compile with debug info. I tried with casainhos TSDZ2 code,that worked. So no difference between windows and linux behavior.

But I think Casainho gave the important hint already:

There is an important issue: we can't use static variables with initial values, liker 5 for instance, other way compilation fails. Because of this I am using a lot of global variables and this makes the code hard to read/understand.

Thanks for the update. Good to know it's not a windows vs linux issue. I'll have more time to look at this later this week. I have got flashing my stm8s minimal dev board working. Now I need to see how to debug.

I'm not sure about the statics thing being the cause, but it's certainly worth testing. I'll check that out.

 

[stancecoke]

We have a new successful user at the german pedelecforum. He added the settings for a Cute 100 C. 8)

https://github.com/stancecoke/BMSBattery_S_controllers_firmware

regards
stancecoke

 

[Mavabo]

Hello Stancecoke, you wrote:

Please try the older commit:
https://github.com/stancecoke/BMSBatter ... a40e4b.zip

I have to check it in THROTTLE_AND_PAS mode in the recent code.

I did what you suggested but this older commit didn't give me any support at all! So I downloaded the latest commit (changed 15 hours ago)
and now my digital brake is constant on until I switch it off in the configurator. My Cadillac doesn't run anymore. Should I change something in my config.h?View attachment config.h

 

[geofft]

I'm also getting the issue of the bike pushing forward slightly when at rest with the Torque simulation mode.
Seems to be worse at initial switch on, strangely the problem seems to correct after it's been ridden for a while. You have to be careful pushing backwards at switch on too, this occasionally causes the motor to drive forwards quite strongly.

 

[stancecoke]

and now my digital brake is constant on until I switch it off in the configurator.

What do you mean with "contant on"??? You should set the phase current to a much higher value, like geofft did. And test in "Throttle" mode first, to avoid faults of PAS or direction detection.

I'm also getting the issue of the bike pushing forward slightly when at rest with the Torque simulation mode.

We could put a higher offset to the auto-zero-value, but then a direct drive will brake a little if it should coast. It would be great, if one of you could try the USB-UART-Converter to have a look at the parameters at runtime in diagnostics mode.
Without that I have no chance to see what's going on in your controllers...

regards
stancecoke

 

[geofft]

I'm also getting the issue of the bike pushing forward slightly when at rest with the Torque simulation mode.

We could put a higher offset to the auto-zero-value, but then a direct drive will brake a little if it should coast. It would be great, if one of you could try the USB-UART-Converter to have a look at the parameters at runtime in diagnostics mode.
Without that I have no chance to see what's going on in your controllers...

Ok, I'm happy to do that, will get one ordered. You'll probably have to give me a little instruction on how to connect/operate it though, I don't think I'm clever enough to work it out for myself...

In the meantime is there something within the code that maybe we can change to play with the auto-zero?

 

[geofft]

Looking at the converter you linked to here:-

https://www.ebay.com/itm/USB-To-RS2...5.m570.l1311.R3.TR6.TRC1.A0.H0.Xusb-uart.TRS0

....it seems that there maybe some problems using this with the latest win 10 drivers. The advice (for win 10) seems to be use one of these instead:-

https://www.ebay.co.uk/itm/1PCS-6Pi...103524?hash=item2ca45cc264:g:sIQAAOSwYHxWQubk

...would that be ok for our purposes?

 

[stancecoke]

Ok, I'm happy to do that, will get one ordered. You'll probably have to give me a little instruction on how to connect/operate it though, I don't think I'm clever enough to work it out for myself...

I will write a tutorial for both, USB-UART converter with PC/Laptop and BT-Module with smartphone...

In the meantime is there something within the code that maybe we can change to play with the auto-zero?

It's the adc_init procedure in the adc.c

  ui16_current_cal_b >>= 4;
  ui16_current_cal_b -= 1;
  printf("ui16_current_cal_b = %d\r\n", ui16_current_cal_b);

You can try

  ui16_current_cal_b -= 3;

or even more than 3 to avoid the motor pushing slightly at standstill.

https://www.ebay.co.uk/itm/1PCS-6Pi...103524?hash=item2ca45cc264:g:sIQAAOSwYHxWQubk

...would that be ok for our purposes?

Yes, that should work also.
You can think about using the BT-module/Smartphone for logging, this has the advantage, that you get data from real rides. With PC/Laptop it's more difficult....

regards
stancecoke

 

[-dg]

We could put a higher offset to the auto-zero-value, but then a direct drive will brake a little if it should coast. It would be great, if one of you could try the USB-UART-Converter to have a look at the parameters at runtime in diagnostics mode.
Without that I have no chance to see what's going on in your controllers...

This sort of investigation and tuning is exactly what I hope to enable with the Modbus implementation. It will still require the USB-UART converter, but should make it possible to explore and modify the controller state at while it is running without needing to build extra debug printfs into the firmware.

USB-Serial converters are only a couple dollars from Aliexpress as are ST-Link dongles. I wonder if we want to add a little shopping list to the project with links to suitable dongles, cables and connectors?

 

[geofft]

stancecoke:
You can think about using the BT-module/Smartphone for logging, this has the advantage, that you get data from real rides. With PC/Laptop it's more difficult....

Ok, that sounds like a more elegant method (until -dg does his magic.... 8) ) I'll probably give that a go.

I'll wait for your tutorial on this first though. As always, no hurry... :wink:

 

[casainho]

You have to be careful pushing backwards at switch on too, this occasionally causes the motor to drive forwards quite strongly.

I also have this issue with TSDZ2 so if you guys find the problem origin, that will be great.
And on TSDZ2 I simple did remove the code about regen.

I guess that is because running the motor backwards will increase battery voltage...

Maybe the firmware needs more state machines, like for disable PWM when the motor is supposed to be stopped (when no throttle and PAS).

Also, I am using the Android app to log that Stancecoke did recomend and works very well for what we need.

Also I agree that sending some specific command to receive specific data, like for logging on debug, would be good. However, myself, I have other priorities.

 

[stancecoke]

You have to be careful pushing backwards at switch on too, this occasionally causes the motor to drive forwards quite strongly.

can you try if changing

uint8_t PAS_act=3;			//recent PAS direction reading

to

uint8_t PAS_act=0;			//recent PAS direction reading

in the main.c fixes this problem? It never occured at my bike, so I can't check it...

regards
stancecoke

 

[geofft]

It's the adc_init procedure in the adc.c

  ui16_current_cal_b >>= 4;
  ui16_current_cal_b -= 1;
  printf("ui16_current_cal_b = %d\r\n", ui16_current_cal_b);

You can try

  ui16_current_cal_b -= 3;

or even more than 3 to avoid the motor pushing slightly at standstill.

Changing this value from 1 > 3 definitely removed problem with pushing forward at rest and also the bike resisted less being pushed in reverse. This also seemed to reduce (but not completely remove) the tendency to suddenly drive forward when being reversed. Maybe this would help Mavabo with his original problem..?

You have to be careful pushing backwards at switch on too, this occasionally causes the motor to drive forwards quite strongly.

can you try if changing

uint8_t PAS_act=3;			//recent PAS direction reading

to

uint8_t PAS_act=0;			//recent PAS direction reading

in the main.c fixes this problem? It never occured at my bike, so I can't check it...

The driving forward when being reversed issue is unfortunately very inconsistent in its nature, this makes things like this rather difficult to assess. The best I can say (after much testing) is that the problem seems to happen more after switch on and pas has been activated, but I *think* the change you mention above doesn't help with this issue. Sorry I can't be more specific but I don't want to give you guys bad information.

It definitely feels like it's regen related, it only seems to happen when the bike is resisting being reversed, as if regen has got rather over zealous. As I said though, it's seems to be reduced with the other change (above) so it's not really a big issue.

 

[stancecoke]

I'll wait for your tutorial on this first though. As always, no hurry... :wink:

I've added the tutorial now 8)
https://opensourceebikefirmware.bitbucket.io/windows_instructions/index6.html

I hope it is detailed enough, as it's just a "quick and dirty" document.

regards
stancecoke

 

[geofft]

I've added the tutorial now 8)
https://opensourceebikefirmware.bitbuck ... ndex6.html

I hope it is detailed enough, as it's just a "quick and dirty" document.

Nice work, BT HC-05 module ordered. It's great that we can play with these wonderful little gadgets these days for so little cost...