• Howdy! we're looking for donations to finish custom knowledgebase software for this forum. Please see our Funding drive thread

TSDZ2 Open Source firmware on KT motor controllers

Slipy

10 mW
Joined
Mar 19, 2020
Messages
25
Hi, i'm using homemade s06s controller but Open Sourse KT firmware on my opinion is too old.
I discovered that TSDZ2 and S06S working on a same microkontroller (STM8S105C6T6).
Also we know what this firmwares was written by Casainho and after modify by Stancecoke and codes very similar
BUT TSZD2 firmware is still updatind
Pluses of the TSDZ2 firmware is Fieldwaiking and more stable
I'm not a programmer but i made some changes in the motor.c and pwm.c
Code:
 pwm.c
TIM1_OC1Init(TIM1_OCMODE_PWM1,
#ifdef DISABLE_PWM_CHANNELS_1_3
         TIM1_OUTPUTSTATE_DISABLE,
         TIM1_OUTPUTNSTATE_DISABLE,
#else
         TIM1_OUTPUTSTATE_ENABLE,
         TIM1_OUTPUTNSTATE_ENABLE,
#endif
         255, // initial duty_cycle value
         TIM1_OCPOLARITY_HIGH,
         TIM1_OCPOLARITY_LOW,
         TIM1_OCIDLESTATE_RESET,
         TIM1_OCNIDLESTATE_SET);

  TIM1_OC2Init(TIM1_OCMODE_PWM1,
         TIM1_OUTPUTSTATE_ENABLE,
         TIM1_OUTPUTNSTATE_ENABLE,
         255, // initial duty_cycle value
         TIM1_OCPOLARITY_HIGH,
         TIM1_OCPOLARITY_LOW,
         TIM1_OCIDLESTATE_RESET,
         TIM1_OCIDLESTATE_SET);

  TIM1_OC3Init(TIM1_OCMODE_PWM1,
#ifdef DISABLE_PWM_CHANNELS_1_3
         TIM1_OUTPUTSTATE_DISABLE,
         TIM1_OUTPUTNSTATE_DISABLE,
#else
         TIM1_OUTPUTSTATE_ENABLE,
         TIM1_OUTPUTNSTATE_ENABLE,
#endif
         255, // initial duty_cycle value
         TIM1_OCPOLARITY_HIGH,
         TIM1_OCPOLARITY_LOW,
         TIM1_OCIDLESTATE_RESET,
         TIM1_OCNIDLESTATE_SET);
Code:
motor.c
void motor_enable_pwm(void)
{
  TIM1_OC1Init(TIM1_OCMODE_PWM1,
#ifdef DISABLE_PWM_CHANNELS_1_3
         TIM1_OUTPUTSTATE_DISABLE,
         TIM1_OUTPUTNSTATE_DISABLE,
#else
         TIM1_OUTPUTSTATE_ENABLE,
         TIM1_OUTPUTNSTATE_ENABLE,
#endif
         255, // initial duty_cycle value
         TIM1_OCPOLARITY_HIGH,
         TIM1_OCPOLARITY_LOW,
         TIM1_OCIDLESTATE_RESET,
         TIM1_OCIDLESTATE_RESET);

  TIM1_OC2Init(TIM1_OCMODE_PWM1,
         TIM1_OUTPUTSTATE_ENABLE,
         TIM1_OUTPUTNSTATE_ENABLE,
         255, // initial duty_cycle value
         TIM1_OCPOLARITY_HIGH,
         TIM1_OCPOLARITY_LOW,
         TIM1_OCIDLESTATE_RESET,
         TIM1_OCIDLESTATE_RESET);

  TIM1_OC3Init(TIM1_OCMODE_PWM1,
#ifdef DISABLE_PWM_CHANNELS_1_3
         TIM1_OUTPUTSTATE_DISABLE,
         TIM1_OUTPUTNSTATE_DISABLE,
#else
         TIM1_OUTPUTSTATE_ENABLE,
         TIM1_OUTPUTNSTATE_ENABLE,
#endif
         255, // initial duty_cycle value
         TIM1_OCPOLARITY_HIGH,
         TIM1_OCPOLARITY_LOW,
         TIM1_OCIDLESTATE_RESET,
         TIM1_OCIDLESTATE_RESET);
}

