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

[casainho]

With this we should get a PWM frequency of 20.833 kHz (16Mhz / (2*384) = 20.833kHz)

TIM1_TimeBaseInit(0, // TIM1_Prescaler = 0
		    TIM1_COUNTERMODE_CENTERALIGNED1,
		    (384 - 1), // clock = 16MHz; counter period = 384; PWM freq = 16MHz / (384*2) = 20.833kHz;
		    //(BUT PWM center aligned mode needs twice the frequency)
1); // will fire the TIM1_IT_UPDATE at every PWM period

Correct!!
And after you need to verify what is the used time on the PWM cycle code -- I do that using debug_pin_set() and debug_pin_reset(), placing set at begin of interrupt code and reset at the end, then measure on oscilloscope.

We may think that a controller with a STM32Fxxx would have advantage here, but the ones like Lishui does work sensorless and they must implement sensorless algorithm that is heavy math done every PWM cycle code, so in the end, there is also no free time. Also maybe to go from 16khz to 32khz, the hardware may need to change on the mosfets power stage, so it is a really different controller.

I think direct drive motors have low ERPM while geared motors seems to have high ERPM...

 

[casainho]

We should decide, if we want to keep both java tools. I set the pathes in the OSEC Parameter Configurator.jar so it can be run directly from the firmware folder again.

As you may understand, I prefer the tool I built. I changed the Netbeans because Eclipse didn't worked well on my Linux, other way I would prefer to maintain your choice. Also I did maintain the same idea and code you did, the scripts, etc. What I mainly changed was the options, giving less options and also changed to that vertical layout.
The only thing not working well is that question about the scroll that I want to resolve by testing myself on windows.

Also I adopted "Flexible" to the name and not OSEC. Flexible (more than customization) because that is the reality and is the main differentiation point, that others will not be capable, unless they are also OpenSource. See for instance the Lebowski chip firmware, it will never be like what is our firmware, you will never be able to play with the sources and learn with them, like you are doing right now and try change to other PWM frequency!!

 

[geofft]

We should decide, if we want to keep both java tools.

Can I add the 'end user' preference here, I don't like to take sides but for me the OSEC parameter Configurator wins here, pleasing layout and all options quickly available. Even better if these options could be added:-

Input Type: PAS/Throttle 100%.
I think Casainho added this to config.h but would be good to have it in the configurator.

Battery option 12s (a popular choice nowadays) so the LCD3 battery monitor gives meaningful info. I guess however that the current options are maybe fixed by the display firmware and can't be changed...?

Will be checking the flashing option 'repairs' very soon.

 

[stancecoke]

Correct!!
And after you need to verify what is the used time on the PWM cycle code -- I do that using debug_pin_set() and debug_pin_reset(), placing set at begin of interrupt code and reset at the end, then measure on oscilloscope.

I just tried it, it works . I have to adust some constants to get back the right timing in Cadence and Speed measuring. I searched the code a little and found just two lines in the main.h

#define PAS_ABSOLUTE_MAX_CADENCE_PWM_CYCLE_TICKS  (6250 / PAS_NUMBER_MAGNETS) // max hard limit to 150RPM PAS cadence
#define PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS  (156250 / PAS_NUMBER_MAGNETS) // min hard limit to 6RPM PAS cadence

I think, there must be some other lines for speed adjust?
Perhaps we shoud use a central constant for PWM frequency and calculate all refering values from this? That will make it easier to change PWM frequency...

regards
stancecoke

 

[casainho]

I think, there must be some other lines for speed adjust?
Perhaps we shoud use a central constant for PWM frequency and calculate all refering values from this? That will make it easier to change PWM frequency...

Please be aware that will be a big project, to make the possibility for changing PWM frequency and avoid all bugs from the more possible values, for instance, there are variables that are 16 bits that may overflow now and that will be really bad, like having issues on some conditions only and so will be dificult to resolve.

We still don't have current firmware stable, so I think is better for you to create a specific branch and we can keep master with current firmware and try make it stable.

Yes, I think is good idea to depend the calculations from the PWM frequency.

 

[stancecoke]

Of course the change of the PWM-frequency should not be done by a "normal" user. I don't want to make that an option in the java-tool. But I think it is good to offer a solution for Middrives. The Shengyi Middrive that I own has a horrible original firmware for example.
It would be interesting, if Kunteng uses a higher PWM frequency for the SO6SC. Or if just the speedlimit is controlled by the external speed sensor. This version of the S06S is especially for central drives.

Can you tell me please, where in the code the PWM frequency is used to calculate other values?

regards
stanecoke

 

[casainho]

Can you tell me please, where in the code the PWM frequency is used to calculate other values?

