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

[stancecoke]

It's not a problem of interrupt handling but of noise on the signal.

regards
stancecoke

 

[geofft]

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

regards
stancecoke

I've just tried the current commit, but it seems just the same..

Edit: This issue also means that without cheat mode enabled the pas is constantly cutting in and out - I guess this is because the sensed speed is above the set limit...

 

[stancecoke]

We have to debounce the signal by Software.

regards
stancecoke

 

[casainho]

It's not a problem of interrupt handling but of noise on the signal.

Are you guys using an input that is originally used for the speed sensor?

Because using the BMSBattery speed sensors (cheap ones) and also TSDZ2 speed sensors, I never got such issue. The hardware has a low pass filter to filter noise.

 

[geofft]

It's not a problem of interrupt handling but of noise on the signal.

Are you guys using an input that is originally used for the speed sensor?

Because using the BMSBattery speed sensors (cheap ones) and also TSDZ2 speed sensors, I never got such issue. The hardware has a low pass filter to filter noise.

Yes, I'm using an external speed sensor using the 'normal' external speed sensor connector. The 'in hub' sensor (white wire, hall plug) is disconnected at the motor hall plug. I've now got the connecting wire (sensor > controller) routed completely away from all other wiring, but still the speed readout is very erratic.

 

[stancecoke]

I've added debounce now at github. Please try again. If it still doesn't work, please log ui16_SPEED and post the result.

regards
stancecoke

 

[casainho]

I have an issue on TSDZ2 that I think is common to KT firmware. I wish Stancecoke had issues enabled on github and so would be easy to focus this discussion on the issue (I tried but I could not found the discussion about this issue on this long thread).

On TSDZ2 firmware (like on KT firmware), when motor is stopped the wheel/motor is engaged because the motor coils are powered on. If I force to rotate backwards the wheel, I see the torque sensor signal of TSDZ2 to get active while to should not!! The result is that the motor starts strongly to pull forward and this is dangerous as user is not expecting this. I see myself and my girlfriend pushing our bicycles backwards many times and getting this issue.... does this also happens to you guys with KT??

Why is this happening?? On TSDZ2, this happens mainly if I have engaged a low gear that will make to motor rotate fast but at high gear this does not happen. I think the issue is because on regen... maybe the circuit voltage is getting very high and that affects the torque sensor circuit making it working incorrectly.

 

[geofft]

I've added debounce now at github. Please try again. If it still doesn't work, please log ui16_SPEED and post the result.

regards
stancecoke

Still the same I'm afraid, no difference in the speed readout behaviour...

I'll do the logging you asked for tomorrow.

 

[geofft]

I've added debounce now at github. Please try again. If it still doesn't work, please log ui16_SPEED and post the result.

regards
stancecoke

Still the same I'm afraid, no difference in the speed readout behaviour...

I'll do the logging you asked for tomorrow.

stancecoke, ignore this message for now, I've just noticed some strange behaviour during the build and flash of that latest github download and I'm not sure it's actually being flashed. I'll do this again tomorrow with a fresh mind... :?

 

[stancecoke]

On TSDZ2 firmware (like on KT firmware), when motor is stopped the wheel/motor is engaged because the motor coils are powered on. If I force to rotate backwards the wheel, I see the torque sensor signal of TSDZ2 to get active while to should not!!

I never had that issue with my BionX DD and the BMS BB Torque sensor. Why should the sensor "see" any torque while pulling the bike in reverse?
geofft reported the issue in torque-simulation mode, but this has to be a malfunction of the direction detection of the PAS signal.

regards
stancecoke

 

[geofft]

stancecoke, ignore this message for now, I've just noticed some strange behaviour during the build and flash of that latest github download and I'm not sure it's actually being flashed. I'll do this again tomorrow with a fresh mind... :?

Problem was that the fw filename (after being unzipped) contains parenthesis - I had forgotten to rename and remove these.

Anyway, the erratic speedo behaviour remains after your latest changes.

I now have a further problem. The throttle response in the recent downloads (I was using torque sim/throttle, offroad mode) has been very sharp when used from a standstill with little progression. This, unfortunately, has just damaged the controller. hopefully just some blown mosfets, but I wasn't able to complete the download you requested.

So I need to repair this controller and find why the throttle is operating so sharply - it may just be bad user settings, I haven't really checked anything yet.

One step forward, two steps back....

 

[geofft]

On TSDZ2 firmware (like on KT firmware), when motor is stopped the wheel/motor is engaged because the motor coils are powered on. If I force to rotate backwards the wheel, I see the torque sensor signal of TSDZ2 to get active while to should not!!

I never had that issue with my BionX DD and the BMS BB Torque sensor. Why should the sensor "see" any torque while pulling the bike in reverse?
geofft reported the issue in torque-simulation mode, but this has to be a malfunction of the direction detection of the PAS signal.

regards
stancecoke

Yes, I'm still getting this. Trouble is, it's very intermittent and unpredictable in it's nature, making it difficult to diagnose. My current feeling is that it's being caused by slow reverse pas rather than a regen issue. When I get the controller repaired and some time I'll try some tests on this.

 

[stancecoke]

I now have a further problem. The throttle response in the recent downloads (I was using torque sim/throttle, offroad mode) has been very sharp when used from a standstill with little progression. This, unfortunately, has just damaged the controller.

Hmm, strange. The only thing I changed in the last few weeks is the phase current limiting, that should protect the mosfets, not kill them....

it may just be bad user settings, I haven't really checked anything yet.

Yes, please check/post the settings. I'm running the firmware in torque-sensor mode (that has no phase current limit, as the motor can't start from standstill in this mode) and I'm really satisfied at the moment...

regards
stancecoke

 

[geofft]