void motor_disable_pwm(void)
{
  TIM1_OC1Init(TIM1_OCMODE_PWM1,
         TIM1_OUTPUTSTATE_DISABLE,
         TIM1_OUTPUTNSTATE_DISABLE,
         255, // initial duty_cycle value
         TIM1_OCPOLARITY_HIGH,
         TIM1_OCPOLARITY_LOW,
         TIM1_OCIDLESTATE_RESET,
         TIM1_OCIDLESTATE_RESET);

  TIM1_OC2Init(TIM1_OCMODE_PWM1,
         TIM1_OUTPUTSTATE_DISABLE,
         TIM1_OUTPUTNSTATE_DISABLE,
         255, // initial duty_cycle value
         TIM1_OCPOLARITY_HIGH,
         TIM1_OCPOLARITY_LOW,
         TIM1_OCIDLESTATE_RESET,
         TIM1_OCIDLESTATE_RESET);

  TIM1_OC3Init(TIM1_OCMODE_PWM1,
         TIM1_OUTPUTSTATE_DISABLE,
         TIM1_OUTPUTNSTATE_DISABLE,
         255, // initial duty_cycle value
         TIM1_OCPOLARITY_HIGH,
         TIM1_OCPOLARITY_LOW,
         TIM1_OCIDLESTATE_RESET,
         TIM1_OCIDLESTATE_RESET);
but still to modify adc.c and adc.h
who a interesting on this firmware conversation Welcome to help :)
 
Slipy said:
Pluses of the TSDZ2 firmware is Fieldwaiking and more stable

Why do you think, the TSDZ2 firmware is more stable?! Are there any issues with the Kunteng firmware?! There are currently not many further developments as the firmware is already very mature.

The core motor commutation control is much better in the kunteng project, we get real phase current feedback to do simplified FOC and not just calculate a theoretical advance angle from coil inductance and resistance. The TSDZ2 firmware only knows two different motortypes and just one PCB layout. The Kunteng-Firmware has to work with various PCB-Layouts and all kind of motors...

The PWM setting is done by a PI control in the Kunteng-firmware and not by simple ramps with delay definitions as in the TSDZ2 (That was the point where my and casainhos ways separated) This results in a significantly better reaction behaviour during load changes and is very easy to configure.

Good Luck with your project!

regards
stancecoke
 
stancecoke said:
Slipy said:
Pluses of the TSDZ2 firmware is Fieldwaiking and more stable

Why do you think, the TSDZ2 firmware is more stable?! Are there any issues with the Kunteng firmware?! There are currently not many further developments as the firmware is already very mature.
Hi stancecoke,
sorry if I offended you, a few days ago I had the opportunity to test tsdz2 with opensource firmware in poland, at first glance it seemed to me much more stable when starting and driving, on my s06s (original not homemade)
there is a problem with the start of the motor (direct drive) the problem appears if you hold the motor, it seems to skip a phase, also on tsdz2 and s06s 16kHz, but at the same time s06s more noise (swithing to 20kHz does not help much), adjust the angle of the motor too
on the homemade controller, everything is exactly the same (I bought the original one because I thought it was a problem in the homemade controller) and another problem with Bluosec.
Immediately after the flashing, it responds adequately to changes, but it is worth changing the settings 20 times as they stop being saved and after a reboot the settings are loaded only after connecting to bluetooth. AND LAST in foc mode with a direct drive motor, if you drive in your hands, the motor starts itself
"ITS ONLY MY FIRST OPINION don't take it to heart"
 
Note that TSDZ2 firmware will not work for direct drive motors while KT firmware will (because firmware on TSDZ2 is not able to rotate motor backwards and manage regen). Also KT firmware use the specific hardware of KT motor controllers to calculate FOC and is independent of motor characteristics like inductance while TSDZ2 hardware can't do it and so the firmware use constants specific for the TSDZ2 motor.

One advantage of TSDZ2 is that there are few hardware combinations possible while on the KT there are MANY, like the motor phases and hall sensors, the torque sensor, the PAS, the throttle, etc... it is hard to configure because all the different hardware combinations, meaning there is an high probability that the default configuration it not work!! this is a big advantage on TSDZ2!! I can't imagine myself giving support on the KT thread for new users........
 
