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

[geofft]

I look forward to using my new gadget for real sometime.. :wink:

you can print out ui16_current_cal_b in column 1 instead of dutycycle for example and compare it with the recent current in column three, to see why the motor pushed at standstill...

Stancecoke, I've been trying this using the printf command (main.c):-

#ifdef DIAGNOSTICS
printf("%u, %lu, %u, %u, %u, %u\r\n", ui16_current_cal_b, uint32_current_target, ui16_BatteryCurrent, ui16_PAS, ui16_sum_torque, (uint16_t) ui32_SPEED_km_h);
#endif

...but it fails to compile with this error in the cmd page:-

main.c:465: error 20: Undefined identifier 'uint32_current_target'

...I can't work out why it doesn't like 'uint32_current_target' - can you help?

 

[stancecoke]

Please update to SDCC3.7.1:
https://sourceforge.net/projects/sdcc/files/snapshot_builds/x86_64-w64-mingw32-setup/sdcc-20180802-10495-x64-setup.exe/download

There were some strange errors reported in the german forum with the 3.7.0 revision, too.

regards
stancecoke

 

[stancecoke]

I've experimented a little with using the EEPROM for parameter storage instead of defining them in the config.h
https://github.com/stancecoke/BMSBattery_S_controllers_firmware/tree/EEPROM_experimenting

As an example the speed limit is read from the EEPROM address (offset) 1 in this fork. This gives the possibility to change the parameter by a UART command. The command has four bytes. The first byte is the EEPROM address (offset) the second byte the value, the third byte the stop byte (0x0E, same as in LCD3 protocol) and the fourth the command sign "!" (0x21)

So the command

01 1A 0E 21

sent to the controller via UART will set the limit to 26 km/h.
We could write a little android app that sends the settings to the controller via the HC-05 BT module.
It's a nice gimmik, but means, that we have to flash the firmware, edit the EEPROM initially (could be done with default values automatically by the firmware) buy and connect a BT-Module and install the app on the smartphone.
Is there any interest in this solution?!

regards
stancecoke

 

[casainho]

I've experimented a little with using the EEPROM for parameter storage instead of defining them in the config.h
https://github.com/stancecoke/BMSBattery_S_controllers_firmware/tree/EEPROM_experimenting

As an example the speed limit is read from the EEPROM address (offset) 1 in this fork. This gives the possibility to change the parameter by a UART command. The command has four bytes. The first byte is the EEPROM address (offset) the second byte the value, the third byte the stop byte (0x0E, same as in LCD3 protocol) and the fourth the command sign "!" (0x21)

So the command

01 1A 0E 21

sent to the controller via UART will set the limit to 26 km/h.
We could write a little android app that sends the settings to the controller via the HC-05 BT module.
It's a nice gimmik, but means, that we have to flash the firmware, edit the EEPROM initially (could be done with default values automatically by the firmware) buy and connect a BT-Module and install the app on the smartphone.
Is there any interest in this solution?!

That is good if you want to support LCD3 flexible OpenSource firmware, as I am dping on TSDZ2 firmware, storing the variables on EEPROM.

Also, use CRC8 for UART communications or soon you will start to have errors and bad bugs....

 

[-dg]

I've experimented a little with using the EEPROM for parameter storage instead of defining them in the config.h
https://github.com/stancecoke/BMSBattery_S_controllers_firmware/tree/EEPROM_experimenting

As an example the speed limit is read from the EEPROM address (offset) 1 in this fork. This gives the possibility to change the parameter by a UART command. The command has four bytes. The first byte is the EEPROM address (offset) the second byte the value, the third byte the stop byte (0x0E, same as in LCD3 protocol) and the fourth the command sign "!" (0x21)

So the command

01 1A 0E 21

sent to the controller via UART will set the limit to 26 km/h.
We could write a little android app that sends the settings to the controller via the HC-05 BT module.
It's a nice gimmik, but means, that we have to flash the firmware, edit the EEPROM initially (could be done with default values automatically by the firmware) buy and connect a BT-Module and install the app on the smartphone.
Is there any interest in this solution?!

