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

[Xnyle]

Mhh that's interesting. I just spent the last two weeks trying to identify the origin of those vibrations with an XF15. Found a few minor bugs, tweaked a few things. There is a difference but ultimatey those vibrations around 15km/h remained.

Would be interesting to know what your controller that doesn't cause any vibrations does differently, maybe full FOC which maybe unintentionally automatically eliminates resonances.

But in general many people use geared motors and the problems with my XF15 do not seem to be electrical: If I turn the wheel backwards without any power connected I still get those vibrations.

So if your controller is able to somehow counter those mechanical vibrations, kudos. Doesn't change the fact, that the motor is the real problem?

Maybe @geofft could write something about the Q128 regarding vibrations.

 

[geofft]

Maybe @geofft could write something about the Q128 regarding vibrations.

There seems to be no inherent problem with vibrations with this motor (Q128H) and with my current settings it pulls smoothly and quietly throughout the rpm range. When I've had issues with cogging, etc, during the development of the firmware it has always been cured by changes in the code configuration, it doesn't seem to have any mechanically resonant point in the rpm range.

I've been generally very happy with this motor, it seems the earlier Q128 was a bit lacking in power but the Q128H and Q128C seem to have been a noticeable improvement on this. I can't make comparisons with other hub motors as this is the only one I've ever tried (my other ebikes are BBS02 powered), but I keep it restricted to 800w and at this power level I've had no issues so far.

 

[Xnyle]

Thanks for reporting back,

@casainho: I'm trying out different waveforms, what is the formula the SVM table was generated with?

I'm coming close with

2.0/3.0*(sqrt(3.0)*sin(x)+1.0/3.0*sin(3*x)); (0<x<2pi)

But it's not exactly the same.

 

[casainho]

Sorry I don't remember now.

 

[Marv1337n]

Does this firmware show higher wattage numbers than the stock one with my LCD3? It tops out at 1999W although I'm using a lot more.

 

[dodjob]

I have an S06S flashed with this firmware, and when I turn on the kit, the motor starts going at a moderate speed and doesn't stop until it's turned off again.

I finished my experiments with the firmware because of the behavior of the thumb throttle that does not suit me, as I wrote above, and returned to the stock firmware (on another controller).
But today my friend got the built-in (for hailong battery case) controller board KTE-9S5-J5 from ebikekit.kom, and asked me to solder the connector for programming.

IMG_0053.JPG

Waterproof compound is very soft, and the contacts are easily released from it with an ordinary wooden toothpick.
The good news is that the firmware has been launched and is working on this controller. The power supply of the throttle hall sensor on this controller is higher than usual (4.9 volts) and the desired "Throttle min" value is 47-49, otherwise the motor slowly rotates when power on. This is normal and logical.
The bad news is that even with the “Throttle min” 100-180, the motor starts to rotate when turned on and makes 0.5 turns without load, or more than 30 on load, ( if you hold the motor with your hand when turned on). I am at a loss - why turn on PWM, if the value of "trottle min" guaranteed below the minimum?! Checked twice... No PAS or TQS connected - only thumb throttle (without throttle - same behavior). MXUS XF15 gear motor.
This happened on the latest firmware (masher branch).
Fortunately, I had in the archive firmware from October last year with the last commit "Added Tool for State translation stancecoke committed Oct 23, 2018" - and with this firmware, the motor makes only 1/16 turn at a very low power, then stop (or slightly hold it with your hand and the motor will not start to rotate) and does not rotate on an ebike installed in the wheel.
As I know - on the forum there are users of such controllers on the factory firmware, pay attention to this problem.
By the way, the correct value of the "Battery current Cal a" is 100 for this controller, as well as for 6Fet controllers.

Hey mate!
Saw your post on the KT opensource thread. I have the same controller and installed the firmware too.
I have also installed osec and used the app to check hall phase and current sense phase on phase b (the little diagram + phase color feedback)
Anyway, I don't get anything regarding the back fem from motor. The green line from diagram remains more or less straight.
Did you check this? Do you see something like a sine wave when you turne the motor?
I tried to Google the phase current sensor, "SM19" but it didn't give anything. You may have some input there.
The controller is somehow ok with geared g310/g370 motors, but fail miserably with Direct drive
I suspect the foc isn't working because phase current sensor is not correctly read/or give other kind of Infos. And the FOC try to compensate this at some point. Disabling angle correction reduce this behaviour, but because of probably not perfectly good phase angle settings, my motor will not work well .
Gruß,
H.

