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

stancecoke said:

please rename the firmware folder and avoid parenthesize! See here:
https://www.avrfreaks.net/forum/make-interruptexception-caught-code-0xc00000fd-addr

regards
stancecoke

Click to expand...

Guessed I was probably doing something dumb, just too many traps for numpties like me.

Will try again tomorrow... :?

geofft said:

stancecoke said:

please rename the firmware folder and avoid parenthesize! See here:
https://www.avrfreaks.net/forum/make-interruptexception-caught-code-0xc00000fd-addr

regards
stancecoke

Click to expand...

Guessed I was probably doing something dumb, just too many traps for numpties like me.

Will try again tomorrow... :?

Click to expand...

Success! Things are now starting to work...

I'm not sure how much time or effort you're planning to put into developing this code, but I've put some feedback below in case it's of any interest.

1) Throttle only mode. Works ok. Was very jerky at first but increasing the 'Phase current max' (500 to 800) greatly improved this and the motor feels smooth and quiet.

2) Throttle and PAS. No response to throttle or PAS.

3) Torquesensor. Not tested.

4) Torque simulation. PAS works ok, maybe a little oscillation during acceleration but otherwise feels smooth, progressive and natural. No throttle response.

Wattmeter readout looks accurate.

Battery bars reading 1 (maybe 2) bars too high. (With my controller, may be ok with others...)

...so generally pretty good. Phase current limiting is obviously working but is rather on/off in its action, maybe a little smoothing required here.

geofft said:

Success! Things are now starting to work...

Click to expand...

Nice to hear! Thank you for testing! 8)

geofft said:

2) Throttle and PAS. No response to throttle or PAS.

Click to expand...

Be aware, this is throttle and PAS mode. In this mode you have to use the throttle, but it works only, if pedals are turning. In this way, the use of the throttle is legal in Germany...

regards
stancecoke

stancecoke said:

2) Throttle and PAS. No response to throttle or PAS.

Be aware, this is throttle and PAS mode. In this mode you have to use the throttle, but it works only, if pedals are turning. In this way, the use of the throttle is legal in Germany...

regards
stancecoke

Click to expand...

Ah..ok, didn't know that.

Have just retested this, but still no response when both operated together.

geofft said:

Have just retested this, but still no response when both operated together.

Click to expand...

Ah, you are right, I never updated the enhanced direction detection for this mode. I've fixed it on github. I have not tried it in hardware, but it should work now.

Please, can you tell us which motor you are using and upload your working settings.ini? So we can collect proven setups and new users can use them, if the have a similar constellation.

regards
stancecoke

Stancecoke, maybe you can start thinking in using LCD3 with KT firmware. The current firmware uses only about half of the total available flash memory but the firmware is almost finished for TSDZ2. It can be easily expanded with new configurations menus (because the structure is already implemented), I can imagine a more generic KT firmware where most options are configured on LCD3 and not on config.h of the firmware.

I just implemented 2 popular requested features: configure on the LCD the battery max current and battery max power.

In the following video you can see this new features working very well, when my ebike is on a training roller. After testing outside on a ride I can say they work very well just like on the video.

I wrote a wiki page with all the features/menus of the OpenSource firmwares for TSDZ2 and KT-LCD3: https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/TSDZ2-and-KT-LCD3-advanced-features

[youtube]6d4fZg9TxnI[/youtube]

casainho said:

Stancecoke, maybe you can start thinking in using LCD3 with KT firmware.

Click to expand...

Sorry, no interest. As you know, I don't like any display at my handlebar. :wink:

regards
stancecoke

stancecoke said:

casainho said:

Stancecoke, maybe you can start thinking in using LCD3 with KT firmware.

Click to expand...

Sorry, no interest. As you know, I don't like any display at my handlebar. :wink:

Click to expand...

I understand.

I think our firmware for LCD3 and motor controllers bring a good value, some like cycle analyst. Let's see if other developers can join to help.

stancecoke said:

geofft said:

Have just retested this, but still no response when both operated together.

Click to expand...

Ah, you are right, I never updated the enhanced direction detection for this mode. I've fixed it on github. I have not tried it in hardware, but it should work now.

