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

Jatem said:
I'd like to get rid of the fork judder at medium speeds and medium PAS levels.
sorry, in this case, the firmware can't help, as it's a known problem of the capacitors used in the KT controllers. The combination of the motorcoil inductance and the capacitance in the controller seems to lead to a resonance issue, that can't be solved by software.


Powerhour said:
King meter lcd is supported?
Protocols of J-LCD and KM5S are implemented, but only J-LCD is really tested.

regards
stancecoke
 
How would I wire up a torque sensing BB? I have been trying to look through the code, but have been unable to figure out which pins are used for torque sensing and direction.

EDIT: looking back, it seems like I won't be able to connect both a torque sensing BB and a throttle, is that correct?

@stancecoke
Could X4 be used in place of the throttle wire? Or is that a digital input?
 
cnrd said:
Could X4 be used in place of the throttle wire? Or is that a digital input?
You can use x4 for the torque signal, if you want to use the throttle in parallel.
We discussed that in the german forum just a few days ago, I added the information about the wiring to the german forum.
https://www.pedelecforum.de/wiki/doku.php?id=elektrotechnik:eek:pen_source_firmware_fuer_sxxs_ktxx_-controller:drehmomentsensoreinbindung

The function is not implemented in the code yet. But it is very easy to do. I made the offer to publish a "quick-and-dirty" solution in an extra branch, if someone asks for it seriously.

regards
stancecoke
 
stancecoke said:
cnrd said:
Could X4 be used in place of the throttle wire? Or is that a digital input?
You can use x4 for the torque signal, if you want to use the throttle in parallel.
We discussed that in the german forum just a few days ago, I added the information about the wiring to the german forum.
https://www.pedelecforum.de/wiki/doku.php?id=elektrotechnik:eek:pen_source_firmware_fuer_sxxs_ktxx_-controller:drehmomentsensoreinbindung

The function is not implemented in the code yet. But it is very easy to do. I made the offer to publish a "quick-and-dirty" solution in an extra branch, if someone asks for it seriously.

regards
stancecoke

Thanks for the reply, do you know if there are any unused digital inputs that could be used for the direction sensing on Sempu cranks?

Also do you know of any unused outputs? I was thinking of implementing a brake light, such that when the brakes are engaged the controller could be used to signal a brake light (using a relay).
 
stancecoke said:
Jatem said:
I'd like to get rid of the fork judder at medium speeds and medium PAS levels.
sorry, in this case, the firmware can't help, as it's a known problem of the capacitors used in the KT controllers. The combination of the motorcoil inductance and the capacitance in the controller seems to lead to a resonance issue, that can't be solved by software.
Thanks for your reply stancecoke.
Has anyone tried changing the capacitors to solve the resonance issue?
 
hi


im new in this

im trying to use wheels from Hoverboard 36V 350 w and the LCD in picture with KT controller 36v/48v 500w

any one can help with the right firmware config or the modifications a must do

i tryed a standard firmware but nothing work

https://drive.google.com/open?id=1HG8kauvawg-b7qZj52X1hNOfF0PMJb0F

lcd https://drive.google.com/open?id=1HG8kauvawg-b7qZj52X1hNOfF0PMJb0F
https://drive.google.com/open?id=1iJgnssPR02rI9b0T2uXmQb_DJjDwE9t3
https://drive.google.com/open?id=15yFaFOoUGSVvPio65c8ejF-37j5gmzqD
 
Powerhour said:
King meter lcd is supported?
stancecoke said:
Protocols of J-LCD and KM5S are implemented, but only J-LCD is really tested.

regards
stancecoke

Thanks for your reply stancecoke
What the worst that would happen if I tried a different king meter LCD that wasn't fully compatible? Would the LCD settings mess with the firmware? Or could I safely use it as a dummy display for speed and battery life, ignoring the rest?
Thanks
 
Powerhour said:
Powerhour said:
King meter lcd is supported?
stancecoke said:
Protocols of J-LCD and KM5S are implemented, but only J-LCD is really tested.

