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

[geofft]

@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... ) is innocent of any involvement..

[amberwolf]

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).

[stein]

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: Select all

	// 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: Select all

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)

[stein]

sorry, it seems I posted to early, it is no longer working...What a mistery that crc is...

[stein]

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.

[j bjork]

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.

[john61ct]

How would you service 5kW rates without that many FETs?

[geofft]

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?

[casainho]

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?

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.

[florkk]

Anyone have maybe some diagram circuit for KT kuteng sine controller?

[geofft]

Anyone have maybe some diagram circuit for KT kuteng sine controller?

https://opensourceebikefirmware.bitbuck ... ematic.pdf

[florkk]

Anyone have maybe some diagram circuit for KT kuteng sine controller?

https://opensourceebikefirmware.bitbuck ... ematic.pdf

thank you very much. i have problem and maybe someone know how to solve it. i damaged two kt controllers, one 48v 22A and one 48v 45A 18fet. i build battery pack 15s, with max voltage of 61.5v. Since i use this pack with cheap no name china controller and work great, but i want switch to sine wave, and i upgraded motor. so i have 15s with max 61.5V, caps inside both controller are 63v. first controller worked for 30km, i connect it to battery when i have about 57v, then i charge baterry and after full charge (61,5V) controller is damaged, so i think it happends, and i buy new one with more fet (18fet) and do the same, i make about 50km with about 60-61V, everything was ok till i charge battery to 61.5V RIght now i have two controllers both damaged the same. it power up, communicate with lcd, everything seems working, but when you press throttle nothing happend, is show no error, but whell dont spin. But when you lift wheel and turn it backward, and it still turning slowly back and then press throttle everything work, it speeds up to max speed, when i press brake and give dummy load, it take 30A i can add and back throttle and its slows and speed , but if they motor slows too much, again i cant do nothing. when i stop and turn wheel again backwards and press throttle again it works. btw battery is still 61V.for sure motor is 100% works since i connect no name controller and it works flawless. what can be damaged ? iits looks like it dont wanna start, like missing one phase, or maybe controller dont see hall? but when i disconnect cable i get error about sensor position fault.

[geofft]

Anyone have maybe some diagram circuit for KT kuteng sine controller?

https://opensourceebikefirmware.bitbuck ... ematic.pdf

thank you very much. i have problem and maybe someone know how to solve it.

I've no experience with running KT controllers at elevated voltages but I'm guessing that the higher voltages you are using are eventually killing the mosfets. I would suggest you reduce your battery to 14s, or maybe look for some 'better' (higher voltage rating) mosfets if you want to continue with 15s. That's just guesswork though, like I said, I'm no expert

This thread is really about using the open source firmware, you may get more response if you open a new thread for your problem...

[BalorNG]

I'm building a low power 'nema 23' drive - mostly because I'm lazy and it has good gearbox options as compared to a typical RC drive, and rated 180w is more then enough to me.
https://www.aliexpress.com/item/32797544178.html
Will a cheap KT controller, or similar chinese e-bike controller work with such a system? I'm working on a tight budget.
7s 24v battery. 13T to 50T on cranks nets me about 100 RPM which is close to my preferred cadence, but it seems that high motor RPMs don't play nice with typical ebike controllers?

[bushido]

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).

In case you still need a bigger controller, i found some 18 MOSFET versions

https://s.click.aliexpress.com/e/B7ao9Irt

https://s.click.aliexpress.com/e/WvYkbgqP

https://s.click.aliexpress.com/e/L2yeXDLW3

[SlowCo]

And another supplier: https://nl.aliexpress.com/item/40001716 ... b201603_55

[Jatem]

No, this is not a "mechanical" problem, it is absolutely exactly a software problem. Or, perhaps, hardware problems (signal filtering, interference) of the KT controllers themselves.

OK, but it can't be a software problem. I have a buck converter for supplying the head- and rearlights on my bike. Even if the battery is not installed at all and the controller is switched off, the resonaces appear when the lights are switched on. The direct drive motor is working as a generator via the body diodes of the mosfets in this case. So it can't be a matter of PWM or commutation.

This leaves only a hardware problem as the cause of the resonances.
Capacity and inductivity may be in an unfavourable relation.

regards
stancecoke