Slipy said:
there is a problem with the start of the motor (direct drive) the problem appears if you hold the motor, it seems to skip a phase,
This is a matter of the phase current limitation. You should never power a blocked motor, this only produces heat and fries your controller. Both, TSDZ2 and Kunteng controllers have no real phase current sensors, (Kunteng has one, that is only used to detect the zero crossing, you'll need at least 2 for having control over the phase current, TSDZ2 has none) So both controllers can only calculate the motor current from motorcurrent = battery current/duty cycle. So you can't get a smooth start up by controlling the motor current.... The motor starts with a battery current target. At standstill, the motor current will increase very fast, then the phase current limitation kicks in. The battery current signal has a hardware RC-Filter implemented, that gives some delay, too. There is an unfiltered input pin also, but it is not used in the recent Kunteng-Firmware.

Slipy said:
also on tsdz2 and s06s 16kHz
It's not a matter of the PWM frequency, but of the update rate of the PI control. You could increase the frequency of the control loop.

So there is some potential for improvement, indeed, feel free to try!

regards
stancecoke
 
stancecoke said:
At standstill, the motor current will increase very fast, then the phase current limitation kicks in. The battery current signal has a hardware RC-Filter implemented, that gives some delay, too. There is an unfiltered input pin also, but it is not used in the recent Kunteng-Firmware.
Sad that we could not work together to make the use of the battery current on the unfiltered input - I did it on may last firmware version for KT and I validated that it works as expected. I think this feature is the key to detect fast current changes and protect the motor controller for more powerful and low inductance motors.
 
casainho said:
I think this feature is the key to detect fast current changes and protect the motor controller for more powerful and low inductance motors.

Yes, perhaps Slipy can try your last version to see if it's worth the work to implement it in the recent code...

regards
stacecoke
 
stancecoke said:
Slipy said:
It's not a matter of the PWM frequency, but of the update rate of the PI control. You could increase the frequency of the control loop.

So there is some potential for improvement, indeed, feel free to try!

regards
stancecoke
what about bluetooth bug, now i'm working with stancecoke firmware and trying to upgrade it (simple functoins) o new questions, does it possible to make reverse in firmware
 
Slipy said:
what about bluetooth bug,

I don't know any bluetooth bug. People report short freezes of the app, but no bug. The freezing is fixed in the "torque from X4" branch for torquesensor mode.

The settings from the BluOsec app are stored in the EEPROM, so they are permanatly written to the memory and are available right after power up, even without the mobile phone connected. If that doesn't work for you, there's something wrong in your setup.
But I'm not a specialist in BluOsec, I dont use it. @Xnyle who developed the app wasn't seen for a long time now...

Of course, if you flash the system to a different display, all former settings from BuOsec are overwritten...

regards
stancecoke
 
stancecoke said:
But I'm not a specialist in BluOsec, I dont use it. @Xnyle who developed the app wasn't seen for a long time now...
It is so sad that app is not OpenSource and then you guys are with your hands tied, with possible bugs and no chance to correct them, or even keep improving the firmware <-> app. Does not make sense on this OpenSource projects that started with objective to share knowledge and technology so the EBikes technology can be elevated.

I hope we can work together for the future Android and IOS app.
 
stancecoke said:
Slipy said:
what about bluetooth bug,

I don't know any bluetooth bug. People report short freezes of the app, but no bug. The freezing is fixed in the "torque from X4" branch for torquesensor mode.

The settings from the BluOsec app are stored in the EEPROM, so they are permanatly written to the memory and are available right after power up, even without the mobile phone connected. If that doesn't work for you, there's something wrong in your setup.
But I'm not a specialist in BluOsec, I dont use it. @Xnyle who developed the app wasn't seen for a long time now...

Of course, if you flash the system to a different display, all former settings from BuOsec are overwritten...

regards
stancecoke


can you help with foc mode, two problems
the first is that if you push the ebike, he drives himself
the second is when you turn on the foc mode, you need to change the overvoltage to a large value
 
Slipy said:
the first is that if you push the ebike, he drives himself
the second is when you turn on the foc mode, you need to change the overvoltage to a large value
Sorry, I don't understand, what's your problem, please explain better.

regards
stancecoke
 
stancecoke said:
Slipy said:
the first is that if you push the ebike, he drives himself
the second is when you turn on the foc mode, you need to change the overvoltage to a large value
Sorry, I don't understand, what's your problem, please explain better.

regards
stancecoke

https://youtu.be/RYx1IvMN9tQ after bluetooth connecting, max speed is bigger
 
Slipy said:
after bluetooth connecting, max speed is bigger

Sorry, but without knowing the settings in the config.h and the BluOSEC app, I can say nothing to your video clip.

regards
stancecoke
 
Back
Top