** edit**

I found it ^^It's this sensor:
https://www.allegromicro.com/~/media/Files/Datasheets/ACS711-Auto-Datasheet.ashx?la=en&hash=37A9B02A1D2931F2560BF4CE32227DE4FEF09289
And as it looks, it seems to be delivering another mV/A as the ACS712 maybe a reason why this thing isn't displaying phase current in in the diagram of OSEC.

 

[walmis]

Anyone else getting crashes for the latest bluOSEC app? I've tried on android 9 and 7.1.2 and on both the app crashes.

 

[dodjob]

Anyone else getting crashes for the latest bluOSEC app? I've tried on android 9 and 7.1.2 and on both the app crashes.

Same here with pie. I disabled the update

 

[Xnyle]

No idea, that line (601) is already gone due to extensive refactoring. Also I reworked all SpannableStrings, so no idea which one is causing problems.

I'm checking in a new version later, have to test a few things first though.

If it still crashes, i'll need a new stack trace with current line numbers

 

[Xnyle]

Actually... I would have needed the line above where 601 appears, the one that ends with ....

Don't post images, post the actual text :wink:

Not to mention that comments like "Same here" are even more useless for debugging.

 

[walmis]

Sorry, shitty app, installed a new one, now i can copy the stack trace lol.

FATAL EXCEPTION: main
Process: org.erratic.android.bluosec, PID: 8687
java.lang.IndexOutOfBoundsException: setSpan (0 ... -1) has end before start
	at android.text.SpannableStringInternal.checkRange(SpannableStringInternal.java:464)
	at android.text.SpannableStringInternal.setSpan(SpannableStringInternal.java:189)
	at android.text.SpannableStringInternal.setSpan(SpannableStringInternal.java:178)
	at android.text.SpannableString.setSpan(SpannableString.java:60)
	at org.erratic.android.bluosec.DashboardFragment.updateCurrent(DashboardFragment.java:397)
	at org.erratic.android.bluosec.DashboardFragment.renderState(DashboardFragment.java:601)
	at org.erratic.android.bluosec.MainTabActivity$3$1.run(MainTabActivity.java:562)
	at android.os.Handler.handleCallback(Handler.java:873)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loop(Looper.java:193)
	at android.app.ActivityThread.main(ActivityThread.java:6718)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:495)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)

 

[Xnyle]

Guess your locale has '.' as decimal separator then?

So much stuff that can go wrong with locale settings when not addressed properly

New version pushed.

 

[timmy66]

I'm sorry to ask a dumb question, have read through many of the pages:

but is the highest power opensource compatible controller either this (psw : SKU:KT36/48SVPR-20A )

http://www.pswpower.com/ven.php?cargo.2016-3f-33c0

or (bms battery : s12s 500w)

https://bmsbattery.com/ebike-kit/552-s12s-500w-torque-simulation-sine-wave-controller-ebike-kit.html

I see reference to the 12 and 18mosfet varieties, but can't find these in the sine wave controllers anywhere.

Also, It's not clear why these are rated at 500w if they're able to do 20/25A at 48V (~1000 watts).

Thanks for helping to not buying the wrong thing. I'll be powering a ~750w direct drive motor with this.

 

[Xnyle]

Got a bit more expensive since i bought it, but this one is working fine.

https://www.aliexpress.com/item/Black-48V-1500W-Brushless-DC-Sine-Wave-Controller-36V-1100W-ebike-controller-48V-1500W-ebike-controller/32332163766.html

 

[MercyFlush]

Has anyone had luck in sorting the High/Low side polarity of the 60V/72V SVP's?
I have just picked one up (KT60SVP) and am not wanting to pop any transistors or mosfets

 

[j bjork]

I see reference to the 12 and 18mosfet varieties, but can't find these in the sine wave controllers anywhere.

Here is one example, there are probably a bunch more out there:

https://www.ebay.com/itm/48V-1500W-Brushless-DC-Sine-Wave-Ebike-Controller-Regenerative-Function/232088804925?hash=item3609921e3d:g:r-sAAOSwzJ5XcfEw

 

[flangefrog]

Hey there,


**Edit**
I have replaced the LM317 as it was the only thing getting warm. Well.. no luck unfortunately. The controller is just pulling too much current. Don't know if it's hardware or software related, and the reason I ask here

I've only had experience with the KT36/48 type controllers, with these the series resistor and LM317 also get very hot, I'm guessing your controller has similar circuitry here. I fretted about this myself but it's the way it's meant to work and seems to be surprisingly reliable. If you check page 126 of this thread you'll see a mod I did that gets this heat out to the casing and away a lot quicker, has worked totally reliably for me.

