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

[stancecoke]

50A set at tool blew my 8A fuse so I replaced with 20A

Obviously the board revision KT-SVPxx uses a different gain at the OpAmp. So we have to use a diffent calibration factor in the code.

I guess, the R17 is different from 10k on your board.

Does not start the motor with a bit of throttle while icon is showing it should run.

I think this is caused by the offset to negative zero current value, we implemented yesterday to make the motor stop faster.

regards
stancecoke

 

[honya96]

I think this is caused by the offset to negative zero current value, we implemented yesterday to make the motor stop faster.

But we need to be able to block the motor by mechanical brakes right after releasing throttle with direct motor.. as it is now it still pushes half the amp limit in the air to stop the motor in 1 second from full speed.

 

[casainho]

But we need to be able to block the motor by mechanical brakes right after releasing throttle with direct motor.. as it is now it still pushes half the amp limit in the air to stop the motor in 1 second from full speed.

I don't like much the way direct drive motor works with our firmware, but I must say I don't have experience with original firmware or others with direct drive motors.

Can you please explain what you feel that happens while braking with brakes; releasing throttle, etc??
On our firmware, the motor is always "engaged" with the phases always with signal, we never open the phases. When duty_cycle/throttle is 0, there is signal of 50% duty_cycle of PWM signal on each phases, there is why motor is blcoked and is hard to push by hand... If you push, you will be doing regen...

 

[stancecoke]

Hmm, I rode my direct drive with the firmware from the torque-simulation fork only, but that worked definitly better than the original firmware. @honya96: perhaps you can try it, too:
https://github.com/stancecoke/BMSBattery_S_controllers_firmware

It has implemented regen controlled by linear hall input on pad X4 already.

You will not regen at pushing the bike, because the current is always controlled to be zero with no throttle or regen signal.
So the wheel always will turn without resistance...

regards
stancecoke

 

[geofft]

Guys, I'll hold back on any further testing until you've got honya's issues sorted.

I'm beginning to think that life would be easier for everybody if you had separate firmware branches for the geared and direct drive motors...?

 

[casainho]

Hmm, I rode my direct drive with the firmware from the torque-simulation fork only, but that worked definitly better than the original firmware.

That's good to know. Any disadvantages over a geared motor??

 

[casainho]

I'm beginning to think that life would be easier for everybody if you had separate firmware branches for the geared and direct drive motors...?

The thing is that I don't if there are diferencies... What would be different??

 

[honya96]

@Casainho: I know they are always energized, that was the problem with motor not stopping but still trying to turn at 160mA current. I think its good for me that they are energized, cause it allows faster reaction time (which is not there yet at pwm rise - 20) can the current or duty cycle be lowered. so it will take less current while mechanicaly braking with wheel in air? I don't fully understand the problem. Will think about it more.

What you dont like about direct drive with this fw?

@Stancecoke: I guess the torque-simulation will be better from what you wrote.

@Geofft: my reported issues are not important to solve if you dont have them too :wink: so you dont have to wait. I feel like it should be separate for gear or direct also. Or just option in config tool which will change a lot of things.

 

[geofft]

I'm beginning to think that life would be easier for everybody if you had separate firmware branches for the geared and direct drive motors...?

The thing is that I don't if there are diferencies... What would be different??

Was just thinking that changes made for one type may have negative effects on the other. Of course I accept that you guys know best however, if you're happy to develop both types inside the same package then that's fine for me.. :wink:

 

[stancecoke]

@Stancecoke: I guess the torque-simulation will be better from what you wrote.

be careful, with this firmware, the zero current value is not set automatically but is set in the Java Tool OSEC_Parameter_Configurator.jar. So with your obviously different current measuring on your board, you'll have to adjust it. In this firmware, you can set the calibration factor for the gain, too. So with some iterations, you should be able to find the right setting for your controller.

https://www.pedelecforum.de/wiki/doku.php?id=elektrotechnikpen_source_firmware_java_tool

regards
stancecoke

 

[honya96]

@Stancecoke: I guess the torque-simulation will be better from what you wrote.