Is the resonance an issue on both square wave and sine wave versions (could I remove the phase b current sensor to solve the fork judder)?

[Valopallo]

How to properly test and measure the correct phase current/battery current ratio to achieve the best performance?

[stancecoke]

could I remove the phase b current sensor to solve the fork judder

The current sensor has no influence on the resonance issue...

How to properly test and measure the correct phase current/battery current ratio

The phase current limit is only needed during the very first milliseconds at startup (or at blocked wheel), so I think there is no high potential to optimize the performance.

regards
stancecoke

[Jatem]

It's a mecanical problem, you can try to increase/decrease the tension of the spokes, but that might just shift the resonance range...

No, this is not a "mechanical" problem, it is absolutely exactly a software problem. Or, perhaps, hardware problems (signal filtering, interference) of the KT controllers themselves.
I tested the original KT firmware (sine and square version) on 7 different gear (rear ) motors - Bafang, Mxus, and Shengyi. They all had the same problem - the resonances and vibrations of the bike frame and equipment of the bike at a speed of 5-8 km / h, and at a speed of 11-13 km / h. Exactly the same problem with open source firmware. Which is a bit strange.
BTW - Mxus XF15R has good mechanics and an absolute lack of even the slightest vibrations and resonances on a cheap "trapezoid" chinese DMHC controller (I quoted the link above). My other motors also work smoothly without vibration. All this is easy to check - just take another (not KT) controller and check the operation of the motors. Vibration will not be
All this is very sad.
P.S. My KT controllers s have 25 kOhm resistors, instead of "standard" 2.2-2.5 kOhm between + 5V and the signal output of the hall sensors(open collectors). Perhaps - the problem is this, the signals are too "dirty" - the pulses from the motor windings can distort the signals from the hall sensors....

Is there a list of motors that works well with the kt controller, without any resonance?

[Valopallo]

If my twin controller/motor setup (2xs06s) pulls max 25A from the battery and I cannot find suitable (fit inside the battery case) bms for my battery, is it ok to bypass bms and discharge without bms? Can the firmware be trusted to shut down properly? If I just let the controllers shut down power from the motors when minimum voltage limit is reached how to be on the safe side and what to adjust from the firmware? I would still balance charge the battery with my 20A bms attached. The cells are up to 8A peak discharge current per cell and the pack is 10s4p. Should it work?

[stancecoke]

what to adjust from the firmware?

Just set the under-/ overvoltage limits in the java tool according to your needs, see the wiki:

Undervoltage: Undervoltage cutoff value. Calculation: Value in volts times (256/Battery Voltage Calibration). example: 34.3V * (256/70) = 125

Overvoltage: Overvoltage cutoff value during Regeneration. Calculation: Value in volts times (256/Battery Voltage Calibration). example: 54.0V * (256/70) = 203

regards
stancecoke

OSEC_Screenshot.PNG (78.1 KiB) Viewed 3270 times

[Valopallo]

Should the BluOSEC show 15A at the screen when full throttle is applied and the wheel is blocked from turning? Does it ever get to the S06S maximum of 15A? If it should go there mine shows only 11.9A? Obviously then something is wrong here. Either my controller is not delivering the full power or my settings are wrong so that it reads the current the wrong way. I'm running S06S, DD rear motor and 36V 10,4Ah battery with 15A BMS. Here's a picture of my OSEC parameter settings. Does everything look properly configured here?

Osec.jpg (112.52 KiB) Viewed 3191 times

[stancecoke]

With a blocked motor, the phase current limitation will be active. You could check the control state, to be sure.

Use the brake of the bike to keep the speed at e.g. 10 km/h with full throttle, then you will see full amps. If not, you have to check your throttle settings throttle_min and throttle_max.

regards
stancecoke

[Nexter]

Hello, i have buy a KT 36 controller (48 V 500/1000 W / 9 Mosfet) and on my controller i have à Bluetooth controller
The bluetooth controller is directly integrated

https://i.ibb.co/N1qkkdw/IMG-20191122-091745.jpg
https://i.ibb.co/3htLN3q/IMG-20191122-091803.jpg

My question is : Are the wires used to connect the Bluetooth controller soldered directly to the correct location on the controller to flash the fimware?

If yes, is there a way to know the order (without disassembling) for the connection with the stlink?