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

I am thinking in implement a power controller, like let's say in assist level 1 max power usage is 100w, 2 200w, ..., level 5 500w. This way I could plan a travel...

Maybe configure on LCD my trip planned total distance and power available on battery, controller would provide available power per km. Maybe a fixed power per km or adapting remaining power for for remaining km. Is this crazy idea??
We have kms travaled from the wheel sensor and used power from battery measure current and voltage, the rest is math...
 
casainho said:
geofft said:
Just an thought....we've found from previous tests and issues that there seems to be an -0.06v offset between the actual battery cell voltage and that seen by the firmware. That's not much, but it's enough to play havoc with the battery monitor.

Maybe an idea to put the 'correct' voltages in that table but build in a hidden -0.06v offset before they are presented to the code. That way the 'correct' voltages would maybe work for most users, and they would also be presented with voltages that make sense in the accepted 'SOC vs voltage' graph of lipo chemistry.

Please find and test a value for ADC_BATTERY_VOLTAGE_K, that is defined on main.h, that will give the exact voltage. Then I will update ADC_BATTERY_VOLTAGE_K.

See that you are talking in a difference of about 0.06v while each ADC unit represents 0.2652 volts...

Ok, I *think* I understand - I would need to:-

a) Place 'normal' values in the lookup table (from lipo SOC/voltage table)

b) Change the value of #define ADC_BATTERY_VOLTAGE_K 68 // S06S.. etc...

.....(currently 68..?) until it produces the required result with the battery bars. Is that correct?
 
Maybe the wrong thread but you guys probably know the answer

If i increase my phase wire thickness a lot from the axle to my controller will it increase my phase current?
 
tolkaNo said:
Maybe the wrong thread but you guys probably know the answer

If i increase my phase wire thickness a lot from the axle to my controller will it increase my phase current?
Maybe nothing expressive. Just increase on our firmware the value of battery and phase current.
 
casainho said:
tolkaNo said:
Maybe the wrong thread but you guys probably know the answer

If i increase my phase wire thickness a lot from the axle to my controller will it increase my phase current?
Maybe nothing expressive. Just increase on our firmware the value of battery and phase current.

I have stock fw
 
tolkaNo said:
Maybe the wrong thread but you guys probably know the answer

If i increase my phase wire thickness a lot from the axle to my controller will it increase my phase current?

The answer is no. From what I know.

Stock fw is measuring only one current and its something between phase and battery current.

Beefing the shunt will increase both phase and battery current.

Thicker cable will give you like 0.5% increase. Nothing you can feel.
 
geofft said:
Do you know how the battery is monitored down at hardware level? From the schematics I see the pin 24 with an analog input from the battery, is it just reading the raw voltage directly from the battery there, and then sent already converted to digital via the TX RX pins to the display ?

Looking at the schematic, the raw supply voltage is fed onto the top of a potential divider network (R61,R66) which reduces it down to 8% of it's full value. This, as you say, is fed to pin 24 of the STM8.
After that these guys can tell you much more than I can.... :?

I have been researching a bit further.
I think the value is divided down(through the divider network you mentioned) to somewhere below 4V.

The cpu seems to be getting right the Van, so I guess my controller is fine, just that without any real load it is not calculating any voltage. I will have to test with a real motor connected.
 
Hi all,

Cool project! I recently purchased a 1000W front hub motor eBike conversion kit from eBay which I'm enjoying, but am looking to upgrade the controller, partly because I need better brakes, but mostly because I think it'd be fun to play with. Can you recommend a compatible controller that will run at 48V to get me started?

Thanks in advance,
Jethro
 
jethro said:
Hi all,

Cool project! I recently purchased a 1000W front hub motor eBike conversion kit from eBay which I'm enjoying, but am looking to upgrade the controller, partly because I need better brakes, but mostly because I think it'd be fun to play with. Can you recommend a compatible controller that will run at 48V to get me started?
BMSBAttery S12S controller of 25A.
 