be careful, with this firmware, the zero current value is not set automatically but is set in the Java Tool OSEC_Parameter_Configurator.jar. So with your obviously different current measuring on your board, you'll have to adjust it. In this firmware, you can set the calibration factor for the gain, too. So with some iterations, you should be able to find the right setting for your controller.

https://www.pedelecforum.de/wiki/doku.php?id=elektrotechnikpen_source_firmware_java_tool

regards
stancecoke

Thanks. As I see its just for kingmeter, so I will try main branch first and then this without display, and wait what you come up with, if the 2 branches will get combined to work from one config tool (btw I like stancecoke's layout more) or stay separate and you will add kt-lcd?

 

[stancecoke]

You can try the torque simulation branch without a display, just to see, if it works better on your direct drive. (without display, level 3 is activated by default)
If it's satisfying for you, we can improve the master branch with this control algorithm. I don't plan to do further development on my fork.

regards
stancecoke

 

[casainho]

If it's satisfying for you, we can improve the master branch with this control algorithm. I don't plan to do further development on my fork.

I agree however I am in a phase that I don't have much time to help on this task.

 

[casainho]

1. Bug report: PAS at 0 runs motor when pedal rotating backwards.
2. slow reaction to throttle and PAS while running and standstill also.
3. Does not start the motor with a bit of throttle while icon is showing it should run.

1. That is no good :-( -- I guess we really need to try increasing the minimum value PAS cadence in main.h file
2. that is because control algorithm of throttle is slow... and we now know it needs better implementation
3. seems good to me to be like that -- I see throttle, brake, etc symbols like kind of safety, you can verify and don't have bad surprises.

 

[geofft]

Bug report: PAS at 0 runs motor when pedal rotating backwards.

Honya, when I had this problem, rather strangely I found it was much worse with 'PAS direction left' selected than it was with right. If you are runnuing PAS left try switching to right (flip the disc over to restore direction) maybe it will help you too...

 

[stancecoke]

mtdr from the German forum has managed to flash the firmware to a KTE-SVP7, but the switch to 60°interpolation doesn't work, and with 6-Step the motor (yamaha middrive) stops after a while :-(
I have no idea how to help at the moment
https://www.pedelecforum.de/forum/index.php?threads/kt-controller-s06s-nicht-f%C3%BCr-jeden-motor-yamaha-pw-geeignet.52697/page-6#post-938489

regards
stancecoke

 

[honya96]

1. Bug report: PAS at 0 runs motor when pedal rotating backwards.
2. slow reaction to throttle and PAS while running and standstill also.
3. Does not start the motor with a bit of throttle while icon is showing it should run.

1. That is no good :-( -- I guess we really need to try increasing the minimum value PAS cadence in main.h file
2. that is because control algorithm of throttle is slow... and we now know it needs better implementation
3. seems good to me to be like that -- I see throttle, brake, etc symbols like kind of safety, you can verify and don't have bad surprises.

1. happens only with assistance 0
3. Its very annoying that it starts only if you turn it 1/3 atleast so it starts and then back off to get the power you desired.

 

[honya96]

Bug report: PAS at 0 runs motor when pedal rotating backwards.

Honya, when I had this problem, rather strangely I found it was much worse with 'PAS direction left' selected than it was with right. If you are runnuing PAS left try switching to right (flip the disc over to restore direction) maybe it will help you too...

Thank you. It means flipping 12 magnets one by one after tearing my PAS apart Its not that big issue now.. I am allready running another bike with direct motor, and trying the torque simulation branch.

 

[casainho]

3. That may happen because of output voltage of your throttle may have a gap considering the values of ADC:
Go to main.h and adapt that values. But first, with throttle connected, measure the min and max voltages with a multimeter.
0 --> 0 volts
255 --> 5 volts

#define ADC_THROTTLE_MIN_VALUE 51
#define ADC_THROTTLE_MAX_VALUE 183

I just went to read again what you wrote before: Does not start the motor with a bit of throttle while icon is showing it should run.
Maybe the issue is with our current control algorithm, I don't know.

 

[casainho]

mtdr from the German forum has managed to flash the firmware to a KT-SVP7, but the switch to 60°interpolation doesn't work, and with 6-Step the motor (yamaha middrive) stops after a while :-(
I have no idea how to help at the moment
https://www.pedelecforum.de/forum/index.php?threads/kt-controller-s06s-nicht-f%C3%BCr-jeden-motor-yamaha-pw-geeignet.52697/page-6#post-938489

"The engine needs a full turn of the crank until it starts" <--- I would say the phases / hall sensors signals do not match as on S06S. Maybe the motor rotates but badly and will never work correctly, if the phases / hall sensors signals do not match.
My advice, go only with S06S and S12S.

 

[stancecoke]

My advice, go only with S06S and S12S.

This advice we would have to give to honya96, too, as he uses a KTE-SVP Board revision also!

regards
stancecoke

 

[geofft]

My estimate here is not scientific, the power maximum the motor draws (indicated on display) with the stock firmware is 800w, but the new firmware is showing 1150w. I can do some better tests with an ammeter in the battery supply if you prefer..?

That would be great, if you can confirm with an external meter.

Tried this 'on the road' today but found that both the readings (ammeter and lcd3 wattmeter) dance around so much that it wasn't possible to get any accurate results, it will need a better test setup than mine to do this.

Would it be possible to point me (and others..) to the number(s) in the code that need to be changed so we can do our own calibrations to the wattmeter?

No rush, anytime will do...

 

[stancecoke]

Would it be possible point me (and others..) to the number(s) in the code that need to be changed so we can do our own calibrations to the wattmeter?

You would have to scale the read value in the ebike_app.c

i8_motor_current_filtered_10b = motor_get_current_filtered_10b ();
  i8_motor_current_filtered_10b -= 1; // try to avoid LCD display about 25W when motor is not running
  if (i8_motor_current_filtered_10b < 0) { i8_motor_current_filtered_10b = 0; } // limit to be only positive value, LCD don't accept regen current value
ui8_tx_buffer [8] = (uint8_t) (i8_motor_current_filtered_10b*120/100);

With the expression *120/100 you would increase the displayed value by 20%.
Casainho has already implemented an offset.

Regards
stancecoke

 

[casainho]

Would it be possible point me (and others..) to the number(s) in the code that need to be changed so we can do our own calibrations to the wattmeter?

You would have to scale the read value in the ebike_app.c

i8_motor_current_filtered_10b = motor_get_current_filtered_10b ();
  i8_motor_current_filtered_10b -= 1; // try to avoid LCD display about 25W when motor is not running
  if (i8_motor_current_filtered_10b < 0) { i8_motor_current_filtered_10b = 0; } // limit to be only positive value, LCD don't accept regen current value
ui8_tx_buffer [8] = (uint8_t) (i8_motor_current_filtered_10b*120/100);

With the expression *120/100 you would increase the displayed value by 20%.
Casainho has already implemented an offset.

Almost there...
i8_motor_current_filtered_10b * 120 will overflow if
i8_motor_current_filtered_10b > 2, because that variables are 8 bits and just hold as max 255.

I saw other tools to customize motor controllers, that user must input values in the form:
x / y.
x and y could be 8 bits and the result would need to be 16 bits variable, because the max of values 255 * 255 is 2^16, so that would be ok.

Sure we could go with floats, but they take a lot of memory space and processing time. I think this 16 bits multiply and division on the STM8 8bits only, without hardware multiply and division, will be better than even doing float operations.

 

[stancecoke]

i8_motor_current_filtered_10b * 120 will overflow

upps, you are right, it's a little strange that you call it _10b, if it's just 8 bit

It's easy to cast the variable into 16bit temporaribly to avoid floating points?!

ui8_tx_buffer [8] = (uint8_t) (((uint16_t) i8_motor_current_filtered_10b)*120/100);

regards
stancecoke

edit: I wonder that you are using a signed integer for the 10 bit current value, as the maximum that this variable can keep is +12.7A only?!