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

[stancecoke]

Finally, I've managed do figure out which files of cygwin are necessary to run the windows release of 3.7.0

09.04.2018  12:08    <DIR>          ..
27.01.2017  21:13           739.859 bash.exe
20.01.2018  10:24            71.187 cyggcc_s-seh-1.dll
20.02.2015  19:07         1.033.235 cygiconv-2.dll
23.10.2016  08:34            42.515 cygintl-8.dll
05.12.2017  10:25           324.560 cygncursesw-10.dll
13.02.2017  21:45           224.275 cygreadline7.dll
20.01.2018  10:26         1.367.059 cygstdc++-6.dll
02.02.2018  16:18         3.195.569 cygwin1.dll
27.01.2017  21:13           739.859 sh.exe

But I don't know, if it's legal to redistribute these files in our github repository...
Some manual path settings are necessary also, but this could be done automatically in the Start_compiling.bat.
Compiling of the recent master branch works with this.

C:\>sdcc -v
SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390
 3.7.0 #10231 (CYGWIN)
published under GNU General Public License (GPL)

regards
stancecoke

 

[casainho]

Finally, I've managed do figure out which files of cygwin are necessary to run the windows release of 3.7.0.

Some manual path settings are necessary also, this could be done automatically in the Start_compiling.bat, I think.
Compiling of the recent master branch works with this.

So, If I can understand correctly, with SDCC 3.7.0, on Windows and Linux, the master branch compiles correctly, no more that 2 issues!! And also with added improving on firmware code size.

Good work Stancecoke. Would be great if you can write the instructions.
SDCC is GPL license. Our project uses the same kind of license and is on the same philosophy, I am pretty sure is ok for us to share the executable. Also our project is a good example/reference of using such tools.

 

[stancecoke]

The only instruction is to set the right path to the sdcc.exe file in the start_compiling.bat, or to extract it to the right place, that's set in the default start_compiling.bat. (After we have added the necessary files to our repository, I would add them to the \firmware\tools folder)

no more that 2 issues!!

The issue with the #defines is still the same.

regards
stancecoke

 

[casainho]

I would like to implement the wheel speed controller like explained by David Wilson here:


Right now I am "bitbang" current/torque instead of doing a PI controller and I hope it is ok. At least it is very fast as David mention that it should be.

The speed controller (which can be run much slower, right now running at 10Hz) output should be the input for the current/torque controller (using ebike_app_battery_set_current_max()) but currently I am using instead as input for PWM duty_cycle: motor_set_pwm_duty_cycle_target (wheel_speed_pi_controller_state.ui8_controller_output_value);

Why all this work? because I like to also have speed controller working (very well). I hope that implementing speed controller like this way, the PI controller coefficients will be quicker and easy to adjust by the final user.

I think is kind of magic when I feel the machine answering fast and precise to my desires. I mean, when using the torque sensor and I feel that I have refined as also fast control of the machine/bicycle.

 

[stancecoke]

Hmm, I don't now, why we need a speed control, the only thing we need is a smooth reduction of motor power at the speed limit.
Often people report, that it's like riding against a wall when reaching the speed limit...
A proven way to reduce the power smoothly, is ramping down the power within the speedlimit + e.g. 2km/h, like in the FC or in my fork....

regards
Stancecoke

p.s. I've just updated the master branch with the cygwin files and an adapted Start_Compiling.bat
I had to comment out the content of the uart_init function, I hope that causes no trouble with linux....

 

[casainho]

Hmm, I don't now, why we need a speed control, the only thing we need is a smooth reduction of motor power at the speed limit.
Often people report, that it's like riding against a wall when reaching the speed limit...

With a direct drive motor, yes, with the power reduction there will be a wall that is the wind + motor regen.
With a geared motor, yes, with the power reduction there will be a wall that is the wind only and unlike direct drive motor, the motor stops and will disengage from the wheel.

And on current firmware, speed control is optional.

p.s. I've just updated the master branch with the cygwin files and an adapted Start_Compiling.bat
I had to comment out the content of the uart_init function, I hope that causes no trouble with linux....