regards
stancecoke

Thanks for your reply stancecoke
What the worst that would happen if I tried a different king meter LCD that wasn't fully compatible? Would the LCD settings mess with the firmware? Or could I safely use it as a dummy display for speed and battery life, ignoring the rest?
Thanks

I read further and realize I need a supported LCD. All good. One other thing though, do I hook the throttle or the torque sensor to X4? maybe because they're in parallel this doesn't matter?
 
I would suggest to connect the torque-signal to X4, as the plug of the throttle may fit to the controller as it is...

regards
stancecoke
 
Hi all,
does someone know if this controller is compatible with the open source firmware?
https://www.aliexpress.com/item/32972931563.html?spm=2114.12010612.8148356.6.3ed9628f3S4Fh0

I've a rear hub bafang 500w motor. Do you suggest this controller or the 1000W version?

Thanks
 
stancecoke said:
atkforever said:
So I bought a KT 6 mosfets controller

Powerhour said:
Is there anyway to use some kind of physical control switch for changing PAS levels with the android app, without an LCD3 or compatable dashboard connected?
Not yet, we'll wait for your reports :)

Doesn't seem likely possible as far (as I can tell) without the source files of the apk. So I'm just building the LCD3 pcb right into my phone mount and I'll run both at once this way to achieve button control 😁
 
Aeron said:
Aeron said:
I have quite the same question but the other way around : I have a 36/48V version, but I want to run it at 52V.
The FETs and caps were changed to their 80V counterparts to accomodate higher voltage (and I am thinking about changing the LM317 regulator*), but is there any hardware modification to make this controller work with 14S battery ? (voltage limits or other)

*edit : original LM317T replaced by TL783CKCSE3.

Noone knows ?

For the sake of documentation. I did this with one Pswpower from 2014 or so, but blew up my controller. I failed to determine the reason. But I did the same now with a pswpower from 2018 late, and the design is very much changed. All caps except one is ok for up to 63v. I just changed one next to the lm317 to a 63v rate, mosfets (csd19506kcs), and replaced lm317 with a lm317ahv variant. I did not have time to test it properly but with stock firmware and a battety charge at 57v, seems to pull up fine up to 1kw. I want to change the lm317 with a switching psu, but this time I wanted minimal risk.

I will report how is the low voltage working etc. Again with stock firmware.

Guys, what is the best 6fet controller for this firmware? I saw you were discussing about one type with phase current sensor, and so.
 
Hi, I had a look through this thread, but couldn't find a good answer to this question.

Does anyone know what the best 18 FET controller (~2Kw) that is available? Had a look around the usual sources, and can only seem to find the ZWS models without sensor.

Thanks in advance
 
@Xnyle,

I've just tested your 'X4 throttle' branch and can confirm that, for me, it works faultlessly. Certainly better than my cobbled up torquesensor and throttle wired in parallel method...

This Torquesensor with throttle override option is perfect for my needs, many thanks for your efforts.
 
c0m47053 said:
Does anyone know what the best 18 FET controller (~2Kw) that is available?

as far I know, there is no 18FET KT controller. I have the 72V 40A 12FET KT controller from BMSBattery. I think its the most you can get
 
@geofft

Thanks for the report. How did you find out about that branch and how to use it so fast?
Did a little bird twitter "coke" down from the stance? ;)
 
Xnyle said:
@geofft

Thanks for the report. How did you find out about that branch and how to use it so fast?
Did a little bird twitter "coke" down from the stance? ;)

Nothing so sinister - simply down to me lurking on the German pedelec forum and relying on google translate.

'High Seat Cola' (google translation... :shock: ) is innocent of any involvement.. :)
 
bushido said:
as far I know, there is no 18FET KT controller. I have the 72V 40A 12FET KT controller from BMSBattery. I think its the most you can get
The first post of this thread implies via picture and title that there at least used to be up to probably at least 24FET versions, though they may not be available anymore.