Would be great to get pictures of S06C to try understand if is the same microcontroller...
STM8S208CB runs at 24MHz VS 16MHz and is pin compatible: https://opensourceebikefirmware.bitbucket.io/development/Motor_control--STM8S105_Alternatives.html

void calc_wheel_speed (void)
// calc wheel speed in km/h, from external wheel speed sensor
f_wheel_speed = ((float) PWM_CYCLES_SECOND) / ((float) ui16_wheel_speed_sensor_pwm_cycles_ticks); // rps

void TIM1_UPD_OVF_TRG_BRK_IRQHandler(void) __interrupt(TIM1_UPD_OVF_TRG_BRK_IRQHANDLER)
// this division takes 4.4us and without the cast (uint16_t) PWM_CYCLES_SECOND, would take 111us!! Verified on 2017.11.20
ui16_motor_speed_erps = ((uint16_t) PWM_CYCLES_SECOND) / ui16_PWM_cycles_counter_total;


if (ui16_PWM_cycles_counter < ((uint16_t) PWM_CYCLES_COUNTER_MAX))


They must use higher frequency and probably different components on power stage -- see:
- https://opensourceebikefirmware.bitbucket.io/development/Motor_control--PWM_frequency_VS_motor_eRPM.html

 

[stancecoke]

Thank you.

The guy in the german forum want's to try the S06SC with his Yamaha, perhaps he can take some photos.

regards
stancecoke

 

[casainho]

@stancecoke, I have bad news for you.

For instance, duty_cycle table values must be adjusted, from max 255 to 192. Then, other limit values will need to be changed, like max duty_cycle should now be 192 and not 255... I think that change will be big, need to be careful.

That is the limitations of this processor controller optimization for cost, most calcs need to be done with hardcode values. We for sure can done more than their development engineers, because we have more time, but doing more thigs will increase a lot the complexity for debug and testing, getting something stable.

 

[geofft]

So options A, B and C should work now!

A) ... flashing failed with 'can't find main.ihx' error in cmd log.

C) Compiles but fails to flash data with can't find main.hex error in cmd log.

after reading this again, I guess, that you get an error while compiling, as the main.hex / main.ihx can't be found. Can you check the log again?

That's much better now, I still get the same error with option A (log attached) but B and C now work fine, so I can work with those ok.

I've been playing around with the rev pedal issue and have almost (but not completely) eliminated it. I've come to the conclusion that I need to try a different pas sensor before I go any further with this.

Casainho: Haven't forgotten the things you asked me to try re: display comms, etc, but it just got too cold in my garage this afternoon - will try again during the week.

 

[stancecoke]

mdtr from the german forum has posted the photos (really quick service ) of the S06SC

The speed limit works from the external sensor, but the maximum rpms of the chainwheel is just a little bit higher 90-92rpm instead of 86rpm.
So we are signficant faster with the higer PWM frequency

regards
stancecoke

 

[stancecoke]

For instance, duty_cycle table values must be adjusted, from max 255 to 192. Then, other limit values will need to be changed, like max duty_cycle should now be 192 and not 255... I think that change will be big, need to be careful.

I have to think about that. I think, the table values refer to the angle not to the frequency...
I have just changed the one value in the PWM init and the motor ran without problems....

regards
stancecoke

 

[casainho]

What do you mean by "So we are signficant faster with the higer PWM frequency "??

Do you think they are using higher frequency?

How do you guys tested the max speed that controller limits?

If we have just 2 different fixed PWM frequencies, than should be simpler and I can help.

PWM uses a timer that will increase from 0 up to 192!! If you put other values, I guess will work incorrectly.
Higher frequency also means loosing that resolution, from 255 --> 192. But let's go!!

 

[stancecoke]

What do you mean by "So we are signficant faster with the higer PWM frequency "??

How do you guys tested the max speed that controller limits?

With the 15.625 kHz PWM frequency i get a maximum speed of about 86 rpm. With a one-third higer PWM frequency (20.833 kHz) I get the one-third higher speed of 118 rpm. I measured the rpm with a normal speedometer (wheel circumference set to 1.667m) and one magnet on the chainwheel of my Shengyi middrive motor.

regards
stancecoke

 

[stancecoke]

to be honest, I can't follow your argumentation. The timing of the fast loop bases on counting the number of timer interrupts. I think it is not relvant for the commutation at all, how many timer tics it takes to trigger the interrupt... ?!
It's only relevant for calculating the cadence and the speed.

regards
stancecoke

 

[casainho]

to be honest, I can't follow your argumentation. The timing of the fast loop bases on counting the number of timer interrupts. I think it is not relvant for the commutation at all, how many timer tics it takes to trigger the interrupt... ?!
It's only relevant for calculating the cadence and the speed.