Click to expand...

Yes, that now works (in German legal manner... ). There is some fairly severe oscillation or 'pulsing' of the drive though. Is the throttle being scaled by pas cadence - maybe that limiting needs smoothing out?

Please, can you tell us which motor you are using and upload your working settings.ini? So we can collect proofed setups and new users can use them, if the have a similar constellation.

regards
stancecoke

Click to expand...

You'll find my running configuration in the bottom signature line of my posts (Q128, etc)
I've attached my current settings.ini. This may change a little, I haven't got around to playing with all config settings as yet.

geofft said:

Yes, that now works (in German legal manner... ). There is some fairly severe oscillation or 'pulsing' of the drive though. Is the throttle being scaled by pas cadence - maybe that limiting needs smoothing out?

Click to expand...

No, the throttle value is used for the target current in the same way as in throttle-mode. Perhaps you should increase the value of "PAS timeout" to avoid hickups.

To avoid oszillation, you can reduce the values of Gain P (and Gain I), but be aware that the response to the throttle signal will get slower.

geofft said:

You'll find my running configuration in the bottom signature line of my posts (Q128, etc)

Click to expand...

Thank you. So we can find the settings for a Q128 and for a Bionx IGH3 in the "proven setting" folder of the firmware now.

regards
stancecoke

stancecoke said:

Thank you. So we can find the settings for a Q128 and for a Bionx IGH3 in the "proven setting" folder of the firmware now.

Click to expand...

I hope I'll share "proven setting" for 18FET and 48v 1000w hallomotor soon.

stancecoke said:

geofft said:

Yes, that now works (in German legal manner... ). There is some fairly severe oscillation or 'pulsing' of the drive though. Is the throttle being scaled by pas cadence - maybe that limiting needs smoothing out?

Click to expand...

No, the throttle value is used for the target current in the same way as in throttle-mode. Perhaps you should increase the value of "PAS timeout" to avoid hickups.

To avoid oszillation, you can reduce the values of Gain P (and Gain I), but be aware that the response to the throttle signal will get slower.

Click to expand...

Gain I has proved to be the key parameter for me - reducing this to 0.1 has removed all the oscillation issues in all modes. Throttle response seems perfectly ok at this setting and everything now works very well, motor smooth and quiet - well done!

It's just a shame for me that there is no unrestricted throttle/pas mode. This for me (and many others I suspect) is a major drawback and would mean that I would probably not be able to use this code...

So how about an unrestricted throttle pas mode (and/or add a throttle option to torque simulation..?) That would be very nice....

Updated settings.ini below.

geofft said:

stancecoke said:

geofft said:

Yes, that now works (in German legal manner... ). There is some fairly severe oscillation or 'pulsing' of the drive though. Is the throttle being scaled by pas cadence - maybe that limiting needs smoothing out?

Click to expand...

No, the throttle value is used for the target current in the same way as in throttle-mode. Perhaps you should increase the value of "PAS timeout" to avoid hickups.

To avoid oszillation, you can reduce the values of Gain P (and Gain I), but be aware that the response to the throttle signal will get slower.

Click to expand...

Gain I has proved to be the key parameter for me - reducing this to 0.1 has removed all the oscillation issues in all modes. Throttle response seems perfectly ok at this setting and everything now works very well, motor smooth and quiet - well done!

It's just a shame for me that there is no unrestricted throttle/pas mode. This for me (and many others I suspect) is a major drawback and would mean that I would probably not be able to use this code...

So how about an unrestricted throttle pas mode (and/or add a throttle option to torque simulation..?) That would be very nice....

Updated settings.ini below.

Click to expand...

Or the "secret" switching from throttle active when PAS (to 25km/h?) to throttle always active (to full speed)

geofft said:

Gain I has proved to be the key parameter for me - reducing this to 0.1 has removed all the oscillation issues in all modes. Throttle response seems perfectly ok at this setting and everything now works very well, motor smooth and quiet - well done!

Click to expand...

Great! thank you for tuning the parameters!

geofft said:

So how about an unrestricted throttle pas mode (and/or add a throttle option to torque simulation..?) That would be very nice....

Click to expand...