Tried the latest master branch earlier, a couple of points that need a mention:-

1) Throttle is still restricted to about 50% in 'Full throttle mode', works as expected in 'Throttle scaled by pas' mode.

2) PAS cutoff when you stop pedalling is a bit too slow, taking around 2 secs. When you're not ready for this it can push you forward several metres further than you intended and has caught me out on a couple of occasions, could do with some adjustment here.

...otherwise all seems pretty good, having battery monitor voltages now available in config.h is a nice touch, will make adjustment a lot easier.
 
geofft said:
Tried the latest master branch earlier, a couple of points that need a mention:-

1) Throttle is still restricted to about 50% in 'Full throttle mode', works as expected in 'Throttle scaled by pas' mode.
Can you please look at ADC_THROTTLE_MAX_VALUE, as see if that value on main.h correspond to your throttle max voltage value??

Hmmm, the current code should scale from 0 to 255:
Code:
void throttle_read (void)
{
  // read torque sensor signal
  ui8_throttle_value = UI8_ADC_THROTTLE;

  throttle_value_remove_offset (&ui8_throttle_value);

  // map throttle value from 0 up to 255
  ui8_throttle_value = (uint8_t) (map (
      ui8_throttle_value,
      (uint8_t) 0,
      (uint8_t) ADC_THROTTLE_MAX_VALUE,
      (uint8_t) 0,
      (uint8_t) 255));

geofft said:
2) PAS cutoff when you stop pedalling is a bit too slow, taking around 2 secs. When you're not ready for this it can push you forward several metres further than you intended and has caught me out on a couple of occasions, could do with some adjustment here.
Although I don't use PAS mode, the torque sensor code depends on PAS to stop the torque signal as the torque signal can be continuous if I press the pedals at rest (which I do) without rotating them. On latest code I also found this cutoff and I don't like it, because before I had a faster response from the system. I am pretty sure this is due to the filtering on the added Stancecoke code, it is something I thought and told before - I think there is no way to filter like that and still have a fast response. I think the feature brake like coast brakes should not work now because it can't have such delay.

The true is that PAS code need careful and refined debug and development... or we just stick with actual implementation and live with that delay.
 
casainho said:
I am pretty sure this is due to the filtering on the added Stancecoke code

The PAS timeout has nothing to do with the filtering. The candence is immediately set to zero, if the PAS counter is bigger than PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS.

Code:
if (ui16_pas1_counter > ((uint16_t) PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS))
    {
      ui16_pas1_pwm_cycles_ticks = (uint16_t) PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS;
      ui16_pas1_counter = 0;
      ui16_pas1_on_time_counter = 0;
      ui16_pas1_off_time_counter = 0;
      ui8_pas1_direction = 1;
      PAS_act=3;
#if (EBIKE_THROTTLE_TYPE == EBIKE_THROTTLE_TYPE_TORQUE_SENSOR)
      ui8_torque_sensor_throttle_processed_value = 0;
#endif
  }


Code:
if (ui16_pas1_pwm_cycles_ticks >= ((uint16_t) PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS)) { ui8_pas1_cadence_rpm = 0; }
  else
  {
    f_temp = ((float) ui16_pas1_pwm_cycles_ticks) * ((float) PAS_NUMBER_MAGNETS) * 0.000064;
    // avoid division by 0
    if (f_temp != 0) { ui8_pas1_cadence_rpm = (uint8_t) (60.0 / f_temp); }
    else { ui8_pas1_cadence_rpm = 60; }

    if (ui8_pas1_cadence_rpm > ((uint8_t) PAS_MAX_CADENCE_RPM))
    {
      ui8_pas1_cadence_rpm = ((uint8_t) PAS_MAX_CADENCE_RPM);
    }
  }

If the cadence is zero, the current target is zero also.