Nice! I guess I need to hurry up or you will invent Modbus independently This is similar to what I'm working on, but in a more standardized way. But don't let me get in the way, we can merge later.

The Modbus packet format is roughly <slave id> <function code> <register number> <data> .... <crc16>.
The functions include read and write single register, read multiple registers etc. "register" is Modbus terminology but usually means memory, but it could be an ioport, eg adc read depending on how you put it together.

 

[stancecoke]

Thank you, casainho and ~dg, for your feedback, but I think, both of you are not the "typical" user :wink:
My idea was to use the "!" for the command to write a parameter and the "?" for a query. Of course I could add a checksum.
But as there is no feedback from other users, that this UART/Smartphone-App feature could be helpful, I think it's not worth to do the work...
Working with one central tool (the java-tool) may be more comfortable for unexperienced users. You don't have to mess around with BT-Module, installing und using additional tools on the smartphone.

regards
stancecoke

 

[casainho]

Thank you, casainho and ~dg, for your feedback, but I think, both of you are not the "typical" user :wink:
My idea was to use the "!" for the command to write a parameter and the "?" for a query. Of course I could add a checksum.
But as there is no feedback from other users, that this UART/Smartphone-App feature could be helpful, I think it's not worth to do the work...

At least S06S controller hardware is ready for Bluetooth, but still yes, not big interest to use the app.
TSDZ2 hardware do not has Bluetooth but some users want it (including a seller).

Maybe what users want is a good LCD instead.

 

[geofft]

Working with one central tool (the java-tool) may be more comfortable for unexperienced users. You don't have to mess around with BT-Module, installing und using additional tools on the smartphone.

I had no strong feelings for (or against) the BT-smartphone idea, but if forced to express an opinion then I would probably agree with stancecoke's statement (above). I just don't feel that the extra complication and work are justified by the benefits it gives.

 

[kdog]

Sorry if this has been asked before-this thread is huge!
Is the Kt controller compatible with a bafang 850e colour display? The original controller I have with this display is hoplessly weak, and I was thinking of getting a stronger Kt controller.. But only if it's easy to do.
Cheers

 

[stancecoke]

Is the Kt controller compatible with a bafang 850e colour display?

No, only Kingmeter J-LCD and Kunteng LCD3/5 are supported.

regards
stancecoke

 

[kdog]

OK thanks for the info

 

[geofft]

Please update to SDCC3.7.1:
https://sourceforge.net/projects/sdcc/files/snapshot_builds/x86_64-w64-mingw32-setup/sdcc-20180802-10495-x64-setup.exe/download

There were some strange errors reported in the german forum with the 3.7.0 revision, too.

regards
stancecoke

I've now upgraded to SDCC 3.7.2 but unfortunately the compiler's dislike of 'uint32_current_target' did not go away. I've now removed this parameter from the diagnostics 'printf' command (main.c) and it compiles and flashes ok.

you can print out ui16_current_cal_b in column 1 instead of dutycycle for example and compare it with the recent current in column three, to see why the motor pushed at standstill...

There's a problem with this in that when the HC-05 is fitted in place of the display the bike behaves slightly differently (because display settings not being communicated to controller maybe?) For example, the motor seems less inclined to push at standstill or drive forward when being reversed, so the conditions we hope to log data for are being masked.

So all a bit frustrating to be honest, and I've given up with this for the time being. It's not really an issue for me because the change you recommended to auto-zero in adc.c seems to resolve these issues anyway, so it's no great problem... :wink:

 

[stancecoke]

I've now upgraded to SDCC 3.7.2 but unfortunately the compiler's dislike of 'uint32_current_target' did not go away. I've now removed this parameter from the diagnostics 'printf' command (main.c) and it compiles and flashes ok.

please make sure, that the line