Does that mean, that you want to override torque-simulation-mode with the throttle and the throttle should have no speed limit?!
A throttle override would be easy to implement, but not legal. I could implement it this way: :wink:
Throttle overrides torque-simulation-mode with speed limit, if pedals are turning. That's legal.

When activating the "offroad" mode, the throttle overrides even with pedals at standstill. The speed limit can be disabled by the morse code already.

regards
stancecoke

stancecoke said:

Does that mean, that you want to override torque-simulation-mode with the throttle and the throttle should have no speed limit?!
A throttle override would be easy to implement, but not legal. I could implement it this way: :wink:
Throttle overrides torque-simulation-mode with speed limit, if pedals are turning. That's legal.

When activating the "offroad" mode, the throttle overrides even with pedals at standstill. The speed limit can be disabled by the morse code already.

regards
stancecoke

Click to expand...

'Yes' to all those suggestions would be fine for me. The throttle option doesn't necessarily have to be added to 'Torque Simulation' mode, it could be added to the existing 'Throttle/pas' mode - or both these modes.
Maybe good to wait for input from honya (and any others) to see if they agree...

geofft said:

The throttle option doesn't necessarily have to be added to 'Torque Simulation' mode, it could be added to the existing 'Throttle/pas' mode - or both these modes.

Click to expand...

??? In "Throttle and PAS" mode it should already work as you want?!
I think the "Torque-Simulation" mode will be the most used mode, here it makes most sense to have a throttle override.

I strongly recomment to try a ride with a torque-sensor-supported bike, you won't miss a throttle in any second, as you legs are operating the "throttle" 8)

regards
stancecoke

stancecoke said:

geofft said:

The throttle option doesn't necessarily have to be added to 'Torque Simulation' mode, it could be added to the existing 'Throttle/pas' mode - or both these modes.

Click to expand...

??? In "Throttle and PAS" mode it should already work as you want?!

Click to expand...

Sometimes, maybe when crossing a busy road junction, it's good to be able to just hit the throttle and go - with the 'throttle and pas' mode you have to wait for pas to trigger which can take a second or so and makes things more difficult. Not a big deal though, if added only to 'torque simulation' mode then that is perfectly ok.

I think the "Torque-Simulation" mode will be the most used mode, here it makes most sense to have a throttle override.

Click to expand...

Yes, as stated, fine for me.

I strongly recomment to try a ride with a torque-sensor-supported bike, you won't miss a throttle in any second, as you legs are operating the "throttle" 8)

Click to expand...

My replacement controller arrived this morning and is being wired for torquesensor operation right now....

My replacement controller arrived this morning and is being wired for torquesensor operation right now....

Click to expand...

Thought I'd finished, but looking at the second photo I've just realised I haven't fitted the ST-link connector....

I finally got my controllers and downloaded and built the tool chain and the project sources (from github) so I can start contributing.
I'm working on Linux, specifically Ubuntu 18.04. My immediate goal is to get all the related projects to build and to document and possibly script the process. If I get this done, I'd like casainho and stancecoke to add or update the documentation to their repos so the next person has an easier time.

I tried to build both the casainho projects and the stancecoke project.

I ran into a couple problems:

The casainho project BMSBattery_S_controllers_firmware is the only one that builds easily. The others: Kunteng_LCD3_firmware and TongSheng_TSDZ2_motor_controller_firmware fail to build because the StdPeriphlib/src directory is missing. It is included in the BMSBattery_S_controllers_firmware project. Once I added it I was able to build all the projects.

May I suggest that you update your projects with the StdPeriphlib that it needs.

The stancecoke/BMSBattery_S_controllers_firmware breaks sdcc. Specifically compiling main.c seg faults in the assembler sdasstm8. I used gdb to track this down and have sent a core file and main.asm as part of a bug report to sdcc. The bug is: #2772 sdasstm8 seg faults on null pointer deref. I'm sort of stuck here for now.

Reading source code I see that all these projects use printf(). printf is almost 2Kb. I'd be happy to submit a patch to avoid printf, or to supply printf_lite() which would have just %d and %s. How should I submit patches?

First, thank you for joning this project!

-dg said:

