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

[casainho]

Guys, can I make a small suggestion here?

It's clear that you both have differing ideas about the way some things should be done - that's completely normal with intelligent minds of course.
Would it not be best to develop this as two separate 'master' branches (maybe stancecoke master and casainho master, (call them what you like) to prevent 'treading on each others toes'. You would still be able to exchange ideas and code between yourselves, and it would be good for end users to have different options to see what works best for them.

I would be perfectly happy to test and feedback on all available options I have hardware for, I'm sure new takers coming along would also be so.....

Would be ok for me. But I think that if we can agree on having only one and trying to discuss new features being rational, would probably make it stronger.

I feel that TSDZ2 motor users are in a big number, probably because the system already has torque sensor and has a clean install. Also this type of motor is easy to install on cargo ebikes, etc. And because there are almost no combinations of hardware; firmware program can be done without soldering wires and open the controller; original firmware is available, I am curious to see the adhesion of users to use the OpenSource firmware. The controller hardware and available firmware is even more limited than Kunteng controllers and so the differentiation / added value can't much big.

 

[stancecoke]

I would prefer one master, that offers a stable implementation of the most common features and an up to date documentation.
The most common setup will be a geared hubmotor with freewheel in PAS ("torque-simulation") mode, I guess.
Hopefully the torquesensor will become more popular, if it's easy to install and to configure.

"Exotic" features can be included of course, but they have to be well documented as well, to avoid frustrating the user with unexpected behaviour. In best case, they are even implemented in the java tool.

regards
stancecoke

 

[casainho]

The most common setup will be a geared hubmotor with freewheel in PAS ("torque-simulation") mode, I guess.
Hopefully the torquesensor will become more popular, if it's easy to install and to configure.

"Exotic" features can be included of course, but they have to be well documented as well, to avoid frustrating the user with unexpected behaviour. In best case, they are even implemented in the java tool.

Here I have a different idea.

First, I see the target as tecnhical users, the ones that are ok to install their KIT on their ebikes AND ALSO are ok to wire some different wires, install PC software and follow instructions. The user can also be some local shop assembling and selling ebikes.

What is the added value of the firmware and documentation?
- documentation: BMSBattery or Ebay sellers, etc lacks documentation!! so any documentation will easily add value.
- firmware: the original firmware seems good but I am more confident using the one I know well and I see other discussing and testing with passion; clearly our firmware wins.

The choice of PAS, I see as a bad option. I see it as a cheap option but I see torque sensor as a much better option in terms of user experience, although more expensive!

I would prefer that others see this firmware and documentation as more premium, with a really good support for more premium options like torque sensor and bluetooth mobile app. I don't care much with the ones that prefer to go really cheap and that is probably because they give a low value to an ebike -- for me an ebike is special but I also look to good relation of price VS value, considering that repair and customization are very important.

So, torque sensor + LCD + bluetooth are for me the most parts that I think need attention. LCD works but does not support the all commands. Torque sensor woks very well but version from BMSBattery only. Bluetooth don't work yet.
Bluetooth because there are a lot of information and parameters that can't simple be seen/configured on LCD.

 

[geofft]

"Exotic" features can be included of course, but they have to be well documented as well, to avoid frustrating the user with unexpected behaviour.

...this has definitely been an issue for me, often I've tried the latest version of a branch and found that features that were previously working well are no longer doing so - this, as you say, can frustrate. Easy for people like me to whinge of course, but I think we all realise this is complex stuff and you guys can't be expected to get it right first time, every time.

I suppose the answer is more testers (and testing) - I'm constantly surprised that more people aren't having a play with this, I find it fascinating stuff. Obviously helps having time available to do this, being retired I'm lucky in this respect.

Anyway, however you guys decide to play it, keep up the good work...

 

[casainho]

"Exotic" features can be included of course, but they have to be well documented as well, to avoid frustrating the user with unexpected behaviour.

...this has definitely been an issue for me, often I've tried the latest version of a branch and found that features that were previously working well are no longer doing so - this, as you say, can frustrate. Easy for people like me to whinge of course, but I think we all realise this is complex stuff and you guys can't be expected to get it right first time, every time.

I clearly understand.

Current master, I think works very well except for:
- direct drive motors: it works but regen is not perfect
- PAS has that issue we had being talking about

I hope new code for PAS will make the firmware even more stable.

 

[casainho]

I've just opened a pull request at github... (I never worked with pull requests before )

Accept the pull request. Must say I didn't looked at it much, but I did that some days ago.

I must say I am not very used to them but my experience is very positive!! It is very clear to see the changes done, works very well.

 

[stancecoke]

Accept the pull request.

Thank you!

regards
stancecoke

 

[geofft]

Current master, I think works very well except for:
- direct drive motors: it works but regen is not perfect
- PAS has that issue we had being talking about

Can I add a couple of 'detail' items to that:-

1)Battery bars no longer quite correct.
Current battery SOC is 45% but battery indicator only showing 1 bar. Powers up correctly on 2 bars, then drops back to 1 after a few seconds. Previously battery bars used to climb slowly to the correct reading.