extern uint32_t uint32_current_target;

can be found in the update_setpoint.h

There's a problem with this in that when the HC-05 is fitted in place of the display the bike behaves slightly differently

The processor is much more busy with the display connected, as the UART interrupt routine runs with every received byte from the display. I have no experience with the behaviour of the firmware with the display connected, as I use no display...
We could try to make the interrupt routine much leaner, if there is really a need for that.

regards
stancecoke

 

[geofft]

I've now upgraded to SDCC 3.7.2 but unfortunately the compiler's dislike of 'uint32_current_target' did not go away. I've now removed this parameter from the diagnostics 'printf' command (main.c) and it compiles and flashes ok.

please make sure, that the line

extern uint32_t uint32_current_target;

can be found in the update_setpoint.h

Err....no, that line is missing in my installation. I can see it is there in the github download - how did that happen?? This is obviously my problem..

There's a problem with this in that when the HC-05 is fitted in place of the display the bike behaves slightly differently

The processor is much more busy with the display connected, as the UART interrupt routine runs with every received byte from the display. I have no experience with the behaviour of the firmware with the display connected, as I use no display...
We could try to make the interrupt routine much leaner, if there is really a need for that.


regards
stancecoke

That's an interesting point, maybe explains why you sometimes weren't seeing the issues that other users were having?

No real need to change the interrupt routines for me, but may be a benefit if it improves the running of the code? I guess you're the best person to make that decision.

 

[stancecoke]

I've built a very basic android app, that sets the speed limit via bluetooth. It's not looking very professional, but it works :| .
The sourcecode and the .apk can be found at github:
https://github.com/stancecoke/C_ROME-B_APP
It shows the diagnostics output also, but has no logging function.

regards
stancecoke

 

[casainho]

I've built a very basic android app, that sets the speed limit via bluetooth. It's not looking very professional, but it works :| .
The sourcecode and the .apk can be found at github:
https://github.com/stancecoke/C_ROME-B_APP
It shows the diagnostics output also, but has no logging function.

I am amazed with your work!!! Congratulations.

 

[geofft]

I've built a very basic android app, that sets the speed limit via bluetooth. It's not looking very professional, but it works :| .

Nice work! Just a couple of questions:-

I presume you intend to add more adjustable parameters eventually?

Will it ever be possible to use this system and still retain the LCD3?

 

[casainho]

So, more feedback from a long time rider on TSDZ2. As we can see, our OpenSource firmware is very good this wouldn't be possible with the work of all of you guys!! Still there is one issue to improve -- the motor vibration at very low speed. I hope to revisit this issue later.

I think the new firmware has given the motor new life. (...) it feels much more responsive and actually gives you more power as you spin out instead of dropping off like the original firmware. That is what I wanted so it now feels more like the Bosch motor.

Just wanted to share my experience this morning on the first ride in to work after I had calibrated the torque sensor using the new firmware.

The bike is very responsive in fact it doesn't feel like the old bike at all
I am now riding in Level 2 and I was able to back off the main power to 300 W max and happily rode in most of the way at around 200W and 32km/hr with not too much effort. When starting off and with some headwind it would go to 280W but not for long
I kept a good eye on my cadence with was between 60 and 67 most of the time
Pushing a little harder I could ride at 75-78 cadence and it felt really comfortable. Easy to change gears by just backing off the torque a little bit, you don’t need to stop pedalling.
In fact the old firmware would feel like you are hitting a brick wall the faster you peddle but with this firmware it feels like a breath of fresh air. The faster you want to go the more it helps you. (Update the cadence did top out at just over 80 for my 36v motor with 39v but I wouldn’t have hit 80 without trying hard)
When I got right near the end and still had some battery left I pumped the power up to 550W and was able to ride comfortably at 38km/hr with little effort. I would not have been able to do this with the old firmware with a battery that was so low.

So this is a very positive feedback and I interpret that our OpenSource is more efficient/uses less battery energy, while TSDZ2 motor also has more torque!!