I updated the uart.h file and it builds ok with SDCC 3.7.0.

 

[stancecoke]

The modified uart.h works with windows, too

The felt "wall" is just the missing "tailwind" if you cut the power apruptly at the speed limit...

regards
stancecoke

 

[casainho]

The felt "wall" is just the missing "tailwind" if you cut the power apruptly at the speed limit...

To control the speed, we would increase (positive) motor torque when speed is lower or decrease (put negative torque for braking) motor torque when speed is higher.
On our ebike application, maybe we should not apply negative torque/brake! On a downhill for instance, after passing the speed limit value, we do not brake the motor. On a geared motor, motor will desingage and will not make resistance/brake. On a direct drive motor, the duty-cycle will increase in a way to keep regen/brake current == zero and so tje motor should also not make resistance/brake.
The only thing braking the rider will be wind or inclination.

I need to try this ideas, but I can only if the rain stops

 

[stancecoke]

I've finally managed to update the windows instructions at bitbucket

https://opensourceebikefirmware.bitbucket.io/windows_instructions/index3.html

Thanks
stancecoke

 

[casainho]

I've finally managed to update the windows instructions at bitbucket

https://opensourceebikefirmware.bitbucket.io/windows_instructions/index3.html

That's great. And I updated the ones on initial site, using your text.

I don't know howto solve that issue of the #defines.

 

[stancecoke]

I don't know howto solve that issue of the #defines.

I suggest to use a

#define LINUX

statement in the config.h for Linux users. I've just updated the Java-Tool at github. I've implemented your latest changes in the config.h as far as I understood them...
The option "Human Power" doesn't work in the code at the moment, there's a variable used, that's not defined...





I have not updated the description of the Java-Tool in the help sites yet.

regards
stancecoke

 

[casainho]

I don't know howto solve that issue of the #defines.

I suppose to use a

#define LINUX

statement in the config.h for Linux users.

I would like to research more, at this issue is not supposed.
Maybe I will ask for help on SDCC mailing list.

 

[stancecoke]

It's a fast workaround. The recent code doesn't work in Throttle/PAS mode for windows users.

Regards
stancecoke

 

[casainho]

Please play with the following change, and try different values for #define EBIKE_THROTTLE_TYPE 0, like 0, 1, 2 or 3.
Maybe try to use instead #if (EBIKE_THROTTLE_TYPE == 1) and #if (EBIKE_THROTTLE_TYPE == 2) instead of EBIKE_THROTTLE_TYPE_THROTTLE_PAS and EBIKE_THROTTLE_TYPE_TORQUE_SENSOR.

It MUST work!!...

#undef EBIKE_THROTTLE_TYPE
#define EBIKE_THROTTLE_TYPE 0
  
#if (EBIKE_THROTTLE_TYPE == EBIKE_THROTTLE_TYPE_THROTTLE_PAS)
  // map throttle value from 0 up to 255 to global variable: ui8_throttle_value
  // setup ui8_is_throttle_released flag
  throttle_read ();
#elif (EBIKE_THROTTLE_TYPE == EBIKE_THROTTLE_TYPE_TORQUE_SENSOR)
  torque_sensor_throttle_read ();
#else
#error
#endif

 

[stancecoke]

Ah, now I found the reason why it doesn't work

If you enable regen, the settings of PAS/THROTTLE and TORQUESENSOR in the config.h are overwritten in the main.h.

So you can set Throttle/PAS only, if regen is not activated. So you can't combine Throttle/PAS with regen at the moment.

regards
stancecoke

 

[casainho]

Ah, now I found the reason why it doesn't work

If you enable regen, the settings of PAS/THROTTLE and TORQUESENSOR in the config.h are overwritten in the main.h.

So you can set Throttle/PAS only, if regen is not activated. So you can't combine Throttle/PAS with regen at the moment.

Ok!! Good to know that is working as expected. So right now there is no issue!!

You mean enable regen like coast brakes. Yes, as I told before, I implemented that feature for me, to use with torque sensor.
By the way, I just received more torque sensors to repair the broken one. Also some LCD3 and so I can look at power used while riding, unlike on LCD5 that I has on my ebikes.

 

