TSDZ2 open source firmware only for KT-LCD3 (v0.19.0 / v.0.20.0beta1)

Nice to hear from you Buba! Thanks for checking in. Maybe now we can get 'beta1' out of the name of this awesome v0.20.0 firmware. :)
 
More hugs:) Welcome back. Awesome work with TSDZ OSF, long story short, I totally forgot I have a car :wink:
 
Hello,
today I tried the Mbrusa modification to fix the overrang on lcd3.
I must say that it works very well, I posted a video made with the phone, obviously it is not the best, but the arrest is clearly visible.

https://youtu.be/r3RW_21sJTc


Ciao,
oggi ho provato la modifica Mbrusa per sistemare l'overrang su lcd3.
Devo dire che funziona benissimo, ho postato un video fatto con il telefono, ovviamente non è il massimo, però si vede bene l'arresto.
 
I think it's time to try the "overrun" modification.
I start from version 20 beta 1 for LCD3, by the weekend I will release the code and the description of the fix, I am preparing it.
Obviously there will also be the version for original displays.
 

Attachments

  • TSDZ2-v0.20.1-LCD3-fix_overrun.zip
    20.6 KB · Views: 81
mbrusa said:
I think it's time to try the "overrun" modification.
I start from version 20 beta 1 for LCD3, by the weekend I will release the code and the description of the fix, I am preparing it.
Obviously there will also be the version for original displays.
Can you please share the source code as also describe the changes you did and why? can you give technical explanation? thanks.
 
mbrusa said:
yes, I'm preparing it.
I was expecting to see the source code on that zip file, as OpenSource you also need to provide the source code and not only the HEX file.
 
mbrusa said:
Of course I will also put the source code, I am preparing the description, I seem to have been clear.
Thank you for taking the time and effort to add the change also to LCD3 version. This is highly appreciated!
 
Casainho, here is the description and the source code, I hope it is also useful for the main project
I hope that after the automatic translation it is still understandable.

The code to calculate and activate the PWM deceleration ramp is in the ebike_app.c file, this introduces a significant delay when you stop pedaling.
I added other code for this function in motor.c, (PWM frequency).
I tried to do it in a simple way by minimizing the lines of code.
The added code works in parallel with the existing one that has not been deleted.

added code:
TSDZ2-20beta1-fix_overrun-1.jpg
variable declaration:
"ui8_cadence_sensor_stop_flag" state of the pedals stopped.
"ui16_cadence_sensor_ticks_stop" number of pulses of the tick counter beyond which the pedals are considered stationary.


TSDZ2-20beta1-fix_overrun-2.jpg
Added direct activation of the PWM deceleration ramp with "ui8_cadence_sensor_stop_flag", previously activated in ebike_app.c due to the absence of assistance.
With the pedals stopped "ui8_cadence_sensor_stop_flag", direct assignment ui16_controller_duty_cycle_ramp_down_inverse_step = PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP_MIN. Previously the value was calculated as a function of the speed in ebike.c.
The PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP_MIN value was used by the brake sensors but always in ebike_app.c. For this I also added "OR ui8_brake_state".
The PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP_MIN value in main.h has not changed.


TSDZ2-20beta1-fix_overrun-3.jpg
TSDZ2-20beta1-fix_overrun-4.jpg
Calculation of the value of "ui16_cadence_sensor_ticks_stop", in standard and advanced cadence sensor mode. They are different values.
The optimal values were obtained experimentally.
Increasing them increases the overrun time, decreasing them lacks assistance at the start.


TSDZ2-20beta1-fix_overrun-5.jpg
Check the state of the pedals.
When "ui16_cadence_sensor_ticks" has a valid value and "ui16_cadence_sensor_ticks_counter" exceeds the value of "ui16_cadence_sensor_ticks_stop", the pedals are considered stationary.


View attachment motor.c
motor.c source code TSDZ2 20 beta 1 version only for LCD3, with overrun modification.
 
mbrusa said:
Casainho, here is the description and the source code, I hope it is also useful for the main project
I hope that after the automatic translation it is still understandable.
Thanks for all this details!! This is a great collaboration with all other forks/project versions.