The true is that I am not sure that original firmware implements FOC while I did on our OpenSource firmware!! With FOC we get the max torque possible per battery amp!! This means more motor is more efficient/uses less battery energy and has more torque.

What could be improved...

At very lower power and cadence at the start of my journey I experienced some weird noises from the motor, almost like a resonance or electrical noise. I could not figure out what it was but it went away and did not come back again ?? Weird. This did not happen on my way home.

Motor vibration at very low speed
Thanks for this feedback. I am well aware of this and there is not a problem to to motor, only it is different from original firmware. Both original firmware of TSDZ2 and KT motor controllers start with 6 step/block commutation and after switches to Space Vector Modulation. When I did the 6 steps implementation, the switch to Space Vector Modulation had an issue with the current controller... we did discuss this on KT OpenSource firmware and we weren't able to improve this... maybe I can revisit this later.

The switch happens at a specific motor speed ERS and this value is defined on config.h:

#define MOTOR_ROTOR_ERPS_START_INTERPOLATION_60_DEGREES 10

Other users reported that they did lower the value to 1 or even 0 and that vibration disappears and the motor works well as expected. Maybe you want to try that to see if you like.

 

[Lem0n]

Hello guys, so after a lil accident that broke my dropouts and damaged a bit the wires of my motor, I pulled it apart, redid the wires, connected to the controller, and bam nothing. When I twist the accelerator, the motor ain't spinning. I tested with a multimeter all phase, there's a resistance. When I spin the wheel by hand, tension rise. Hall sensor cables were undamaged, and when tested on the connector, tension varies when I spin the wheel, so I think the controller got damaged somehow.
Do you know a way to run a kt36/48 sensorless ? Or any way to spin the motor without the throttle ?

Thank you for your work guys !

 

[stancecoke]

I presume you intend to add more adjustable parameters eventually?

No, I think I won't spend more time in the BT-App, I'm not very experienced with android studio.

Will it ever be possible to use this system and still retain the LCD3?

You would have to use something like the Lishui BT-Module that is just plugged between the controller and the display. It uses the HM-10 BLE module internally and can detect if the LCD is switched on and can switch on the controller by itself.
Using BT and Display just in parallel can't work, as the controller would receive a mess of bytes from both devices at the same time...

so I think the controller got damaged somehow

Sad, to hear, that your controller doesn't work any more... You could check the UART output in diagnostics mode, to see if the throttle signal is processed. I don't know, if honya96 has recent experience with 9/12/18 FET KT-Controllers and our firmware....

regards
stancecoke

 

[geofft]

Using BT and Display just in parallel can't work, as the controller would receive a mess of bytes from both devices at the same time...

I did try this when I made up the HC-05 cable. Wasn't expecting it to work, and, unsurprisingly, it didn't...

 

[stancecoke]

Obvoiusly, something went wrong with one of the latest commits, I've reset the master at github to an older commit. Hopefully everything works again with this.

regards
stancecoke

 

[geofft]

I'm probably doing something dumb but I've run out of things to try, any ideas?

I fear there is too much noise on the signal when the motor is running. You can try to fit a split ferrite to the wire next to the controller. I could filter the signal by software, but to be honest, I have no desire to do that :wink:

You can try a normal speedometer sensor also.

stancecoke, sorry to be a pain in the ar5e but I still can't get rid of the speedo problem (readout rising to max displayable in use).

I've now tried ferrite sleeves on the signal wire, decoupling cap (within the controller) on speed signal line and an external speed sensor. None of these things really get rid of the problem, it seems that the firmware is extremely sensitive to any noise on the speed signal input, or maybe some other issue. I've now tried this with a second controller with the same result.

I guess casainho's f/w must handle the speed signal in a different way as I have no problems when using that, maybe he has some filtering routines in his code, I'm not sure.

I understand this may not be a priority for you, in which case fair enough, I'll live with it - but if you could find time to take a look, that would be great...

 