I've not spent much time at it, but I have had a hard time even finding *any* controllers that I can be *certain* are KT and that have the full current sensors, etc., much less in an 18FET version (which is what I really wanted to find to try this out on my trike).
 
Hi guys, it looks like I might have figured out the checksum issue with the kunteng lcd's. It would be great if some others with kunteng displays could second this before committing anything.

The UART transmission from the display contains 14 words instead of the 13 that where in the code so I've updated the size of the buffer.

(this is what I logged trough uart when logging the incoming uart with a buffer 20 long, as you can see the buffer gets filled with 14 values):

<\n>buffervalue 0=16<\r>
<\n>buffervalue 1=1<\r>
<\n>buffervalue 2=202<\r>
<\n>buffervalue 3=105<\r>
<\n>buffervalue 4=0<\r>
<\n>buffervalue 5=74<\r>
<\n>buffervalue 6=5<\r>
<\n>buffervalue 7=202<\r>
<\n>buffervalue 8=4<\r>
<\n>buffervalue 9=20<\r>
<\n>buffervalue 10=5<\r>
<\n>buffervalue 11=50<\r>
<\n>buffervalue 12=14<\r>
<\n>buffervalue 13=14<\r>
<\n>buffervalue 14=0<\r>
<\n>buffervalue 15=0<\r>
<\n>buffervalue 16=0<\r>
<\n>buffervalue 17=0<\r>
<\n>buffervalue 18=0<\r>
<\n>buffervalue 19=0<\r>
<\n>crc =74<\r>
<\n>-----------------------------------------------------------------<\r>