I understand that the PWM ramp up and down plays an important role on the reaction time of the motor... the thing was that I tried a few times different and I saw the motor rotate on my bicycle frame at startup or stop, when the ramp up is to fast -- so, to have faster reaction the forces applied by the motor on the frame seem to be stronger and I was afraid to damage my frame and the motor shell... -- do you have the same felling / results?? -- like the motor is pulling the chain with a strong torque and suddenly you disable the full torque...
 
I have not changed the value of the PWM deceleration ramp, I have only reduced the time between stopping the pedals and starting the ramp.
The PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP_MIN value remained 8, I have never tried to decrease it.
It is the same value used with the activation of the brakes or with an motor error.
The one calculated as a function of speed, still used with the pedals in motion, is between 8 and 40.
I am using this modification without problems.
 
mbrusa said:
Casainho, here is the description and the source code, I hope it is also useful for the main project
...

Does the overrun feature make the brake sensor more or less useless since you are usually not pedaling when braking?
 
It is not the same, the intervention of the brake sensors is immediate and they immediately activate the PWM deceleration ramp.
When the pedals stop, there is always a delay, necessary to verify that they are stationary.
There is also a non-software aspect, it can happen to brake suddenly while you are still pedaling!
 
Great contribution. If someone merges it into 850c 0.54 version I'm willing to test it. I'm not sure I can merge this changes myself...
 
Here is the "fix overrun" update in the TSDZ2-20beta1 version, for the LCD3 display.
The files changed are 3, ebike_app.c, motor.c, motor.h
I had not considered the riding modes with stationary pedals, which consequently do not work.
Now "fix overrun" is disabled in WALK ASSIST, CRUISE, THROTTLE mode and CADENCE SENSOR CALIBRATION MODE.
For this the variable ui8_fix_overrun_enabled has been added.
TSDZ2-20beta1-fix_overrun_update-1.jpg
TSDZ2-20beta1-fix_overrun_update-2.jpg
TSDZ2-20beta1-fix_overrun_update-3.jpg
TSDZ2-20beta1-fix_overrun_update-4.jpg
Attached: HEX file and source code of the modified files.
View attachment TSDZ2-v0.20.1-LCD3-fix_overrun_update.zip
I don't have LCD3, I would be happy with the confirmation of correct working.
Thank you.
 
vshitikov said:
Great contribution. If someone merges it into 850c 0.54 version I'm willing to test it. I'm not sure I can merge this changes myself...
I want to get this on the firmware but currently there is a higher priority issue to solve then I will add this improvement.
 
mbrusa said:
Here is the "fix overrun" update in the TSDZ2-20beta1 version, for the LCD3 display.
The files changed are 3, ebike_app.c, motor.c, motor.h
I had not considered the riding modes with stationary pedals, which consequently do not work.
Now "fix overrun" is disabled in WALK ASSIST, CRUISE, THROTTLE mode and CADENCE SENSOR CALIBRATION MODE.
For this the variable ui8_fix_overrun_enabled has been added.
TSDZ2-20beta1-fix_overrun_update-1.jpg
TSDZ2-20beta1-fix_overrun_update-2.jpg
TSDZ2-20beta1-fix_overrun_update-3.jpg
TSDZ2-20beta1-fix_overrun_update-4.jpg
Attached: HEX file and source code of the modified files.
TSDZ2-v0.20.1-LCD3-fix_overrun_update.zip
I don't have LCD3, I would be happy with the confirmation of correct working.
Thank you.

So to be able to install this overrun fix we have to be able to compile the files on our own?
We can't just install it like we can an update?
If that's the case it would be really great for someone to compile it so those that can't compile can use the overrun fix.
 
mbrusa said:
In the zip file, in addition to the source code, there is also the HEX file already compiled and ready to be flashed.

There is only 1 hex file, don't we need 2 one for the LCD3 and one for the TSDZ2?
 
mbrusa said:
The HEX file is for the TSDZ2 controller, only that has changed.
For LCD3, the buba 20 beta 1 version is still fine.

Ok, got it. Having LCD3 in the title of the hex file made us think it was for the KT-LCD3. We will try it in the motor today. Thanks!
 
Back
Top