2) Wattmeter has become jittery and unstable, making it difficult to read.

....which is a little unfortunate because back on 14th April I was congratulating you guys on how well these things were working....
Only minor issues though, bother with these only when you can find the time.

 

[casainho]

Can I add a couple of 'detail' items to that:-

1)Battery bars no longer quite correct.
Current battery SOC is 45% but battery indicator only showing 1 bar. Powers up correctly on 2 bars, then drops back to 1 after a few seconds. Previously battery bars used to climb slowly to the correct reading.

2) Wattmeter has become jittery and unstable, making it difficult to read.

....which is a little unfortunate because back on 14th April I was congratulating you guys on how well these things were working....
Only minor things though, bother with these only when you can find the time.

1. I also think the same but I am pretty sure current code works well because I tested it recently. Power up to 2 bars because the low pass filter is reset to a middle battery voltage. Maybe this can be improved as currently this filtered value is only used to show to user.

Can you please verify the working of the current code on ebike_app.c?? You need a variable power supply or discharging a battery and look at display voltage and compare with main.h battery voltages table:

// calc battery pack state of charge (SOC)
  ui16_battery_volts = ((uint16_t) ebike_app_get_ADC_battery_voltage_filtered ()) * ((uint16_t) ADC_BATTERY_VOLTAGE_K);
  if (ui16_battery_volts > ((uint16_t) BATTERY_PACK_VOLTS_80)) { ui8_battery_soc = 16; } // 4 bars | full
  else if (ui16_battery_volts > ((uint16_t) BATTERY_PACK_VOLTS_60)) { ui8_battery_soc = 12; } // 3 bars
  else if (ui16_battery_volts > ((uint16_t) BATTERY_PACK_VOLTS_40)) { ui8_battery_soc = 8; } // 2 bars
  else if (ui16_battery_volts > ((uint16_t) BATTERY_PACK_VOLTS_20)) { ui8_battery_soc = 4; } // 1 bar
  else if (ui16_battery_volts > ((uint16_t) BATTERY_PACK_VOLTS_10)) { ui8_battery_soc = 3; } // empty
  else { ui8_battery_soc = 1; } // flashing

I think the table on main.h has to high values...

2. I removed the low pass filter, as I see that LCD already filter and adds delay to the real value. The only way to improve is adding back the low pass filter. I wish I could change LCD firmware and remove the show on units, like just showing 110 amps while real value is 112, 111, 114, 113, etc.
I can add back the filter, and put a define for the low filter coefficient, including disable it.

 

[geofft]

Can you please verify the working of the current code on ebike_app.c?? You need a variable power supply or discharging a battery and look at display voltage and compare with main.h battery voltages table:

No problem, I'll do this during the next battery charge cycle.

I can add back the filter, and put a define for the low filter coefficient, including disable it.

It was clear that removal of the filter had caused these changes, so for me this option would be great... :wink:

 

[-dg]

I'm quite excited by the open source nature of this project, enough so that I'm stuck between setting up my bike with a Phaserunner or one of the KT controllers so that I can test and contribute here. I'd be most interested to make it work with small gear motors, Q100H, Q128H, Bafang SWXH. For development purposes I suppose I need a display, for actual riding, I'd prefer not to have a lot of stuff on the bars. Which display do you think works best for development and is still useful without too much space used?

One of the themes that has been raised several times (I have read the whole topic from the beginning ) is the idea of using a better controller with the resources to actually do FOC instead of fake-sine-wave. The argument against this has been that the KT STM8 based controllers are so cheap and common that it will benefit the community to have good firmware easily available. So for the most part the project has considered running on cheap hardware an important feature. The recent thread on "PAS is no good, torque sensors are much better" seems to contradict this goal.

Personally, if I decide to use these controllers I will be setting up three or four bikes and don't want to buy a bunch of torque sensors and worry about axles breaking and chainline being wrong etc. Ideally these could be made to work with PAS and a couple buttons on the bars instead of a throttle. The simpler hardware the better and make it up in software.

 

[stancecoke]

A simple LED display should work, we could even use a simple button to switch through the levels (not implemented yet, but quite easy to do...). The default settings for some parameters have to be set manually in this case.

Once you rode a bike with a torquesensor, you will throw away your PAS immediatly 8)
But I agree, this cheap part of BMS-Battery is not the first choice...

regards
stancecoke

 

[casainho]

I'm quite excited by the open source nature of this project, enough so that I'm stuck between setting up my bike with a Phaserunner or one of the KT controllers so that I can test and contribute here. I'd be most interested to make it work with small gear motors, Q100H, Q128H, Bafang SWXH. For development purposes I suppose I need a display, for actual riding, I'd prefer not to have a lot of stuff on the bars. Which display do you think works best for development and is still useful without too much space used?

While I respect Justin from Grin Technologies, for done a lot for EBikes including supporting this forum, I think KT controllers with our OpenSource firmware are much better than Phaserunner controller, because it is closed source.
Justin for instance, were able to DIY an electric pedaling unicycle and he says he adapted the firmware of Phaserunner for that -- something that no one else can do it because it is not OpenSource. So to resume, I think we need OpenSouce tools, we need "the Arduino" of the EBike motor controllers so we can thinker!!

