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

[stancecoke]

This mod doesn't work because the output signal from the sensor is always the same: ui16_pas_on_time_counter > ui16_pas_off_time_counter for both directions, so, there is not way to detect rotation direction. This is probably why they have added hardware/cost.
Any ideas??

See the code in the main.c of my fork and my posts with the graphs some pages before.

Code: Select all

#if defined(TORQUESENSOR) || defined(TORQUE_SIMULATION)
    //	Update cadence, torque and battery current after PAS interrupt occurrence
    if (ui8_PAS_Flag == 1)
    {
      ui16_PAS=ui16_PAS_Counter; 		//save recent cadence
      ui16_PAS_High=ui16_PAS_High_Counter;

#if (PAS_DIRECTION)
      if((float)ui16_PAS/(float)ui16_PAS_High>PAS_THRESHOLD){
	  if (PAS_act<7) {PAS_act++;}
      }
      else{
	  if (PAS_act>0) {PAS_act--;}
      }
#endif

#if (!PAS_DIRECTION)
      if((float)ui16_PAS/(float)ui16_PAS_High<PAS_THRESHOLD){

	  if (PAS_act<7) {PAS_act++;}
      }
      else{
	  if (PAS_act>0) {PAS_act--;}
      }
#endif
      if (PAS_act>3){PAS_dir=1;} //set direction only if enough pulses in the right direction are detected.
      else{PAS_dir=0;}
      ui16_PAS_Counter=1;
      ui16_PAS_High_Counter=1;//reset PAS Counter
      ui8_PAS_Flag =0; 			//reset interrupt flag
      
      ....

If PAS_act < 2 you are pedaling in reverse direction...

I've updated the description of the Java tool at bitbucket now.

regards
stancecoke

[casainho]

Should I create a new thread for TSDZ2 motor firmware or use this one??
I think there are more users discussing TSDZ2 motor, maybe there will be even more discussion on that firmware than on Kunteng controllers. On the other side, I don't know if this thread will keep busy as was up to now. I can say my ebikes use Kunteng and I live in flat lands so I think I will not prefer to use TSDZ2 mid drive motor, but for one MTB ebike so I can try to go to some mountains. For Kunteng, I still fell the need of mobile app, because LCD is to limited to change some firmware parameters in real time... and we have some flash memory and ram available that we can use for the Bluetooth/mobile app...

[casainho]

The difference is so thin for (float)ui16_PAS/(float)ui16_PAS_High.You used a PAS_THRESHOLD of 1.7 while for what we can see, for my hardware, should be more like 1.55 (left side pedaling forward, right side pedaling backwards):


So, this approach seems problematic, because the user will need to tune PAS_THRESHOLD. Also the rate change of (float)ui16_PAS/(float)ui16_PAS_High is so low and noisy, I think this approach is problematic. So, sorry but I think will not implement (unless I am missing something). I think the other approach of adding another PAS is much more robust and it is also cheap, because a PAS is very cheap. The disadvantage is the user will need to solder an extra wire to the controller, but it should be able to do it anyway since for both of the mods, user needs to solder wires.

This is a mod, means the user need to have some tecnhical skills to do it. I think there is no other way.

This mod doesn't work because the output signal from the sensor is always the same: ui16_pas_on_time_counter > ui16_pas_off_time_counter for both directions, so, there is not way to detect rotation direction. This is probably why they have added hardware/cost.
Any ideas??

See the code in the main.c of my fork and my posts with the graphs some pages before.

Code: Select all

#if defined(TORQUESENSOR) || defined(TORQUE_SIMULATION)
    //	Update cadence, torque and battery current after PAS interrupt occurrence
    if (ui8_PAS_Flag == 1)
    {
      ui16_PAS=ui16_PAS_Counter; 		//save recent cadence
      ui16_PAS_High=ui16_PAS_High_Counter;

#if (PAS_DIRECTION)
      if((float)ui16_PAS/(float)ui16_PAS_High>PAS_THRESHOLD){
	  if (PAS_act<7) {PAS_act++;}
      }
      else{
	  if (PAS_act>0) {PAS_act--;}
      }
#endif

#if (!PAS_DIRECTION)
      if((float)ui16_PAS/(float)ui16_PAS_High<PAS_THRESHOLD){

	  if (PAS_act<7) {PAS_act++;}
      }
      else{
	  if (PAS_act>0) {PAS_act--;}
      }
#endif
      if (PAS_act>3){PAS_dir=1;} //set direction only if enough pulses in the right direction are detected.
      else{PAS_dir=0;}
      ui16_PAS_Counter=1;
      ui16_PAS_High_Counter=1;//reset PAS Counter
      ui8_PAS_Flag =0; 			//reset interrupt flag
      
      ....

If PAS_act < 2 you are pedaling in reverse direction...

regards
stancecoke

Thought I might try one of these (T2 version):-
https://www.aliexpress.com/item/torque- ... 93999.html
...anybody have any thoughts/comments/experiences with these?

Yes, I've tested the first and the second generation of these Sempu sensors myself, and there's experience with the third generation in the german forum also.
I can recommend this product, but it needs higher supply voltage, you can't use the 5V from the throttle connector. The third generation works with battery volatage directly.

So, which part of PAS code doesn't work? direction detection?

I think so, as the difference between pedaling forward and pedaling reverse is not big with my modded torquesensor, as already shown some pages before, see the orange graph...



regards
stancecoke

[stancecoke]

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.
See the slide control for the pas ratio in the Lishui parameter setting tool as example.



Perhaps you can try to remove every second magnet from the PAS disc, then the signal should be much better.

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. Then you can do the very reliable quadrature signal processing, there are many ready to use libraries available for encoders, e.g. here

Other torque sensors like Thun ore NCTE use this kind of quadrature PAS signal, too.
http://www.ncte.de/download/English/Bic ... -BB-RT.pdf

I can imagine, that this kind of PAS sensors are the reason why Kunteng has put the pullup resistor to X4.

Regards
stancecoke

[casainho]

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

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.

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.

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.

[stancecoke]

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



I think there will be no one who wants to copy this . 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

[casainho]

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



I think there will be no one who wants to copy this . 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.

[stancecoke]

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

[casainho]

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.

[casainho]

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.

[-dg]

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:

This one clearly has a design/manufacturing/materials defect and is far to dangerous to encourage anyone to use.

[stancecoke]

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

[casainho]

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.

[geofft]

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.

[-dg]

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.

[casainho]

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.

[casainho]

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.

[geofft]

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.

[bardbe]

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.

[casainho]

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.

[casainho]

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.

[casainho]

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:



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.

[bardbe]

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!

[stancecoke]

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

[geofft]

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.