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

I tested again now with the PAS detecting that torque sensor magnets disk but the issue persist.

stancecoke said:
I agree, that there is much scatter in the signal, but the algorithm can handle it. Even with the stock firmware of Lishui and Kunteg, you have to choose the right settings for your specific PAS.
Thanks for the info. I think you are correct and I saw with attention your graph and code. I think is possible but it needs tuning and filtering, as you do in your code. The filtering means it is slow to detect the inversion and it not always happens at the same magnet/pedal position, so the user can always have different results and is no good for what we want to achieve: precise control for ebraking.

stancecoke said:
Perhaps you can try to remove every second magnet from the PAS disc, then the signal should be much better.
These will make a risk to damage the original torque sensor disk, that we can't buy as a spare part: torque sensor $50 VS PAS $2.

stancecoke said:
Another smart possibility to avoid an additional PAS is to solder in a 5-core cable und connect the additional wire from the second PAS-Hall to X4.
Why the need to avoid adding a PAS? PAS costs only $2 and you can buy it at and the same time when you buy this torque sensor.
This new idea will make the need to solder more 5 wires, while using a PAS you don't need to solder.

Also adding the PAS, the code is already developed and tested.

If you need a PAS, please ask me and I can send you one fast, as I bought a few of them as spare parts.
 
I think it's much mechanical work and it looks a little ugly to do the mod in the way you did....

102-2.png


I think there will be no one who wants to copy this :shock: . Soldering in a new cable will take just 15min, looks very clean and the direction detection will be much more reliable.

But in general: There will be only very few users using the combination of a directdrive and this specific torquesensor. Therefore I think it's important, to make regen usable in PAS-Mode without using X4.

regards
stancecoke
 
stancecoke said:
I think it's much mechanical work and it looks a little ugly to do the mod in the way you did....

102-2.png


I think there will be no one who wants to copy this :shock: . Soldering in a new cable will take just 15min, looks very clean and the direction detection will be much more reliable.
For me it's done. I had to do it again because the other torque sensor broke. I reused the cover, that as you say is ugly but I put black tape and I think is good for me.

 
OK, then I will try to port EBrake like Coast Brake to the normal PAS mode. I hope you will accept it and merge it to master if it works.... Perhaps you should switch the wiring in your personal setup to use the additional PAS at the normal PAS connector and put the origin PAS signal of the BMS-Sensor to X4. That would make the feature more universal.

Regards
stancecoke
 
stancecoke said:
OK, then I will try to port EBrake like Coast Brake to the normal PAS mode. I hope you will accept it and merge it to master if it works.... Perhaps you should switch the wiring in your personal setup to use the additional PAS at the normal PAS connector and put the origin PAS signal of the BMS-Sensor to X4. That would make the feature more universal.
Yes and I will review the code. I don't have an ebike with PAS so I will not be able to test.

I am using the PAS wiring of the torque sensor to connect to PAS connector of the controller, I think like this should be the standard.
 
Since I went to the gym, I feel stronger :)
It happen again!! I broke another BMSBattery torque sensor, and this time I know that I didn't to much force with my legs.

3 things:
1. with this ebike, I had that small accident against a car were the pedals got bent and I exchanged for a new ones, maybe torque sensir was fragile after that
2. I am thighting to much the pedals, at least were my last intereaction with the torque sensor on my last ride -- could this be possible??
3. Piece of sh****t this torque sensor

Any idea what can I do to avoid this?? I have another new one that I will put on the bicycle and I would like to avoid this issue.

 
I've just finished the whole thread. Great stuff.

But, if you have had two bottom bracket axles break you should drop support for that sensor as it will kill somebody. Normal bike bottom brackets do not break like this:
20180413_151636.jpg

This one clearly has a design/manufacturing/materials defect and is far to dangerous to encourage anyone to use.
 
casainho said:
Should I create a new thread for TSDZ2 motor firmware or use this one??

I think we should start a new one. What will be the advatange of a custom firmware for the TSDZ2? The implementation of the torquesensor is already done in the original firmware...

regards
stancecoke
 
stancecoke said:
casainho said:
Should I create a new thread for TSDZ2 motor firmware or use this one??

I think we should start a new one. What will be the advatange of a custom firmware for the TSDZ2? The implementation of the torquesensor is already done in the original firmware...
The controller is the same from 36V up to 52V yet users can't program that feature and need to buy the different versions. Also the current, users can't program although there are anfew different versions on the market, still is the same controler.
Also users are asking for some features like current ramp at startup, etc.
 
stancecoke said:
casainho said:
Should I create a new thread for TSDZ2 motor firmware or use this one??

I think we should start a new one.
....I think so too, this thread is already so long that earlier info can be hard to find and I can foresee information getting confused between the two types.