Code:
 ui8_temp = (uint8_t) (map ((uint32_t) ui8_pas1_cadence_rpm,
		 (uint32_t) 0,
		 (uint32_t) PAS_MAX_CADENCE_RPM,
		 (uint32_t) 0,
		 (uint32_t) 255));

#if !defined(EBIKE_THROTTLE_TYPE_THROTTLE_PAS_ASSIST_LEVEL_PAS_ONLY)
  ui8_temp = ui8_max (ui8_throttle_value_filtered, ui8_temp); // use the max value from throttle or pas cadence
#endif

  f_temp = (float) (((float) ui8_temp) * f_get_assist_level ());

#if !defined(EBIKE_THROTTLE_TYPE_THROTTLE_PAS_ASSIST_LEVEL_PAS_ONLY)
  ui8_throttle_pas_target_value = (uint8_t) f_temp;
#else
  ui8_temp = ui8_max (ui8_throttle_value_filtered, (uint8_t) f_temp); // use the max value from throttle or (pas cadence * assist level)
#endif

  ui8_target_current = (uint16_t) (map ((uint32_t) ui8_temp,
			   (uint32_t) 0, // min input value
			   (uint32_t) 255, // max input value
			   (uint32_t) 0, // min output battery current value
			   (uint32_t) ui8_battery_controller_max_current));  // max output battery current value

The delay for power cut off after stop pedaling is influenced by the parameters:
- PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS
- PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP
I wonder that there's no PI-controller for the battery-current in the recent code any longer?!

regards
stancecoke
 
casainho said:
geofft said:
Tried the latest master branch earlier, a couple of points that need a mention:-

1) Throttle is still restricted to about 50% in 'Full throttle mode', works as expected in 'Throttle scaled by pas' mode.
Can you please look at ADC_THROTTLE_MAX_VALUE, as see if that value on main.h correspond to your throttle max voltage value??

Some numbers for my throttle:-
Supply 4.32v
Throttle min 0.86v
Throttle max 3.57v
ADC_THROTTLE_MAX_VALUE (thr/pas) is 229

I think they look ok..?

geofft said:
2) PAS cutoff when you stop pedalling is a bit too slow, taking around 2 secs. When you're not ready for this it can push you forward several metres further than you intended and has caught me out on a couple of occasions, could do with some adjustment here.
Casainho wrote:
Although I don't use PAS mode, the torque sensor code depends on PAS to stop the torque signal as the torque signal can be continuous if I press the pedals at rest (which I do) without rotating them. On latest code I also found this cutoff and I don't like it, because before I had a faster response from the system. I am pretty sure this is due to the filtering on the added Stancecoke code, it is something I thought and told before - I think there is no way to filter like that and still have a fast response. I think the feature brake like coast brakes should not work now because it can't have such delay.

The true is that PAS code need careful and refined debug and development... or we just stick with actual implementation and live with that delay.

I'm not sure people are gonna like that delay, it's just a bit too long and could create dangerous situations. I'm sure you guys will come up with a solution.
 
geofft said:
I'm not sure people are gonna like that delay, it's just a bit too long and could create dangerous situations. I'm sure you guys will come up with a solution.

Have you tried to reduce PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS (main.h) and/or PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP (config.h) already?

regards
stancecoke
 
stancecoke said:
geofft said:
I'm not sure people are gonna like that delay, it's just a bit too long and could create dangerous situations. I'm sure you guys will come up with a solution.

Have you tried to reduce PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS (main.h) and/or PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP (config.h) already?

regards
stancecoke

PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP (config.h) - only seems to change how the motor ramps down at the end of the 2 sec delay, the delay itself remains.

PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS (main.h) - I haven't tried changing this (in relation to this issue) as yet, will do so a little later and let you know.
 
stancecoke said:
casainho said:
I am pretty sure this is due to the filtering on the added Stancecoke code