The heat output of the resistor/LM317 combination in watts is calculated based on the voltage drop multiplied by the current draw (including quiescent/no load current). E.g. try 48V-15V = 33V and 80mA in the below calculator
http://www.ohmslawcalculator.com/ohms-law-calculator

If you don't want so much power dissipation/heat you could replace the linear regulator (resistor/LM317 combination) with a 15V buck converter such as the CUI V7815W-500. I did this on mine (ignore the TL783 stuff, I went for the buck instead).

https://endless-sphere.com/forums/viewtopic.php?t=79763#p1210397

 

[geofft]

If you don't want so much power dissipation/heat you could replace the linear regulator (resistor/LM317 combination) with a 15V buck converter such as the CUI V7815W-500. I did this on mine (ignore the TL783 stuff, I went for the buck instead).

https://endless-sphere.com/forums/viewtopic.php?t=79763#p1210397

Wasn't aware of those V7815W buck converters, I think I'll give one a try. A while back I tried a couple of the cheapo chinese ebay bucks but found I was getting occasional random mosfet failures. Reverted back to the LM317 setup and this hasn't happened again since...

 

[Xnyle]

Just to bump this Thread a bit

 

[stancecoke]

Really cool design ! :thumb:
Is there any progress in the vibration issue?

regards
stancecoke

 

[MercyFlush]

So I have my 18FET KT60SVP and it weirdly the high side and low side drivers are identical to the 48v 12FET I have. Perhaps this is something we should add to the WIKI for those with >48v controllers to check if the polarity config matches their hardware as it doesn't seem to be consistent based on the seller of the hardware.

I have loaded the latest revision of the code to my setup and I have only battery voltage shown on my stock firmware KT-LCD3. I have changed the checksum from 1 through to 20 and have had no luck. I too am getting about a 1 second pulse on startup regardless of throttle connected or not. I have the following setup:
-BHT alternative motor ~70rpm/v with confirmed working Halls etc. (Confirmed using three controllers including a VESC)
-Hall type throttle
-NO PAS
-2x6S 4500mAh 40C LIPOs for testing. About 0.01V sag in testing

I have probed around with my scope and found some interference on the throttle input at exactly the switching frequency of the controller, sometimes spiking to over 10V! I wonder if this has anything to do with the issues at high current / rpm.

Additionally, I have tried to increase the decrement of

ui16_current_cal_b

from 1 to as high as 35 (in steps of 2) and have resolved the issue, but now have lazy/unpredictable throttle response. I also changed the amount of samples taken by the ADC from 16 to 128 (as below) and this helped my a slight amount (I could change the decrement to about 25 and avoid startup rotation).

Before I gave up for the day I added some delay between the initial current sampling (just before the below code) and also changed the order of the main.c main void to put adc_init(); before pwm_init(); and even with a 5second delay between these I still get wheel rotation. I have also tried to tie PAS and Throttle inputs to ground to no effect! I think it is perhaps something in the PAS_init or electrical noise / bad voltage regulation of the ADC

As I get time I will dig deeper on the circuit and try to find the culprit of the noise. P.S> I can audibly hear the 15.625kHz switching noise from my motor when I reduce the ui16_current_cal_b decrement to 1. It really makes me think something is funny with the code and perhaps configs with no PAS. Hopefully this is helpful, please let me know if I'm just rambling on too much :wink:

    // read and average a few values of ADC. Check that your sample will not overflow!!!
    for (ui8_i = 0; ui8_i < 128; ui8_i++) {
        delay_halfms(30);
        adc_trigger();
        delay_halfms(30);
        ui16_current_cal_b += ui16_adc_read_motor_total_current();
        ui16_x4_cal_b += ui16_adc_read_x4_value();
        ui16_throttle_cal_b += ui8_adc_read_throttle();
    }
    
    ui16_current_cal_b >>= 7;
    ui16_current_cal_b -= 28;
    ui16_x4_cal_b >>= 7;
    ui16_x4_cal_b -= 1;
    ui16_throttle_cal_b >>= 7;
    ui16_throttle_cal_b -= 1;
    }

 

[Xnyle]

I would just first debug the ADC values for a long time after startup (via diagnostics/printf) and see if they behave funny.
BTW are you sure that your controller does 10bit ADC and not 12, 16, whatever? that would explain a lot. So debug them as 16bit.