Next it seems like the first received byte (16 in decimal) is omitted when making the checksum since it is a check by itself (to indicate the start of the new package I'm thinking)-> just like how the fixed first byte (65 decimal) when transmitting to the display is omited from the checksum as per snipped below:
Code:
	// calculate CRC xor
	ui8_crc = 0;
	for (ui8_j = 1; ui8_j <= 11; ui8_j++) {
		ui8_crc ^= ui8_tx_buffer[ui8_j];

-> this was not omited in the current master so I've changed the diplay_update() function from display.h into:
Code:
void display_update() {

	// fill local buffer from uart ringbuffer
	uart_fill_rx_packet_buffer(ui8_rx_buffer, 14, &ui8_UARTCounter);
	
	// Check for reception of complete message
	if ((ui8_UARTCounter > 13) || (ui8_rx_buffer[ui8_UARTCounter - 1] == 0x0E)) {
		ui8_UARTCounter = 0;

		// validation of the package data
		ui8_crc = 0;
		for (ui8_j = 1; ui8_j <= 13; ui8_j++) {
			
			if (ui8_j == 5) continue; // don't xor B5 
			ui8_crc ^= ui8_rx_buffer[ui8_j];
		}		
		if (ui8_crc==ui8_rx_buffer [5]) // see if CRC is ok
		{
			// Light On/Off
			lcd_configuration_variables.ui8_light_On = ui8_rx_buffer [1] & 128;
			// Walk mode
			if ((ui8_rx_buffer[1] & 7)==6) {lcd_configuration_variables.ui8_ReverseDriveModus_On = 1;}
			else {lcd_configuration_variables.ui8_ReverseDriveModus_On = 0;}
			//Assist level
			lcd_configuration_variables.ui8_assist_level = ui8_rx_buffer [1] & 7;

			lcd_configuration_variables.ui8_max_speed = 10 + ((ui8_rx_buffer [2] & 248) >> 3) | (ui8_rx_buffer [4] & 32);
			lcd_configuration_variables.ui8_wheel_size = ((ui8_rx_buffer [4] & 192) >> 6) | ((ui8_rx_buffer [2] & 7) << 2);

			lcd_configuration_variables.ui8_p1 = ui8_rx_buffer[3];
			lcd_configuration_variables.ui8_p2 = ui8_rx_buffer[4] & 0x07;
			lcd_configuration_variables.ui8_p3 = ui8_rx_buffer[4] & 0x08;
			lcd_configuration_variables.ui8_p4 = ui8_rx_buffer[4] & 0x10;
			lcd_configuration_variables.ui8_p5 = ui8_rx_buffer[0];

			lcd_configuration_variables.ui8_c1 = (ui8_rx_buffer[6] & 0x38) >> 3;
			lcd_configuration_variables.ui8_c2 = (ui8_rx_buffer[6] & 0x37);
			lcd_configuration_variables.ui8_c4 = (ui8_rx_buffer[8] & 0xE0) >> 5;
			lcd_configuration_variables.ui8_c5 = (ui8_rx_buffer[7] & 0x0F);
			lcd_configuration_variables.ui8_c12 = (ui8_rx_buffer[9] & 0x0F);
			lcd_configuration_variables.ui8_c13 = (ui8_rx_buffer[10] & 0x1C) >> 2;
			lcd_configuration_variables.ui8_c14 = (ui8_rx_buffer[7] & 0x60) >> 5;

			digestLcdValues();
			send_message();
		}
	}
}

That seems to work for me for any display setting I could come up with without the crc's getting out of sync. Only parameter 11, (communication protocol version) gets the crc's out of sync as expected. I'm not sure how the old protocol works and if it is worth implementing this, if you do, knock yourself out on it:)

Let me know if this tests ok for others as well, I can try to commit my the code to master or feel free to do it yourself.

(also I corrected the walk mode bit status in the code above as it was not working in its current form)
 
sorry, it seems I posted to early, it is no longer working...What a mistery that crc is...
 
Ok, did some more testing and it seems to work consistent without changing the code above. Think i turned on the pass code feature when testing the parameters without realizing it.
 
amberwolf said:
bushido said:
as far I know, there is no 18FET KT controller. I have the 72V 40A 12FET KT controller from BMSBattery. I think its the most you can get
The first post of this thread implies via picture and title that there at least used to be up to probably at least 24FET versions, though they may not be available anymore.

I've not spent much time at it, but I have had a hard time even finding *any* controllers that I can be *certain* are KT and that have the full current sensors, etc., much less in an 18FET version (which is what I really wanted to find to try this out on my trike).

Last I checked there was no problem to find 18fet controllers, but I have not seen the 24fet versions. It is probably about a year ago, maybe it has changed? They were sold under different names, hallomotor, consinmotor (?) etc. Zoom in on the pictures on ebay and try to work out the specifications.
 
I'm currently using Xnyle's 'X4 throttle' branch which, as previously reported, works extremely well for me. There's just one small issue that's bugging me though - the calibration of the battery bars. (12s lipo, LCD3 display)

It was always possible with previous versions to calibrate the battery bars using the 'Voltage Calibration' setting in the cofigurator, but changing this setting now seems to have no effect on the battery bars. I'm fairly sure this is the same with the Master branch too.

Is there now some other way to adjust the battery bars, or am I misunderstanding things here? :confused:
 
geofft said:
I'm currently using Xnyle's 'X4 throttle' branch which, as previously reported, works extremely well for me. There's just one small issue that's bugging me though - the calibration of the battery bars. (12s lipo, LCD3 display)

It was always possible with previous versions to calibrate the battery bars using the 'Voltage Calibration' setting in the cofigurator, but changing this setting now seems to have no effect on the battery bars. I'm fairly sure this is the same with the Master branch too.

Is there now some other way to adjust the battery bars, or am I misunderstanding things here? :confused:
On TSDZ2 firmware, everyone prefer SOC Coulomb counting as it works very well, even for different battery chemistry. User just need to setup the amount the Watts Hour rate of the battery, that can be previously measured by full discharging the battery once, while riding. On commercial MTB ebikes is standard to use the Watts Hour rate of the battery as the main tecnhical characteristic, being 500 as currently average good value. But a 200 Wh is also good for commuting on the city and be a small and light battery.

So, resuming, Watts Hour rate discharge seems the best for calculate the SOC. And it is very easy to implement as well.
 
Back
Top