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

Xnyle said:
Why do you get a buildup? If hysteresis is >1 as it was b4 you would get a constant offset of 1 once correction kicks in?

I might have the beginning of an answer.

Xnyle you're right that the current should only get offset by 1, but in my case the phase current scale is so squished that the angle correction needed to correct such a small offset is still large, and leads to big changes of behavior of the motor.

It led me to think that my phase current sensitivity was not adequate.
I looked at the ACS712 current sensor and my controller has the 30A version, which has a 66mV/A sensitivity. In 8bit adc steps, that's 3 per amp. This combined with the fact that I'm on an electric scooter, so perhaps less current draw than an ebike, means that the phase current is not resolved enough to do fine foc.

What variants of current sensors do you guys usually find on your controllers ?
 
naimo said:
I looked at the ACS712 current sensor and my controller has the 30A version, which has a 66mV/A sensitivity. In 8bit adc steps, that's 3 per amp.

Or maybe I should just keep the 10bit adc for the phase current instead of keeping the division by 4 in the code.
Code:
ui16_ADC_iq_current >> 2
 
I had the same behavior with the same ACS712 on a 35A 12FET when there was a solder blob connecting all 4 pins.
No idea why they did that, once I (more or less) removed it more current went through the sensor and correction worked fine.
Have you checked on the underside of your board that there is no bypass?

I don't think 128/127 is the real problem, actually mid point is 127,5.
 
Xnyle said:
I had the same behavior with the same ACS712 on a 35A 12FET when there was a solder blob connecting all 4 pins.
No idea why they did that, once I (more or less) removed it more current went through the sensor and correction worked fine.
Have you checked on the underside of your board that there is no bypass?

Wow you were right, there was a short between the two inputs of the current sensor. This is some fine tuning only chinese manufacturers know how to do !

I cleaned it up, back to stock and I will test again.
 

Attachments

  • shunt.jpg
    shunt.jpg
    203.4 KB · Views: 1,832
Yeah, once I fixed the current sensing, I could actually see something on the scope when probing on the output. It showed me that I didn't have the wiring correct (current waveform was not a sine wave). After rearranging, I get a pretty sine wave and the motor runs much smoother/more quietly.

Now it seems that the default angle doesn't start the motor well in 6-step before switching to 60degree interpolation, but if I change it (lower it) to improve the startup, then the motor doesn't reach as high of a speed at full throttle.
 
naimo said:
Yeah, once I fixed the current sensing, I could actually see something on the scope when probing on the output. It showed me that I didn't have the wiring correct (current waveform was not a sine wave). After rearranging, I get a pretty sine wave and the motor runs much smoother/more quietly.

Now it seems that the default angle doesn't start the motor well in 6-step before switching to 60degree interpolation, but if I change it (lower it) to improve the startup, then the motor doesn't reach as high of a speed at full throttle.
What are you looking for? Best efficiency or more speed??

With FOC you should get best efficiency possible, most possible torque per amps and so best battery range.
 
casainho said:
What are you looking for? Best efficiency or more speed??

With FOC you should get best efficiency possible, most possible torque per amps and so best battery range.

Since we're current controlled, I think that when the motor runs the most efficient, it also runs the fastest for a given current and "load".
Getting the best battery range, at fixed current, also means going the fastest during the time it takes to discharge the battery.
 
naimo said:
casainho said:
What are you looking for? Best efficiency or more speed??

With FOC you should get best efficiency possible, most possible torque per amps and so best battery range.

Since we're current controlled, I think that when the motor runs the most efficient, it also runs the fastest for a given current and "load".
Getting the best battery range, at fixed current, also means going the fastest during the time it takes to discharge the battery.
You can also change the parameters to have FOC working being less efficient but giving higher motor speed for the same battery voltage.
 
casainho said:
naimo said:
Since we're current controlled, I think that when the motor runs the most efficient, it also runs the fastest for a given current and "load".
Getting the best battery range, at fixed current, also means going the fastest during the time it takes to discharge the battery.
You can also change the parameters to have FOC working being less efficient but giving higher motor speed for the same battery voltage.

mmm... I don't see how this is possible in a current limiting mode. Maybe this is possible at a fixed duty cycle ?

Anyway, to go back to the determination of the MOTOR_ROTOR_DELTA_PHASE_ANGLE_RIGHT : in your experience, is it possible that the angle giving best efficiency for interpolation+foc be causing issues for starting the motor in 6-step ?
 
naimo said:
casainho said:
naimo said:
Since we're current controlled, I think that when the motor runs the most efficient, it also runs the fastest for a given current and "load".
Getting the best battery range, at fixed current, also means going the fastest during the time it takes to discharge the battery.
You can also change the parameters to have FOC working being less efficient but giving higher motor speed for the same battery voltage.