The PAS timeout has nothing to do with the filtering. The candence is immediately set to zero, if the PAS counter is bigger than PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS.
I felt this change after the change to PAS. Although I think I didn't changed the code, it could happen.

I am being busy with FOC angle that is why I didn't looked at PAS code. FOC, I think one issue was that I measured with oscilloscope BEMF but my geared motor rotating backwards and seem that forwards, BEMF changes +90 degrees. But I still have some issue with the code....
 
geofft said:
casainho said:
geofft said:
Tried the latest master branch earlier, a couple of points that need a mention:-

1) Throttle is still restricted to about 50% in 'Full throttle mode', works as expected in 'Throttle scaled by pas' mode.
Can you please look at ADC_THROTTLE_MAX_VALUE, as see if that value on main.h correspond to your throttle max voltage value??

Some numbers for my throttle:-
Supply 4.32v
Throttle min 0.86v
Throttle max 3.57v
ADC_THROTTLE_MAX_VALUE (thr/pas) is 229

I think they look ok..?

3.57V is 182, so your throttle never reaches the 229.
 
Just had a short road test, looks like both problems are now sorted... :D

Reduced PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS (main.h) to 50000 and PAS now quits very quickly. I guess there must be some limiting factor to how low you can go with this setting?

Changed ADC_THROTTLE_MAX_VALUE to 182 and I now have full throttle.

Many thanks guys, for us throttle/pas riders this is looking close to finished now.
 
Good to ear!! Very happy the PAS is also reacting fast.

Next thing I would like to try is to setup on LCD power levels instead of current levels, as this helps manage the battery range. Also means that when battery starts to drop the voltage, we should keep anyway the same assist level.

Also battery SOC, maybe improving depending on the current being draw.
 
casainho said:
Good to ear!! Very happy the PAS is also reacting fast.

Next thing I would like to try is to setup on LCD power levels instead of current levels, as this helps manage the battery range. Also means that when battery starts to drop the voltage, we should keep anyway the same assist level.

Also battery SOC, maybe improving depending on the current being draw.

These would be really nice extra features. I think you are also waiting for some info from me re: wattmeter calibration, (still only reads 2/3 'correct' value), will try to do this tomorrow.
 
geofft said:
Reduced PAS_ABSOLUTE_MIN_CADENCE_PWM_CYCLE_TICKS (main.h) to 50000 and PAS now quits very quickly. I guess there must be some limiting factor to how low you can go with this setting?
If you set a value that is too small, the engine will start and stop continuously with very small candence. You can just try out, what value is comfortable for you.

regards
stancecoke
 
Had a request for a video showing wattmeter error a while back, so here goes:-

https://www.youtube.com/watch?v=ztBQEd5Ex7E

It's a bit hard to judge but I reckon the average battery current is about 8.5A, subtract 0.15A idle current gives around 8.35A.
Average wattmeter reading is about 235w
Battery voltage during test sags to 44.5v

So 'actual' wattage is (roughly) about 370w, indicated wattage around 235w, so only about 63-64% of the measured value. In reality increasing the displayed figure by 50% would probably be good enough.

BTW - the loud noise on the video is the tyre against the roller of the training stand, glad my motor doesn't actually sound like that... :shock:
 
geofft said:
Had a request for a video showing wattmeter error a while back, so here goes:-

https://www.youtube.com/watch?v=ztBQEd5Ex7E

It's a bit hard to judge but I reckon the average battery current is about 8.5A, subtract 0.15A idle current gives around 8.35A.
Average wattmeter reading is about 235w
Battery voltage during test sags to 44.5v

So 'actual' wattage is (roughly) about 370w, indicated wattage around 235w, so only about 63-64% of the measured value. In reality increasing the displayed figure by 50% would probably be good enough.

BTW - the loud noise on the video is the tyre against the roller of the training stand, glad my motor doesn't actually sound like that... :shock:
Ok, I will a coeficient to config.h. What is you controller reference??
 
Back
Top