[casainho]

On the following test, with #define ADC_BATTERY_CURRENT_MAX 35 on config.h, the measured current with wheel blocked, as seen on the video, I got measured on the multimeter about 12.5 amps:
[youtube]if195JSfAVI[/youtube]

I found that at least on S06S, each ADC 8 bits step equals to 0.35 amps (35*0.35 = 12.25 amps).
The LCD5, each current step equals to 0.25 amps, so I multiply the current ADC 8 bits step value * 1.5 and the LCD shows to me a very near wattage value.

 

[casainho]

Are you aware that you will have to use torque sensor and modding it with a PAS to get that feature you like??

You don't have to add an additional PAS, you just have to solder the yellow wire of the torque-sensor to one of the PAS-Halls directly...

Torque Sensor Hall mod.jpg

Done!! tested and works as expected.

 

[stancecoke]

Done!! tested and works as expected.

Great! So you will adapt the code for not using X4 for the second PAS signal? Then I don't have to do that

regards
stancecoke

 

[casainho]

Done!! tested and works as expected.

Great! So you will adapt the code for not using X4 for the second PAS signal? Then I don't have to do that

This mod is much more easy and clean - thanks.
Yes, I hope the adaptation of the code will be fast, maybe I can do if over the weekend.

 

[casainho]

Done!! tested and works as expected.

Great! So you will adapt the code for not using X4 for the second PAS signal? Then I don't have to do that

This mod is much more easy and clean - thanks.
Yes, I hope the adaptation of the code will be fast, maybe I can do if over the weekend.

This mod doesn't work because the output signal from the sensor is always the same: ui16_pas_on_time_counter > ui16_pas_off_time_counter for both directions, so, there is not way to detect rotation direction. This is probably why they have added hardware/cost.
Any ideas??

 

[stancecoke]

This mod doesn't work because the output signal from the sensor is always the same: ui16_pas_on_time_counter > ui16_pas_off_time_counter for both directions, so, there is not way to detect rotation direction. This is probably why they have added hardware/cost.
Any ideas??

See the code in the main.c of my fork and my posts with the graphs some pages before.