About Qxxx motors, that's the ones I started the project with, they work very well with the firmware.

Go with the LCD3 because you can monitor the power usage. The smaller one is LCD5. Hopefully, we will make the mobile app working with the bluetooth module.

One of the themes that has been raised several times (I have read the whole topic from the beginning ) is the idea of using a better controller with the resources to actually do FOC instead of fake-sine-wave. The argument against this has been that the KT STM8 based controllers are so cheap and common that it will benefit the community to have good firmware easily available. So for the most part the project has considered running on cheap hardware an important feature. The recent thread on "PAS is no good, torque sensors are much better" seems to contradict this goal.

There are other controllers like Lishui that really does FOC but don't have such options like Kunteng, to support bigger currents, bluetooth, etc. There would be no problem for me to pay 60€ for each controller instead of the current 20€ for Kuntengs. Kuntengs should be on the market for many years ahead, I don't know about others.

Personally, if I decide to use these controllers I will be setting up three or four bikes and don't want to buy a bunch of torque sensors and worry about axles breaking and chainline being wrong etc. Ideally these could be made to work with PAS and a couple buttons on the bars instead of a throttle. The simpler hardware the better and make it up in software.

I think depends on what your are looking for. For an electric bicycle experience, torque sensor is the best. For a more motorcycle experience you can go with the throttle.

 

[1N4001]

Can you use a torque sensor and throttle in parallel? e.g. have the throttle override the sensor if used, is that possible?

 

[casainho]

Can you use a torque sensor and throttle in parallel? e.g. have the throttle override the sensor if used, is that possible?

Yes if you buy the S06S throttle version. With regular version, you need to wire the cables to the controller.
Firmware does not support that yet but should be very simple to do. However, firmware does this with throttle and PAS very well, like this:

output_value = max (throttle_signal, PAS_signal)

 

[casainho]

Updated master branch code:

- Corrected a issue on adc_battery_current_offset and adc_motor__current_offset.

- Implemented adc_throttle_offset with objective to have torque sensor most sensible possible. Now at startup, that offsets are calculated so we should not move the throttle/torque sensor or even the motor wheel.

- Changed assist level multiplication factor: now I think it is clear in the code on how it works, art least for me.

- Now on main.h, there are defines for low pass filter coefficients for: THROTTLE_FILTER_COEFFICIENT, READ_BATTERY_CURRENT_FILTER_COEFFICIENT, READ_BATTERY_VOLTAGE_FILTER_COEFFICIENT

- added back the current filter for the value that is sent to LCD, so the power value on LCD should now be more stable although with more delay

What I got that I think works better:
- torque sensor now seems better for my son, before he had to do a relative high force on pedals before get assistance. The torque sensor is capable to detect very low force.

- at boot, display starts to show battery from empty and seems better than before that started from the middle value

 

[casainho]

Changed the master branch the LCD assist level on config-example.h:

#define ASSIST_LEVEL_0	0.0
#define ASSIST_LEVEL_1 	0.25
#define ASSIST_LEVEL_2 	0.5
#define ASSIST_LEVEL_3 	1.0
#define ASSIST_LEVEL_4 	2.0
#define ASSIST_LEVEL_5 	4.0

Now the throttle ADC read value is subtracted with: ui8_adc_throttle_offset + ADC_THROTTLE_THRESHOLD
ADC_THROTTLE_THRESHOLD is small value defined at 4.
The previous value is then multiplied by ASSIST_LEVEL_x and the final value is limited to 255(the max possible value).

With this implementation, we get the full range(except ADC_THROTTLE_THRESHOLD which is very small) of throttle signal and there no hard coded values that can depend on hardware. As a disadvantage, at startup during first second, we should not touch the throttle.

 

[1N4001]

> #define ASSIST_LEVEL_3 0.1

that probably should be 1.0

 

[casainho]

> #define ASSIST_LEVEL_3 0.1

that probably should be 1.0

Yes. Thanks.

 

[geofft]

Updated master branch code:

Won't flash for me...

Maybe some errors in ebike_app.c ?

Cmd dump attached.

 

[casainho]

Updated master branch code:

Won't flash for me...

Maybe some errors in ebike_app.c ?

Cmd dump attached.

Maybe a problem on your config.h:

 

[geofft]

Updated master branch code:

Won't flash for me...

Maybe some errors in ebike_app.c ?

Cmd dump attached.

Maybe a problem on your config.h:

Can't see a problem, can you take a look..?

 

[casainho]

Updated master branch code:

Won't flash for me...

Maybe some errors in ebike_app.c ?

Cmd dump attached.

Maybe a problem on your config.h:

Can't see a problem, can you take a look..?

The very first line is commented, it must has a value -- see config-example.c

 

[geofft]

Ok, I think I finally realised my config.h error. Looks like there maybe some operational PAS issues with this firmware in throttle/pas mode.
Before I go any further, could you guys cast an eye over my current config.h just to make sure it looks ok?

 

[stancecoke]

The settings in the config.h seem to be OK, now.

regards
stancecoke