On a different subject I recently downloaded and road tested the latest master branch, and I have to say I was impressed. With my geared motor, riding throttle/pas, (other modes not tested) everything seems to work very well, even the previously troublesome wattmeter and battery bars now seem to give 'correct' readings (LCD3) without having to tweak the code or lookup tables.

Just noticed one small 'glitch' though, often when under full power (800w on my setup, usually using throttle but I think has also happened under pas only) the LCD3 wattmeter reading will suddenly decay down to zero, although the motor is still at full drive. If at this point you release throttle/stop pedalling the motor 'hangs in' at full power for a further 2-3 secs before stopping. Not a big deal but just thought I'd mention it, it can catch you out if it happens at a bad moment.

Anyway, well done guys, this is now starting to feel like a polished and almost finished product. My Sempu torque sensor should be arriving soon, if I can get that working this well I shall be more than happy.
 
Stupid question, but I'm about to buy a few of the KT 36/48 V controllers from pswpower and an LCD3 and LCD5 from bmsbattery along with some motors so I can play with this firmware too. Bmsbattery's website claims the lcd3 and lcd5 are only for the S series controllers. I assume this is not true and that they will work with any KT controller. Has anyone actually tried this? Thanks.
 
geofft said:
Just noticed one small 'glitch' though, often when under full power (800w on my setup, usually using throttle but I think has also happened under pas only) the LCD3 wattmeter reading will suddenly decay down to zero, although the motor is still at full drive. If at this point you release throttle/stop pedalling the motor 'hangs in' at full power for a further 2-3 secs before stopping. Not a big deal but just thought I'd mention it, it can catch you out if it happens at a bad moment.

Anyway, well done guys, this is now starting to feel like a polished and almost finished product. My Sempu torque sensor should be arriving soon, if I can get that working this well I shall be more than happy.
That issue, with P3 = 0 or 1??

About the Sempu torque sensor, is the version that works with 5V?
I may move to that torque sensor. I contacted BMSBattery and I am waiting a response and if it will not be satisfactory, I will then write a note with pictures and the story.
 
-dg said:
Stupid question, but I'm about to buy a few of the KT 36/48 V controllers from pswpower and an LCD3 and LCD5 from bmsbattery along with some motors so I can play with this firmware too. Bmsbattery's website claims the lcd3 and lcd5 are only for the S series controllers. I assume this is not true and that they will work with any KT controller. Has anyone actually tried this? Thanks.
I would hope so as I think firmware is not customized for BMSBattery but a generic for all Kuteng controllers.
 
casainho said:
geofft said:
Just noticed one small 'glitch' though, often when under full power (800w on my setup, usually using throttle but I think has also happened under pas only) the LCD3 wattmeter reading will suddenly decay down to zero, although the motor is still at full drive. If at this point you release throttle/stop pedalling the motor 'hangs in' at full power for a further 2-3 secs before stopping. Not a big deal but just thought I'd mention it, it can catch you out if it happens at a bad moment.

Anyway, well done guys, this is now starting to feel like a polished and almost finished product. My Sempu torque sensor should be arriving soon, if I can get that working this well I shall be more than happy.
That issue, with P3 = 0 or 1??
My P3=1

About the Sempu torque sensor, is the version that works with 5V?
I may move to that torque sensor. I contacted BMSBattery and I am waiting a response and if it will not be satisfactory, I will then write a note with pictures and the story.

If the Aliexpress listing is to be believed, it should be the latest version that operates at 10-60v (i.e. main battery voltage). Probably won't know for sure until I actually receive it however.... :?

I was originally going for the BMSbattery unit along with their associated controller. That way I would have had something working 'straight out of the box', but after your first failure decided to go for the Sempu. Now you've had another fail it looks like it was the right decision.
 
Bought a Q128C 500W with a S12SH 40A controller from BMSB about a month ago, but not used/tested it yet. Just realized from searching ES that this controller might be too powerful for Q128C. I admit I got the S12SN instead of the S12S (which is probably the right choice) because I thought it might be more robust than S12S , but I guess maybe they just differ in how much current they are programmed to put out? After I found this thread (but no time for reading all of it) it got me thinking that I could reprogram the S12SH with the OS firmware and limit the current in that way, ie reprogram my S12SH to be optimized for the Q128C? I have not found S12SH mentioned in this thread, but is my assumption right that all S12S(x) controllers are the same HW (except voltage ratings), only different firmware to suit different current outputs , and therefore can be reprogrammed with the OS firmware?

NB! Although I made a beginner error, I have some electronics/programming experience, and are a lot wiser in terms of DIY e-bike tech after browsing the net for a while, so I'm up for some hacking if that's what it takes :) . If it doesn't work, I just buy a new S12S.
 