#if defined(TORQUESENSOR) || defined(TORQUE_SIMULATION)
    //	Update cadence, torque and battery current after PAS interrupt occurrence
    if (ui8_PAS_Flag == 1)
    {
      ui16_PAS=ui16_PAS_Counter; 		//save recent cadence
      ui16_PAS_High=ui16_PAS_High_Counter;

#if (PAS_DIRECTION)
      if((float)ui16_PAS/(float)ui16_PAS_High>PAS_THRESHOLD){
	  if (PAS_act<7) {PAS_act++;}
      }
      else{
	  if (PAS_act>0) {PAS_act--;}
      }
#endif

#if (!PAS_DIRECTION)
      if((float)ui16_PAS/(float)ui16_PAS_High<PAS_THRESHOLD){

	  if (PAS_act<7) {PAS_act++;}
      }
      else{
	  if (PAS_act>0) {PAS_act--;}
      }
#endif
      if (PAS_act>3){PAS_dir=1;} //set direction only if enough pulses in the right direction are detected.
      else{PAS_dir=0;}
      ui16_PAS_Counter=1;
      ui16_PAS_High_Counter=1;//reset PAS Counter
      ui8_PAS_Flag =0; 			//reset interrupt flag
      
      ....

If PAS_act < 2 you are pedaling in reverse direction...

I've updated the description of the Java tool at bitbucket now.

regards
stancecoke

 

[casainho]

Should I create a new thread for TSDZ2 motor firmware or use this one??
I think there are more users discussing TSDZ2 motor, maybe there will be even more discussion on that firmware than on Kunteng controllers. On the other side, I don't know if this thread will keep busy as was up to now. I can say my ebikes use Kunteng and I live in flat lands so I think I will not prefer to use TSDZ2 mid drive motor, but for one MTB ebike so I can try to go to some mountains. For Kunteng, I still fell the need of mobile app, because LCD is to limited to change some firmware parameters in real time... and we have some flash memory and ram available that we can use for the Bluetooth/mobile app...

 

[casainho]

The difference is so thin for (float)ui16_PAS/(float)ui16_PAS_High.You used a PAS_THRESHOLD of 1.7 while for what we can see, for my hardware, should be more like 1.55 (left side pedaling forward, right side pedaling backwards):


So, this approach seems problematic, because the user will need to tune PAS_THRESHOLD. Also the rate change of (float)ui16_PAS/(float)ui16_PAS_High is so low and noisy, I think this approach is problematic. So, sorry but I think will not implement (unless I am missing something). I think the other approach of adding another PAS is much more robust and it is also cheap, because a PAS is very cheap. The disadvantage is the user will need to solder an extra wire to the controller, but it should be able to do it anyway since for both of the mods, user needs to solder wires.

This is a mod, means the user need to have some tecnhical skills to do it. I think there is no other way.

This mod doesn't work because the output signal from the sensor is always the same: ui16_pas_on_time_counter > ui16_pas_off_time_counter for both directions, so, there is not way to detect rotation direction. This is probably why they have added hardware/cost.
Any ideas??

See the code in the main.c of my fork and my posts with the graphs some pages before.

#if defined(TORQUESENSOR) || defined(TORQUE_SIMULATION)
    //	Update cadence, torque and battery current after PAS interrupt occurrence
    if (ui8_PAS_Flag == 1)
    {
      ui16_PAS=ui16_PAS_Counter; 		//save recent cadence
      ui16_PAS_High=ui16_PAS_High_Counter;

#if (PAS_DIRECTION)
      if((float)ui16_PAS/(float)ui16_PAS_High>PAS_THRESHOLD){
	  if (PAS_act<7) {PAS_act++;}
      }
      else{
	  if (PAS_act>0) {PAS_act--;}
      }
#endif

#if (!PAS_DIRECTION)
      if((float)ui16_PAS/(float)ui16_PAS_High<PAS_THRESHOLD){

	  if (PAS_act<7) {PAS_act++;}
      }
      else{
	  if (PAS_act>0) {PAS_act--;}
      }
#endif
      if (PAS_act>3){PAS_dir=1;} //set direction only if enough pulses in the right direction are detected.
      else{PAS_dir=0;}
      ui16_PAS_Counter=1;
      ui16_PAS_High_Counter=1;//reset PAS Counter
      ui8_PAS_Flag =0; 			//reset interrupt flag
      
      ....

If PAS_act < 2 you are pedaling in reverse direction...

regards
stancecoke

Thought I might try one of these (T2 version):-
https://www.aliexpress.com/item/torque-sensor-transducer-standard-buttom-bracket-parts-for-electric-scooter-e-bike-motor-assisted-bicycle/32793693999.html
...anybody have any thoughts/comments/experiences with these?

Yes, I've tested the first and the second generation of these Sempu sensors myself, and there's experience with the third generation in the german forum also.
I can recommend this product, but it needs higher supply voltage, you can't use the 5V from the throttle connector. The third generation works with battery volatage directly.

So, which part of PAS code doesn't work? direction detection?

I think so, as the difference between pedaling forward and pedaling reverse is not big with my modded torquesensor, as already shown some pages before, see the orange graph...

regards
stancecoke

 

[stancecoke]

I agree, that there is much scatter in the signal, but the algorithm can handle it. Even with the stock firmware of Lishui and Kunteg, you have to choose the right settings for your specific PAS.
See the slide control for the pas ratio in the Lishui parameter setting tool as example.

Perhaps you can try to remove every second magnet from the PAS disc, then the signal should be much better.

Another smart possibility to avoid an additional PAS is to solder in a 5-core cable und connect the additional wire from the second PAS-Hall to X4. Then you can do the very reliable quadrature signal processing, there are many ready to use libraries available for encoders, e.g. here

Other torque sensors like Thun ore NCTE use this kind of quadrature PAS signal, too.
http://www.ncte.de/download/English/Bicyclesensor_EN_S-BB-RT.pdf

I can imagine, that this kind of PAS sensors are the reason why Kunteng has put the pullup resistor to X4.

Regards
stancecoke