Is there any progress in the vibration issue?

No, I'm pretty sure now the motor is just crap mechanically, motor shaft, ball-bearing,...
Efficiency is also not very good, my 5kg heavier no name DD is about 10% more efficient overall.
Nothing I changed has any statistically significant effect.
I don't drive that bicycle very much though.

 

[MercyFlush]

I would just first debug the ADC values for a long time after startup (via diagnostics/printf) and see if they behave funny.
BTW are you sure that your controller does 10bit ADC and not 12, 16, whatever? that would explain a lot. So debug them as 16bit.

So after about 9 hours debugging and tracing my way through the unfamiliar code, I have landed on the following as the part of the cause of the unwanted acceleration on startup.

	ui32_time_ticks_between_pas_interrupt_accumulated -= ui32_time_ticks_between_pas_interrupt_accumulated >> 3;
	// do not allow values > ramp_start into smoothing cause it makes startup sluggish
	// also do not allow values < ramp_start when pedalling backwards
	if ((!PAS_is_active||(ui16_time_ticks_between_pas_interrupt > ui16_s_ramp_start)) && ((ui16_aca_flags & TQ_SENSOR_MODE) != TQ_SENSOR_MODE)) {
		ui32_time_ticks_between_pas_interrupt_accumulated += ui16_s_ramp_start;
	} else {
		ui32_time_ticks_between_pas_interrupt_accumulated += ui16_time_ticks_between_pas_interrupt;
	}
	printf("PAS_is_active %d\r\n",PAS_is_active);
	printf("PAS_timetickacc %lu\r\n",ui32_time_ticks_between_pas_interrupt_accumulated);
	ui16_time_ticks_between_pas_interrupt_smoothed = ui32_time_ticks_between_pas_interrupt_accumulated >> 3;
	printf("PAS_timetick %u\r\n",ui16_time_ticks_between_pas_interrupt_smoothed);

As well as

// >=8 means levels are switched of, use wanted percentage directly instead
	ui16_assist_percent_smoothed -= ui16_assist_percent_smoothed >> 4;
	if ((ui8_assistlevel_global & 15) < 8) {
		ui16_assist_percent_smoothed += ui8_a_s_assistlevels[ui8_assistlevel_global & 15];
	} else {
		ui16_assist_percent_smoothed += ui8_assist_percent_wanted;
	}
	printf("ALG %u\r\n",ui8_assistlevel_global);
	ui8_assist_percent_actual = ui16_assist_percent_smoothed >> 4;

Basically the maximum allowed current is determined by the assist level which is slowly ramped from 0 to whatever your default setting is (In my case my screen doesn't communicate with the controller, so 66% is my number). So basically the issue was that I have no PAS or torque sensor only throttle. Logically I unchecked the Torque Sensor Ride Option in the tool, however this enabled the PAS code (Code only checks if Torque mode == 1). Essentially the as PAS code accumulates the time_ticks_between_pas_interrupt from the starting number of 0 up to the RAMP START value (64000), then that goes to

float_temp = 1.0 - (((float) (ui16_time_ticks_between_pas_interrupt_smoothed - ui16_s_ramp_end)) / ((float) (ui16_s_ramp_start - ui16_s_ramp_end)));

which then sets the current target to be something other than zero

uint32_current_target = ((uint16_t) (uint32_current_target)*(uint16_t) (float_temp * 100.0)) / 100 + ui16_current_cal_b;

I think this could be solved by initializing all these smoothing functions to the preset value. Alternatively, I think turning on the TORQUE_MODE circumvents the issue too.

I'll be looking at it with fresh eyes over the weekend. Perhaps someone else could provide some insight into the best course of action to resolve this issue

 

[Xnyle]

You noticed the comment that's above your last code snippet?

//if you are pedaling slower than defined ramp end
//or not pedalling at all
//current is proportional to cadence

No cadence -> no current. If you have no PAS sensor time_ticks always goes to max, same as if you have one and are not pedalling. Otherwise everyone else would have your problems at standstill.

 

[MercyFlush]

No cadence -> no current. If you have no PAS sensor time_ticks always goes to max, same as if you have one and are not pedalling. Otherwise everyone else would have your problems at standstill.

Do you understand that it takes about 300 cycles for time_ticks to reach max as it starts at 0?
That it what I am saying is the issue.

Maybe someone else can debug time_ticks every loop and compare. I have many logs showing over 200 cycles for time_ticks to reach max, with the current set point being written quite high in this period. Not an issue for weak motors or for very damped PI I suppose