[stancecoke]

Have you tried the latest commit? I've added some Software filtering some days ago....

regards
stancecoke

 

[casainho]

I guess casainho's f/w must handle the speed signal in a different way as I have no problems when using that, maybe he has some filtering routines in his code, I'm not sure.

I am not doing any filtering!! And the same code is working perfectly for TSDZ2.

If I had to guess, I think that Stancecoke is using a different approach of using interrupts to measure the time between speed sensor pulses. I had problems using many interrupts at the same time before and so I decided to use only the PWM interrupt that runs every 64us and I run there the code to measure the time between speed sensor pulses -- this is my suggestion and my code is easy to copy-paste, I also think is well documented/commented/is easy to understand:

Code that runs every PWM cycle / 64us:

  /****************************************************************************/
  // calc wheel speed sensor timming between each positive pulses, in PWM cycles ticks
  ui16_wheel_speed_sensor_counter++;

  // detect wheel speed sensor signal changes
  if (WHEEL_SPEED_SENSOR__PORT->IDR & WHEEL_SPEED_SENSOR__PIN) { ui8_wheel_speed_sensor_state = 1; }
  else { ui8_wheel_speed_sensor_state = 0; }

  if (ui8_wheel_speed_sensor_state != ui8_wheel_speed_sensor_state_old) // wheel speed sensor signal did change
  {
    ui8_wheel_speed_sensor_state_old = ui8_wheel_speed_sensor_state;

    if (ui8_wheel_speed_sensor_state == 1) // consider only when wheel speed sensor signal transition from 0 to 1
    {
      ui16_wheel_speed_sensor_pwm_cycles_ticks = ui16_wheel_speed_sensor_counter;
      ui16_wheel_speed_sensor_counter = 0;
      ui8_wheel_speed_sensor_is_disconnected = 0;
    }
  }

  // limit min wheel speed
  if (ui16_wheel_speed_sensor_counter > ((uint16_t) WHEEL_SPEED_SENSOR_MIN_PWM_CYCLE_TICKS))
  {
    ui16_wheel_speed_sensor_pwm_cycles_ticks = (uint16_t) WHEEL_SPEED_SENSOR_MIN_PWM_CYCLE_TICKS;
    ui16_wheel_speed_sensor_counter = 0;
    ui8_wheel_speed_sensor_is_disconnected = 1;
  }
  /****************************************************************************/

And the code that runs at every 100ms and calc the wheel speed using as input the measured time between speed sensor pulses: ui16_wheel_speed_sensor_pwm_cycles_ticks

void calc_wheel_speed (void)
{
  uint32_t ui32_temp;
  uint32_t ui32_temp1;

  if (ui8_wheel_speed_sensor_is_disconnected)
  {
    // calc wheel speed in km/h, from motor hall sensors signals
    ui32_temp = ((uint32_t) (lcd_configuration_variables.ui8_motor_characteristic >> 1)) * 1000;
    ui32_temp1 = ((uint32_t) ui16_motor_get_motor_speed_erps ()) * 3600;
    f_wheel_speed = ((float) ui32_temp1) * f_wheel_perimeter;
    // avoid 0 division
    if (ui32_temp > 0) { f_wheel_speed /= (float) ui32_temp; }
  }
  else
  {
    // calc wheel speed in km/h, from external wheel speed sensor
    // avoid 0 division
    if (ui16_wheel_speed_sensor_pwm_cycles_ticks > 0) { f_wheel_speed = ((float) PWM_CYCLES_SECOND) / ((float) ui16_wheel_speed_sensor_pwm_cycles_ticks); } // rps
    else { f_wheel_speed = (float) PWM_CYCLES_SECOND; }
    f_wheel_speed *= f_wheel_perimeter; // meters per second
    f_wheel_speed *= 3.6; // kms per hour
  }

  ui8_wheel_speed = ((uint8_t) f_wheel_speed);
}