I now have a further problem. The throttle response in the recent downloads (I was using torque sim/throttle, offroad mode) has been very sharp when used from a standstill with little progression. This, unfortunately, has just damaged the controller.

Hmm, strange. The only thing I changed in the last few weeks is the phase current limiting, that should protect the mosfets, not kill them....

it may just be bad user settings, I haven't really checked anything yet.

Yes, please check/post the settings. I'm running the firmware in torque-sensor mode (that has no phase current limit, as the motor can't start from standstill in this mode) and I'm really satisfied at the moment...

regards
stancecoke

Both green phase mosfets had shorted, controller now ok.
I've attached my config.h, maybe you could cast an eye over it, but I think it's ok.
I'd like to make the throttle a bit less aggresive, I guess reducing Gain P and Gain I should help? Anything else?

 

[stancecoke]

Nothing attached?
I have to check the phase current limiting algorithm I think...
regards
stancecoke

 

[geofft]

Nothing attached?
I have to check the phase current limiting algorithm I think...
regards
stancecoke

Sorry, brain fade... Now attached.
I've tried reducing Gain P to 0.3 and Gain I to 0.1 and the throttle now works smoothly from rest, so I think that problem is now ok.

 

[stancecoke]

Good to hear, that the controller is working again and the throttle behaviour is OK with the new gain settings
In the config.h there are still 0.5 and 0.2, I think this is an old one?

You have defined 500 for max battery current (=18,8A) and 800 for max phase current (=48A) I think these are quite high values for a 6 FET....

regards
stancecoke

 

[geofft]

Good to hear, that the controller is working again and the throttle behaviour is OK with the new gain settings
In the config.h there are still 0.5 and 0.2, I think this is an old one?

Yes, I stored that config.h copy just before I made the Gain I/P changes.

You have defined 500 for max battery current (=18,8A) and 800 for max phase current (=48A) I think these are quite high values for a 6 FET....

I arrived at the phase current figure (800) as this seems to restrict the max power drawn by the motor to around 800 watts. This is plenty for my use and equates to about 17.5A drawn from the battery, I may reduce this a little more. I guess the 48A you mention is the instantaneous figure?

The battery current figure (500) was just a bit of a guess really, the controller was originally rated at 20A max so 18-19A seemed reasonable.

I did manage to take a datalog from a short ride today with some 'interesting' results. I'll post the details of this tomorrow, I can't be bothered with this tonight... :wink:

 

[geofft]

I did manage to take a datalog from a short ride today with some 'interesting' results. I'll post the details of this tomorrow

The printf line that produced this log was:-

printf("%d, %d, %d, %d, %d\r\n", ui16_setpoint, ui16_motor_speed_erps, ui16_BatteryCurrent,ui8_cheat_state, ui16_SPEED);

...I placed the 'ui16_SPEED' parameter you requested at the end of this line, but I doubt that will be much help in this log. The log consists of a short idle section at the start, after this I entered the brake lever code for 'offroad' mode, then a short test ride.

It was immediately clear when riding that things were not well, with the motor cutting in and out at regular intervals. A look at the log with my untrained eye spotted that LVC was constantly being triggered, hence the drive cutting in/out. Not sure why this is happening, the battery isn't particularly low so I guess the battery voltage is being mis-reported in diagnostics mode - or maybe I've made a mistake, there's also some odd looking characters in the log that don't look right.

Anyway, log attached, perhaps you could see what you think... :wink:

 

[stancecoke]

OK, it seems, that the controller is reset by the watchdog all the time. I had that issue too, therefore I switched back to the older commit... I don't know, if it's an issue of the newer SDCC3.7.x We can try to increase the watchdog timeout, but I have to have a look how that works...
Please use %u instead of %d as we want to look at unsigned variables. This avoids the negative values in the printout.

regards
stancecoke

 

[geofft]

Ok, no problem, I'll hold on this for now.

 

[stancecoke]

It's not an issue of the watchdog. I had the same phenomena again this morning, I tried to fix it with different timeouts and even with watchdog completely disabled and with SDCC 3.7.0, but nothing helped. Then I switched back to the latest commit at github and it worked properly again I tried to provoke the issue by changing the code step by step, but it always worked fine. :|
So no idea, what went wrong. Perhaps you can try to start from the latest commit again!
Just one guess is that the BT-module draws too much current and the 5V /3,3V brakes down and force the reset of the processor ?! Can you test that first? Just disconnect the BT-Module and make a test ride...

regards
stancecoke

 

[geofft]

Tried disconnecting the HC-05 5v line (from spare brake connector) but still the same.
I'll try re-downloading and starting again as you suggest.
Please don't spend any more time on this, it all started from from chasing the speedometer error which isn't a great problem in reality.
If I discover any more useful information on this I'll let you know...

 

[casainho]

Tried disconnecting the HC-05 5v line (from spare brake connector) but still the same.
I'll try re-downloading and starting again as you suggest.
Please don't spend any more time on this, it all started from from chasing the speedometer error which isn't a great problem in reality.
If I discover any more useful information on this I'll let you know...

Maybe you can try my branch and see if it works, if works, than that hardware is ok and we will know it works with my code and will be an option. I just say this because you told before that you get not problem with my code.

 

[geofft]

Maybe you can try my branch and see if it works, if works, than that hardware is ok and we will know it works with my code and will be an option. I just say this because you told before that you get not problem with my code.

Casainho, your branch (with my gear motor setup) works pretty much faultlessly and is still the fw I use when I go for a leisure (i.e. non-testing) ride.

Stancecoke's branch also works extremely well, just needs one or two details tidying up then users will have a choice of two very good options.

Obviously there are differences in the way each version operates, e.g. pas/throttle response, extra features, etc, etc. It will be great that users can eventually try both and see which they like best. Who knows, if -dg performs some magic we might even have a third option...