The stancecoke/BMSBattery_S_controllers_firmware breaks sdcc.

Click to expand...

Have you adapted the Makefile_linux? As nobody used my fork with linux so far, I never updated it. Now I've done it, perhaps you can try again.

-dg said:

Reading source code I see that all these projects use printf(). printf is almost 2Kb. I'd be happy to submit a patch to avoid printf, or to supply printf_lite() which would have just %d and %s. How should I submit patches?

Click to expand...

The print command is only used for debugging and not necessary in normal ride. The communication to the display is done by putchar, this should be much smaller. But of course, you are welcome if you want to improve the code. You have to make the changes in your own fork and then send a pull request. (I've never worked with this also :wink: )

regards
stancecoke

stancecoke said:

First, thank you for joning this project!

-dg said:

The stancecoke/BMSBattery_S_controllers_firmware breaks sdcc.

Click to expand...

Have you adapted the Makefile_linux? As nobody used my fork with linux so far, I never updated it. Now I've done it, perhaps you can try again.

Click to expand...

I did not change Makefile_linux. Even if it is not correct, the compiler should just complain, not crash. So I filed a bug with the sdcc project. I will pull the repo again and try again though.

I'll see about getting the linux set up and builds to work first. I know some people like Windows, but a big attraction of this project is that it is open source. This is more likely to appeal to Linux people than windows people, so I think it is important to getting more developers to have the linux set up be as smooth as possible.

One idea that has come up several times in this thread is to have the configuration adjustable without reflashing. I am thinking we could use the serial interface that connects the LCD to set parameters in both the controller and in the LCD by connecting a serial line. I'm also thinking of building something like a headless Cycle Analyst that could handle things like cruise control or different types of throttle.

To make this useful we would need a protocol to communicate settings that would be more general than the current protocol between the LCD display and the controller. Looking around, I found Modbus https://www.lammertbies.nl/comm/info/modbus.html which is used to send state info and settings between different industrial controllers. It is very simple and would not require much code. The idea is that we could use any serial device like a bluetooth dongle or a USB serial and change settings, or read data back from eiher the controller and the LCD. Since it is addressable we could also use Modbus to handle the LCD to controller communication so if we wanted to provide new displays on the LCD it would be easy to do so in a structured way instead of just taking another byte onto the existing protocol.

Since Modbus has been around since 1979, there are lots of interoperable implementations for Linux and Windows in a variety of languages and for various micro controllers. There are at least a dozen AVR or Arduino packages on github and even a couple for STM8 that could be adapted.

Specifically I am interested in making a multi button throttle for drop bars that would support multiple hand positions and cruise control and power settings without requiring a display. This might be based on one of the $1 STM8S breakout boards connected via the LCD serial to the controller. It would read speed and cadence etc from the controller and the buttons state and then send throttle either via the throttle wire, or even better via Modbus over the serial line. Ideally this device could live on the bars with the brake lever sensors and the throttle buttons and only have the 4 wire serial+power interface to the controller so that it would be fly-by-wire and there would not be such a mess of cable all over the bike.

Is this of any interest? Do I need to explain it better?

-dg said:

Is this of any interest? Do I need to explain it better?

Click to expand...

I had this discussion with casainho in early days of this project already. My aim is to make the firmware usable for unexperienced PC users. 99% will have a windows operating system. 99% will not care if they connect a ST-Link or a USB to UART converter to the controller (they will not know the difference between both devices at all...). Only if there is an android app to do the settings, it would have an advantage to set the parameters via UART. But the user would have to buy two devices, the ST-Link and a bluetooth module...

Feel free to do what ever you want. :wink:

regards
stancecoke

I've now added the throttle override in torque-simulation mode now. I can't test it at the moment, as my normal PAS-Sensor is defective
Throttle without pedaling in offroad mode is not implemented yet.

regards
stancecoke

stancecoke said:

I've now added the throttle override in torque-simulation mode now. I can't test it at the moment, as my normal PAS-Sensor is defective

Click to expand...

Seems to work just fine, many thanks for your time and effort on this.

Throttle without pedaling in offroad mode is not implemented yet.

Click to expand...

We look forward to this full feature version appearing sometime soon.... :wink: