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

sylvain_wm said:
I don't know why,

have you checked the stability of the 5V rail? We had often problems with unexpected controller behaviour, when the current on the 5V rail was to high and the voltage dropped. (don't connect a BT-Module to the 5V rail for example, use an extra DC/DC converter)

If the throttle reading is OK, you should try, if uint32_current_target changes, if you twist the throttle.

regards
stancecoke

Edit:
@sdobbie: sylvain_wm provides senseful logging data, so I can help to find the problem. You only say "Mimimi ... doesn't work" and spread around in several parallel threads that the firmware sucks....
 
I unsoldered a wire that I assumed was the input to the SPEED sensor and soldered it to the pin X5 of my KT controller and now the speed is read on pin 30 of the microcontroller. The speed is displayed on my KT LCD3 ...
Small steps ....
Now the motor spins !!! Always ... and the speed is 62km/h
I have to change parameters in the config.h and I'll see if it works well.
 
stancecoke said:
have you checked the stability of the 5V rail? We had often problems with unexpected controller behaviour, when the current on the 5V rail was to high and the voltage dropped.
I think you're right, there must be a problem with the 5V.
I tried to supply my controller with another power supply, the bluetooth communication works well until 40V.
Beyond 40V, the communication is really bad.
The two LM317 are maybe the cause of the problem.
 
The bluetooth communication is now perfect. I got rid of the two LM317s and the two resistors.
I used instead a DC/DC converter 90V/12V.
LM317 to DC_DC converter.jpg
It doesn't heat up anymore. And the system is stable.
I can now study the behavior of my bike with the bluetooth diagnostic.
Everything works now. The motor spins when I pedal.
I still have problems :
- When I stop pedaling, the motor takes time to stop... too much time. Can we change this?
- I'd like to limit the motor current to 20 amps, how can I be sure it's 20 amps?
 
I own exactly the same controller except the fact it's labeled KT56-90..., hardware is the same, I havn't tested it yet as my new motor is still between China and France. I'll use 16S battery so I might have the same issue as you.
You said you solved it by replacing the line with DC/DC 90V-12V converter, it's not rather 90V-5V?
 
I'll use 16S battery so I might have the same issue as you.
You said you solved it by replacing the line with DC/DC 90V-12V converter, it's not rather 90V-5V?

The FET circuit is designed to operate with 15V. 12V is a little low and might not be optimal for the FET's.

A 16S battery will have a maximum voltage of 67.2V so I don't think you'll run in to the same problem. I would try it first.
 
Woly said:
The FET circuit is designed to operate with 15V. 12V is a little low and might not be optimal for the FET's.
The MOSFET for this board is an IRFB4110 (instead of a TK150E09NE for KT 48V)
You are right, the output voltage of the second LM317 is Vout=15V. But the Gate Threshold Voltage of the MOSFET is less than 4V. So there are chances that VGS is enough to saturate the transistor : there is no need to have VGS=10V to saturate the transistor.
I picked a 90V/12V because I had one at home and didn't want to wait.
I'll try to measure the VGS with an oscilloscope.
 
My board is dead!!
While measuring VGS, I made a shortcut!!
3 MOSFETs are dead.It's not that bad.
I have now an arm with only two transistors instead of six.
I'll send you scopes later.
 
Hello,
I still have problems :
- When I stop pedaling, the motor takes time to stop... too much time. Can we change this?
- I'd like to limit the motor current to 20 amps, how can I be sure it's 20 amps?

Does anyone know how to solve these problems?

Have a good day.
 
You only say "Mimimi ... doesn't work"

No, I actually provided details of my setup and steps I took to troubleshoot, so don't put words in my mouth. You are being very childish. If we all work together on this rather than making smartarse remarks to people without an electronics laboratory and a degree in C++ who are trying to get support, we can turn something which is pretty buggy and difficult to set up into something pretty awesome. I can see the project has potential.

So, if you want me to give as much info as I can and list all the problems I am having so that we can get these bugs sorted for everyone's benefit, that would be great. Otherwise, I will just move on to the vesc project.
 
sylvain_wm said:
- When I stop pedaling, the motor takes time to stop... too much time. Can we change this?

please read the wiki carefully!!! :wink: Keyword: PAS timeout

sylvain_wm said:
- I'd like to limit the motor current to 20 amps, how can I be sure it's 20 amps?

You probably have to adjust the battery current cal a value. You have to check the setting with a lab power supply or a wattmeter or any other suitable multimeter.

@sdobbie: feel free to provide us meaningful log data and a short but precise description of your problem. Tell us your setup as good as possible, e.g. find out the number of pole pairs and the mechanical gear ratio of your motor.

regards
stancecoke
 
feel free to provide us meaningful log data and a short but precise description of your problem. Tell us your setup as good as possible, e.g. find out the number of pole pairs and the mechanical gear ratio of your motor.

Thanks, sorry if any hard feelings earlier.
I will get proper log data to you tomorrow when I am back at my other house. What data would you like me to log from the list of options in the app?

The motor has 18 stator coils and 20 magnets, so I'd imagine 6 poles for the stator.

It is a planetary reduction drive with 78 teeth on the wheel, 30 teeth on each planetary gear and 16 teeth on the motor giving a 39 to 8 ratio.
Clipboard01.png

The two main issues are:
1: Some limit is being hit before field weakening gets a chance to kick in and give me the highest speed possible so I am getting about the same speed as the old KU63 controller that was on the bike. I suspect that it could be the erps limit. I was playing around with the ratio and wheel circumference settings and the motor hits some limit when the speed in the app is showing 70km/h at full throttle when I set it to 100 in the Java tool. I made sure not to change any settings in the app as you mentioned an overflow bug which causes it to loop back to 20.

2: Motor drag and high power consumption when coasting with no throttle input.
I did an experiment yesterday and spun the pedals by hand with a watt meter connected. My watt meter can only register current in one direction so the power is definitely flowing into the controller and not back into the battery. This issue is not due to regen being active as I disabled regen for the test to make sure. Here is a video, controller was consuming 40 watts just with me pedalling by hand.

The motor starts and runs smoothly and quietly when propelling the bike so my motor angle settings should be okay.

Many thanks,

[youtube]2ZJWiV7FMAA[/youtube]
 
sdobbie said:
What data would you like me to log from the list of options in the app?
As I've written before, I don't use the BluOSEC app, so I'm not familiar with it.
Please flash in Diagnostics mode and log with Bluterm e.g.:

https://github.com/stancecoke/BMSBattery_S_controllers_firmware/wiki/07---The-Diagnostics-Mode

This parameters are interesting for your problem:
ui8_control_state, uint32_current_target, ui16_BatteryCurrent, ui32_SPEED_km_h, ui16_motor_speed_erps, ui16_current_cal_b

Please log one run with full throttle with the wheel in the air and one run with closed throttle and turning the pedals by hand, like in the video. Please post the content of the config.h you have used for the tests.

sdobbie said:
20 magnets, 78 teeth on the wheel, 16 teeth on the motor
so your correct gear ratio should be 20/2*78/16 = 48,75 ~ 49, you can fine tune the system with the wheel circumference.

regards
stancecoke
 
Hello,
in diagnostic mode, when I print out ui16_control_state, ui16_BatteryCurrent, ui16_current_cal_b
I get : 28 316 315 without pedalling, weird???
when I pedal and brake, only ui16_BatteryCurrent increases.
Is that normal?
It doesn't seem correct.
To tell the truth, I'm a bit lost...
I don't have the same current sensor on KT 72V than on the KT 48V. It can be the reason?View attachment config.h
Thanks
 
sylvain_wm said:
Is that normal?

Yes. why should there be other changes than ui16BatteryCurrent?!
ui16_current_cal_b (ADC offset of the battery current channel) is determined once at startup and will never change later at runtime.

If ui16BatteryCurrent is lower than ui16_current_cal_b you are doing regen, if ui16BatteryCurrent is higher than ui16_current_cal_b, you are getting power from the motor.

ui16_control_state will only change, if you run in a special situation like speed limitation or overcurrent limitation.

State28.JPG

regards
stancecoke
 
Thanks stancecoke,

I measured currents and printed out their adc values.
For ui16_BatteryCurrent I obtain the equation:
ui16_BatteryCurrent = 2.68 x I_batt + 315
For ui16_adc_read_phase_B_current I obtain the equation:
ui16_adc_read_phase_B_current = 2 x I_phase_B + 511

I'd like to limit the battery current to about 15A and the motor current to about 20A.
What are the parameters I should put in Battery Current max, Phase Current max and Battery Current cal a?
In my opinion :
Battery Current max = 355
Phase Current max = 551
And Battery Current cal a = 27 I'm not sure?

I don't want to make another mistake. So I prefer to be sure.

Question : Voltage Calibration and Battery Current cal a are only for the display?

Thank you.
 
sylvain_wm said:
ui16_BatteryCurrent = 2.68 x I_batt + 315

Have you did this for different currents? If you get a good linearity, the 2.68 should be OK. You can set Battery Current cal a to 27.

For the phase current you have to use the same formula as for the battery current. The phase current is not measured but calculated from
Code:
phase current = battery current / duty cycle

The ADC value of the phasecurrent sensor is used to do the simplified FOC, only. We look at the zero crossing to adjust the advance angle.

sylvain_wm said:
Voltage Calibration and Battery Current cal a are only for the display?
yes.

regards
stancecoke
 
stancecoke said:
Have you did this for different currents?
Yes I did. I think I was pretty accurate.

stancecoke said:
For the phase current you have to use the same formula as for the battery current.
Ok. I thought the firmware used the current sensor because the value is read in the program. It's only used for the zero crossing.

Thank you.

Have a great day.
 
endlessolli said:
stancecoke said:
endlessolli said:
this opensource firmware results in erratic / non smooth Motor behavior (under load).

What is your setting for max battery current and for max phase current?
Set max phase current much higher than max battery current!

regards
stancecoke

Thanks for the reply, stancecoke!
These are my current settings:
Battery current = 70
Phase current = 100
Cal a = 50 (I have small a 6 FET controller - so I should put this to 100 accroding to the wiki. (Is that a fudge factor or is there a way to calculate the correct value?)

I also found another potential issue: I digged some more in the forums (also german pedelec forum) and realized that my 'pre-controllers' RC low pass filter for the thumb input was maybe too low. (You used 1kOhm & 5µF for some experiments, the 'Forum-controller' uses 150Ohm and 100µF; I used 10kOhm & 5µF. Still wondering why it worked w/ the std. Firmware and not so good with your open source f/w.
I will also experiment with the current settings.
But the weather forces me to take a break......

OK, weather gets better and I did further testing, so I wanted to give a brief update on this (older) topic:

It turns out that all my problems with eratic motor behavoir seem to be due to the fact that I use Bluetooth w/ the BluOsec App!

When I compile it with 'no Display', everything behaves as smooth as with the stock firmware (and better).

Note: I don't want to blackmail the BluOsec App with this - it is a great tool to efficiently finetune motorparameters for initial setup i.e. on a motor test setup. But when actually using the setup / driving, it does not work properly.
I think @stancecoke mentioned that also already in this thread, but I was so far under the impression, that it 'sometimes' (as in rarely) causes problems, whereas for me, it *contantly* caused problems during use (also, when the Smartphone is not even on / connected to the controller)

But again: Thank you for all the work to all the contributors! Great project!!
 
I managed to get hterm working, the blueterm app didn't show up any options for connecting. I have attached three log files, rev up.log is me revving the motor up under no load, cycle regen.log is just slowly moving the regen throttle from closed to open without the wheel spinning and motor drag.log is turning the wheel quite hard with no regen throttle connected and no throttle input.

A new issue has now arisen and this is with the regen being stuck on all the time when the regen throttle is plugged in. This prevents the main throttle from responding as expected because we changed the code so that we don't need to pull the brake to get regen to work. I have measured the regen throttle output voltage while it was attached to the controller and it is 0.973v in the closed position , 0.95 just slightly open and 3.459 fully open. This is a fault with my throttle and not so much the software so is there a way to change the x4 throttle range like you can with the main throttle?
 

Attachments

  • motor drag.log
    4.3 KB · Views: 21
  • rev up.log
    4.5 KB · Views: 22
  • cycle regen throt.log
    4.5 KB · Views: 13
endlessolli said:
But when actually using the setup / driving, it does not work properly.

Yes, the app is known to freeze the system sometimes. We have the bugfix in the branch "torque from X4" already. @Xnyle has used very much floating point and division operations in the master branch. In combination with the massivie UART communication of the BluOSEC app, we get an overload on the processor. The solution is to replace all the floating points and divisions by integer arithmetics and shifts. It's just half an hour of work to port the solutions of the "torque from X4" branch to the master, but nobody have done this job so far.

sdobbie said:
the blueterm app didn't show up any options for connecting
You have to long press one of the three "hardware" buttons of the cell phone to open the menu for connecting, logging etc.

sdobbie said:
I have attached three log files
Thank you, I made some graphs from the data, everything is OK, so far. The log with the regen throttle makes no sense, you have to print out the relevant variables (I listed them in the post addressed to you before :wink: ) You have to change them manually on line 193 of the main.c

In the drag graph, you can see, that the motor regenerates slightly at the first acceleration, before the PI control brings the battery current to (almost) zero again. The duty cycle is controlled, to get exactly the same voltage from the controller as from the BEMF. So we get no voltage difference and therefore no battery current. As written before, you could manipulate the ADC offset (battery current cal b) a little, to get a slightly positive torque and avoid a "braking" feeling.

drag.JPG

In the rev up graph, everything looks normal. No speed or current limits are reached, so the wheel just spins up and stops again...

rev up.JPG

sdobbie said:
is there a way to change the x4 throttle range like you can with the main throttle?
Of course. Quick and dirty, you could hardcode your values in line 173 of the ACAsetpoint.c or you can define own variables for the X4 limits.

regards
stancecoke
 
Hugely appreciated, thank you :D . I'm going to play around with the settings a bit more as you suggest to sort the regen throttle range and the motor drag. It would be nice to get the wheel going faster though because as I said previously, I accidentally changed this line ui16_current_cal_b >>= 4; to >>=8 and as soon as the controller was powered up, the wheel spun around twice as fast as it would normally on full throttle without me even touching the throttle, so it would be good if we could find a way to reach that speed with normal throttle operation.
 
sdobbie said:
so it would be good if we could find a way to reach that speed with normal throttle operation.

Is this behaviour repeatable?! I know no reason, why the wheel should spin faster with a misstuned ADC offset of the battery current channel.
As you can see in the rev up graph, the duty cycle reaches 255 at idle run, that's the maximum. The wheel can only spin faster with a higher battery voltage or with field weakening.

regards
stancecoke
 
Back
Top