Again, I may be misunderstanding. I think you were talking about the limitation of PWM frequency and also limitation of max duty_cycle value.

 

[stancecoke]

That's much better now, I still get the same error with option A (log attached)

Which settings did you choose for the battery option? Only the values 7, 10 or 13 are valid values. I think there must be the bug.

motor.c:966: error 20: Undefined identifier 'ADC_BATTERY_VOLTAGE_MAX'
motor.c:975: error 20: Undefined identifier 'ADC_BATTERY_VOLTAGE_MIN'

regards
stancecoke

 

[stancecoke]

also limitation of max duty_cycle value.

Ahh, now I see:

If the maximum (LOAD) value of the counter is 192 at 20.833kHz PWM frequency, it makes no sense to use higher values for the duty cycle...
But it's easy to scale the table values to this...

regards
stancecoke

 

[geofft]

That's much better now, I still get the same error with option A (log attached)

Which settings did you choose for the battery option? Only the values 7, 10 or 13 are valid values. I think there must be the bug.

I normally use a value of 13, (48v) pretty sure this has worked before. I'll try again tomorrow to see if all the 3 options fail in this way.

 

[casainho]

If the maximum (LOAD) value of the counter is 192 at 20.833kHz PWM frequency, it makes no sense to use higher values for the duty cycle...
But it's easy to scale the table values to this...

See that I considered 256 value, and so I use shift operations:

ui8_temp = (uint8_t) (ui16_value >> 8);

I don't know if they will work with other values.

Maybe here:

  // scale and apply _duty_cycle
  ui8_temp = ui8_svm_table [ui8_sinewave_table_index];
  if (ui8_temp > MIDDLE_PWM_DUTY_CYCLE_MAX)
  {
    ui16_value = ((uint16_t) (ui8_temp - MIDDLE_PWM_DUTY_CYCLE_MAX)) * ui8_duty_cycle;
    ui8_temp = (uint8_t) (ui16_value >> 8);
    ui8_value_a = MIDDLE_PWM_DUTY_CYCLE_MAX + ui8_temp;
  }
  else
  {
    ui16_value = ((uint16_t) (MIDDLE_PWM_DUTY_CYCLE_MAX - ui8_temp)) * ui8_duty_cycle;
    ui8_temp = (uint8_t) (ui16_value >> 8);
    ui8_value_a = MIDDLE_PWM_DUTY_CYCLE_MAX - ui8_temp;
  }

That code does a scale, maybe we can make that code to work on both frequencies and maintain all the code as 255 max value, including the table.

Increasing the ERPM limit is also great for some Q/Cute motors as they are high ERPM, like the ones to use on a 16'' wheel like brompton or other folding ebikes.

 

[casainho]

mdtr from the german forum has posted the photos (really quick service ) of the S06SC

Just added the pictures to development documentation notes.

20.833 kHz?? why don't you try a round value like 21 or 22 kHZ?? -- would be better for the communication of features/documentation.

 

[honya96]

Battery option 12s (a popular choice nowadays) so the LCD3 battery monitor gives meaningful info. I guess however that the current options are maybe fixed by the display firmware and can't be changed...?

Correct, its set by display itself (P5) I think. But still if it affects something, we need also 14s 20s and 16s (in this order) to cover the most.

 

[casainho]

Correct, its set by display itself (P5) I think. But still if it affects something, we need also 14s 20s and 16s (in this order) to cover the most.

P5 is not implemented on our firmware. Currently, only 7, 10 and 13S can be selected. If someone needes other value, we can quickly implement to be chosen on firmware configuration tool.

 

[casainho]

Can I add the 'end user' preference here, I don't like to take sides but for me the OSEC parameter Configurator wins here, pleasing layout and all options quickly available.

Ok, so next time I touch on the configuration tool, I will start to change it to be like OSEC. What do you think about optins to be organized in sections? throttle section, etc?

Casainho: Haven't forgotten the things you asked me to try re: display comms, etc, but it just got too cold in my garage this afternoon - will try again during the week.

Just updated the firmware, it shows now the PAS symbol on LCD when PAS is active.

Since I remember you have 2 issues that you are the only one that can help:
- finding the minimum PAS cadence (avoid the issue of rotating pedals backwards)
- find the correct value for FOC_READ_ID_CURRENT_ANGLE_ADJUST to your motor, as it seems to ask a lot of current and the controller seems to get to much hot

 

[stancecoke]

20.833 kHz?? why don't you try a round value like 21 or 22 kHZ?? -- would be better for the communication of features/documentation.

I wanted a one-third higher speed, so I just calculated 15.625 * 1.3333. So I ended up with the timer load value of 384.
We can use another value, of course.

regards
stancecoke