mmm... I don't see how this is possible in a current limiting mode. Maybe this is possible at a fixed duty cycle ?

Anyway, to go back to the determination of the MOTOR_ROTOR_DELTA_PHASE_ANGLE_RIGHT : in your experience, is it possible that the angle giving best efficiency for interpolation+foc be causing issues for starting the motor in 6-step ?
Yes, maybe. I remember that I could never make work the 6 step before jumping to SVM and the startup is still done with SVM kind of 6 steps (this is what still is implemented on TSDZ2). I don't know how it is current KT firmware done as I am not anymore developing and using it.
 
casainho said:
Yes, maybe. I remember that I could never make work the 6 step before jumping to SVM and the startup is still done with SVM kind of 6 steps (this is what still is implemented on TSDZ2). I don't know how it is current KT firmware done as I am not anymore developing and using it.

Ah yes that's what I meant, the code seems to be doing what you're describing, a six-step sine wave (phases are always energized).

Still, for me it seems that a "good" angle for foc doesn't start well in this SVM six-step mode.
 
You can change the 6step startup to trapezoid and see if that works better (wavetable already there, just one or two line change in motor.c)
This is on my backlog, but hadn't time/motivation so far.
 
Xnyle said:
You can change the 6step startup to trapezoid and see if that works better (wavetable already there, just one or two line change in motor.c)
This is on my backlog, but hadn't time/motivation so far.
What I remember is that the way it is done, the startup is weak, motor vibrates, etc.

6 steps is way strong but the current controller did fail on the transition to SVM and I easily burn mosfets. I were able to see the current controller going out of control when I moved the wheel slightly back and forward to simulate changing between both states.

On TSDZ2 is not a big issue because the motor has an high rpm so the startup happens in very short time.
 
You know that I reworked that part? So no idea what version you're referring to.

Where I picked it up it looked up some position from the (only) svm wavetable that was influenced by hallsensor position and motor angle. And that "some position" could have been anything within a 60° range depending on motor angle.

Now there is a six step "wavetable" and a trapezoid one. six step is currently used on startup, that is what I was referring to.
 
Xnyle said:
You know that I reworked that part? So no idea what version you're referring to.

Where I picked it up it looked up some position from the (only) svm wavetable that was influenced by hallsensor position and motor angle. And that "some position" could have been anything within a 60° range depending on motor angle.

Now there is a six step "wavetable" and a trapezoid one. six step is currently used on startup, that is what I was referring to.
Sorry for the incorrect information I gave. I didn't know you did rework that.

Maybe I will look at this again in the future for TSDZ2 and I will borrow your code :)
 
Small update. I played around with the motor angle some more

First I limited the battery current to a low value, and looked for the angle that gave me the highest RPM at no load.
Unfortunately, when I went to actually ride it, the motor did reach a high speed on flats but seriously lacked torque, especially at low end.

Then reading a few pages back on this thread, I found this suggestion :
apple2 said:
Also to test different motor angles, what I do is disable angle correction and try starting from standstill (not at full throttle) and check how much cogging I get.. then change and try again

Did that, turned correction off and found a close-to-optimal angle as far as startup torque is concerned (standing on the scooter, while applying weight on the front wheel, and punching the throttle).
I went for a first ride without re-enabling angle correction yet (interpolation + sine wave kept enabled of course), and I must say it is riding really well (decent torque uphill, still reaches high speeds on flat). I'm now quite happy with the performance, hopefully efficiency isn't too bad.

I need to re-enable angle correction to conclude, but I'd like to be able to toggle it on and off while riding. I might use the assist levels from my LCD5 since for now I don't apply them to throttle.
Edit : I did exactly that (toggle with assist level), I know that the controller is receiving my command because turning foc on and off makes a significant difference at no load. However I couldn't feel anything significant when toggling while riding.
 
stancecoke said:
Marv1337n said:
I saw that you can modify the LVC, so would that fix my problem or is it a hardware problem?
No hardware problem, you can define any LVC with our open firmware. But I don't know, if your LCD works with lower voltages, as a special "high voltage" version of the LCD3 exists.

regards
stancecoke

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.
 
Aeron said:
stancecoke said:
Marv1337n said:
I saw that you can modify the LVC, so would that fix my problem or is it a hardware problem?
No hardware problem, you can define any LVC with our open firmware. But I don't know, if your LCD works with lower voltages, as a special "high voltage" version of the LCD3 exists.

regards
stancecoke

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 limit sor other)

+1

i would also love to have higher voltage on a small 6FET/9FET controller. because i will use it with high geared hub motors, i would max out @ ~45km/h. i dont need more power (A), just higher voltage.