bardbe said:
Bought a Q128C 500W with a S12SH 40A controller from BMSB about a month ago, but not used/tested it yet. Just realized from searching ES that this controller might be too powerful for Q128C. I admit I got the S12SN instead of the S12S (which is probably the right choice) because I thought it might be more robust than S12S , but I guess maybe they just differ in how much current they are programmed to put out? After I found this thread (but no time for reading all of it) it got me thinking that I could reprogram the S12SH with the OS firmware and limit the current in that way, ie reprogram my S12SH to be optimized for the Q128C? I have not found S12SH mentioned in this thread, but is my assumption right that all S12S(x) controllers are the same HW (except voltage ratings), only different firmware to suit different current outputs , and therefore can be reprogrammed with the OS firmware?

NB! Although I made a beginner error, I have some electronics/programming experience, and are a lot wiser in terms of DIY e-bike tech after browsing the net for a while, so I'm up for some hacking if that's what it takes :) . If it doesn't work, I just buy a new S12S.
Yes. And even I can tell you how you can measure with a multimeter the current that goes to the motor, so then you will be able to validate the max current.
 
Yes S12Sx should work with the same firmware.

You can choose on the config.h a lower battery current and then mesure as I did, by blocking the wheel and then increase on config.h for the value you need.

[youtube]if195JSfAVI[/youtube]
 
Some ideas for things I would like to improve:

1. Calibrate ui8_adc_battery_current_offset and ui16_adc_motor_current_offset when the motor is stopped. Currently we do the calibration at power up of the system but I can see on the LCD that ui8_adc_battery_current_offset drifts over time. ui8_adc_battery_current_offset is not only important to show to user on LCD for motor consumed power but also for correct regen implementation.

2. Calibrate at power up of the system the ui8_adc_throttle_min_value because right now it is #define ADC_THROTTLE_MIN_VALUE 51 and that seems to depend a bit on hardware. The idea here is to get max sensitivity and range from torque sensor. I wish there was a way to also determine the ui8_adc_throttle_max_value.

3. Adjust motor rotor position angle values and take as reference hall sensor B because we measure phase B current. Rotor position angle zero value should start at top/max value of BEMF measured signal on oscilloscope, line yellow:

25-4.png


Phase B current must be in synchronization with rotor position and at 90º so we can get max torque per amp, max efficiency. This means, as show in the previous image and considering that BEMF middle value don't has the offset of 2.8ms, but 0 offset, that the phase B current middle value must stay at hall sensor phase B signal change. That is what current code does for FOC, looking for phase B current middle value/"zero cross" and keep it synchronized with rotor position(rotor position because of the magnets there).

The idea is to clearly use rotor position starting 0 value on top/max value of BEMF, that we can measure using oscilloscope and that can vary a bit for each motor. After knowing this value, the best angle used at startup (MOTOR_ROTOR_OFFSET_ANGLE) don't need to be defined by the user which is important.
Also with this changes I hope will be easier to follow and understand the implemented "very low resolution FOC", something that is unique on EBike motor controllers, I never saw a reference to this idea and implementation, only for the more expensive and complex FOC.
 
That is great news! Thanks for very quick reply, casainho!
I will try it out when I have set up the bike with the motor. Will test with original firmware to make sure everything works in the first place and then reprogram it with OS firmware. Great effort of you guys from making stuff more configurable, and better performance!
 
I've just uploaded a new branch with improved direction detection on PAS and made Regen like coast brakes availabe in normal PAS/Throttle mode. No wire at X4 is necessary, just a normal PAS at the origin PAS connector.
@casainho: you are right, with your code for handling the PAS signal, the mod of the BMS-Sensor doesn't work. With my interrupt-based handling, it works. Quite strange, but not important, as we won't use this sensor any more, I think....

regards
stancecoke
 
stancecoke said:
I've just uploaded a new branch with improved direction detection on PAS and made Regen like coast brakes availabe in normal PAS/Throttle mode. No wire at X4 is necessary, just a normal PAS at the origin PAS connector.
@casainho: you are right, with your code for handling the PAS signal, the mod of the BMS-Sensor doesn't work. With my interrupt-based handling, it works. Quite strange, but not important, as we won't use this sensor any more, I think....

regards
stancecoke

Will give this a try sometime over the next couple of days and let you know how it goes, but I suspect my non-regen gear motor setup won't tell you too much. Will be interested to try the new PAS detection though, this has always been a bit borderline (on my installation) with the current code.
 
Are you planning to use the java tool? Then I have to update it, too, as there is an additional #define necessary in the config.h for the PAS ratio.

regards
stancecoke
 
stancecoke said:
Are you planning to use the java tool? Then I have to update it, too, as there is an additional #define necessary in the config.h for the PAS ratio.

regards
stancecoke

I normally do the user setup directly in config.h. Do I need add the #define in config.h to set PAS ratio at this time?
 
No, the config.h in the branch works, but if you use the Java Tool, this config.h will be overwritten. If you want to use a display, you have to comment the line

Code:
#define DEBUG_UART


regards
stancecoke.
 
bardbe said:
Great effort of you guys from making stuff more configurable, and better performance!
Thank you for your feedback!!
 
Back
Top