i just want to know if its an "easy" mod. if i have to replace one third of the components its not worth it
 
geofft said:
davideserin said:
I'm using the Sempu torque sensor and i have it working, but is it possible to use a throttle in addition to this?

I'm currently using a Sempu T4 torquesensor and also have a throttle connected. My method was to connect both throttle and torquesensor signal lines in parallel to the controller i/p via a couple of blocking diodes, I used shottky diodes here to reduce the signal voltage drop. You'll then have to alter the Throttle min/max settings to suit.

This works well enough for me, there's a little lag in the throttle response due to the averaging function applied by the torquesensor code but not too noticeable in use.

I think I need to add a little more to this. I'm using a version of the firmware that dates back to last October - with this version the motor would operate from rest with torquesensor input only (i.e. without pedal rotation/pas pulses).

I now realise that the current fw downloads also require pas input before the motor will drive. This is the safer method of operation but unfortunately means the throttle method described above won't work in any useful manner. I don't know if the requirement for pas input can be switched off, I can't see anything in the configurator that would do this - maybe there's something in the app..?
 
No, that would be an experimental and dangerous option we could add though.

What changed since October is ACAsetpoint 282.

In the past apparently someone blew up his motor by tilting his pedal against a wall or something. Without this new protection the bike then wanted to move but couldn't.

What I would suggest though instead of yet another option nobody understands is to just change this protection so that it's always on (you could also think of someone leaning his thumb throttle against something) but more lenient

For instance allowing X seconds of throttle without cadence input (just a quick thought).

Low processing power solutions welcome.

Please think about it and come up with some pseudo code.
 
Xnyle said:
No, that would be an experimental and dangerous option we could add though.

What changed since October is ACAsetpoint 282.

In the past apparently someone blew up his motor by tilting his pedal against a wall or something. Without this new protection the bike then wanted to move but couldn't.

What I would suggest though instead of yet another option nobody understands is to just change this protection so that it's always on (you could also think of someone leaning his thumb throttle against something) but more lenient

For instance allowing X seconds of throttle without cadence input (just a quick thought).

Low processing power solutions welcome.

Please think about it and come up with some pseudo code.
That issue wasn't on TSDZ2 firmware??

What I did was motor shutoff if torque sensor > 0 for like 15 seconds and wheel speed == 0. Throttle or torque sensor activated means bicycle wheel should move otherwise something is stuck which should not happen.
 
Not sure where it was, stancecoke reported it to me.

I'll probably just implement a counter that counts when throttle/torque override is present:

if erps <3: down
else: up

if counter reaches 0: disable override
init 127 or something.
 
For me there are just two situations where you need throttle capability in the (current) torquesensor mode:-

1) Pulling away quickly from a standstill,
2) In awkward 'feet down' situations where you are manoeuvring at slow speed around obstructions.

For instance allowing X seconds of throttle without cadence input (just a quick thought).

....I guess this could be a problem in situation 2.

What I did was motor shutoff if torque sensor > 0 for like 15 seconds and wheel speed == 0. Throttle or torque sensor activated means bicycle wheel should move otherwise something is stuck which should not happen.

....this seems a good option to me, would you allow brake input to disable this protection? - maybe this is already implemented.
 
geofft said:
What I did was motor shutoff if torque sensor > 0 for like 15 seconds and wheel speed == 0. Throttle or torque sensor activated means bicycle wheel should move otherwise something is stuck which should not happen.

....this seems a good option to me, would you allow brake input to disable this protection? - maybe this is already implemented.
Yes sure, brakes simple keep motor disabled as also keep that counter reset. Also if wheel_speed > 0, the counter is reset.

We send to KT-LCD3 (and the others) a specific error code so users know when this error is active other way they will not understand why system is not working. Some users do not install brake sensors and keep pressing slightly the pedals/resting feet on red lights and the torque sensor is activated and will trigger this issue.

So, this is a kind of feature that can create frustration to some users if they do not have visual feedback from the system.
 
Hi All,

Sorry if I'm asking very stupid question.

My goal is just to remove 'speed limiter' in my ebike.
Currently my setup is 900s led with KT48ZWS 1000watt(previously is KT36/48 500 watt)
With both controller I'm hitting barrier on the same 43kph (on gps). Even when i feel the bike still have more juices to get higher

1. What's the diferences of setting up the maximum speed in the firmware/controller, than setting it up through the LCD3?

2. Seems my bottleneck is the RPM limiter, but i didn't see options for that on the firmware GUI

3. How to get/read the default parameter value just for recovery plan? Will it load the default when i connect the controller for the first time?

Thanks
 
Back
Top