TSDZ2 mid drive with 860C, 850C or SW102 displays only -- Flexible OpenSource firmware (Casainho code only)

[stefkrger]

What made you switch back to stock firmware?

Right when I bought my TSDZ2 I flashed it with the OSFW and used it with a SW102 display.
With the later releases the OSFW worked fine, however I'd like to try the original one just to get a comparison. Also someone mentioned in another thread that the original FW offers slightly better acceleration and responsiveness when accelerating from stand. I'm mostly riding in the city and with all the traffic lights i'm constantly stopping and accelerating. Just want to see if it's really better with the stock FW.

 

[r0mko]

What made you switch back to stock firmware?

Right when I bought my TSDZ2 I flashed it with the OSFW and used it with a SW102 display.
With the later releases the OSFW worked fine, however I'd like to try the original one just to get a comparison. Also someone mentioned in another thread that the original FW offers slightly better acceleration and responsiveness when accelerating from stand. I'm mostly riding in the city and with all the traffic lights i'm constantly stopping and accelerating. Just want to see if it's really better with the stock FW.

You can try out my mod then before switching back to stock firmware. It has much more acceleration at low RPM.
Give it a try: https://github.com/r0mko/TSDZ2-Smart-EBike/releases/tag/v0.57.10
and the older version:
https://github.com/r0mko/TSDZ2-Smart-EBike/releases/tag/v0.56-experimental

 

[vshitikov]

What made you switch back to stock firmware?

Right when I bought my TSDZ2 I flashed it with the OSFW and used it with a SW102 display.
With the later releases the OSFW worked fine, however I'd like to try the original one just to get a comparison. Also someone mentioned in another thread that the original FW offers slightly better acceleration and responsiveness when accelerating from stand. I'm mostly riding in the city and with all the traffic lights i'm constantly stopping and accelerating. Just want to see if it's really better with the stock FW.

There isn't that much difference between stock FW and Casainho's Firmware in terms of the acceleration. Stock firmware though gives you the wobble at low pedal cadence.
There is also a branch of 0.20 firmware developed by Casainho in the beginning and modified by other users buba, marcoq e.t.c, It works with the stock displays, It proposes several motor control modes . I think you can find it in the user Stancecoke git

https://github.com/stancecoke/TSDZ2-Smart-EBike/blob/master/manuals/EN-Manual_display%20operation-TSDZ2-mb.20beta1.A.pdf

 

[James Broadhurst]

Go to configurations and then variables, then odometer and trip distance. Read the wiki page about features and configurations to see how they should be configured.

Switching to SI units (from imperial) cures it. Nothing else does. Sorry! What makes it worse is that the grandchild thinks he suggested this, by phone no less.

 

[windburner]

Has anyone tried to go back to the stock motor firmware from the OpenSource one?
I found some stock FW files posted here:
https://www.eco-ebike.com/blogs/eco-cycles-instructionals/tsdz2-motor-firmware-programming

I have a stock VLCD5 which I would use. Should I expect any problems when flashing the motor back?

Expect no problems, the guide you linked to is very clear and thorough. If the option byte settings after read from the controller are different, just change them according to the image before continuing.

Yes, you will definitely need to restore the Option Byte data! One other thing. If you have a 48V system, then definitely use the 48V Program & Data files, as using the 52V files on a 48V system will result in the max output being limited. (The 52V files will definitely fix the issue where a fully charged 48V battery sometimes causes an overvoltage response from the controller, but the loss in output is definitely noticable and documented somewhere in the main TSDZ2 thread.)

With my 'for pleasure on street' mode of operation, I definitely prefer the Factory FW. As you noted, quick and smooth onset of pedal assist and walk mode of the Factory FW, and the operational stability, was much preferred/safer, at least for my testing of many versions through 0.55/0.6.8, after which I have reverted to Factory.

 

[casainho]

Casainho there is a problem in version 0.8.0. by 0.7 the engine stop time has been shortened. it is too short for my bike frame. this causes the engine to stop constantly on bumps and unevenness. It will be a big problem in some frames with full suspension where crank retraction occurs while bending the rear suspension. Could it be done so that this stop time could be adjusted by itself in the display?

@Casainho
They reported me the same problem with fix overrun in v.20, it is more evident with a full suspension.
I have tried to increase the value of PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP_MIN, I have had confirmation that it is much better. The ideal would be to set the value on the display.

Thanks! I will look at your current code here and use your values.

So the idea is to slow down the motor reaction when "cutting the power" (duty-cycle). Why not change instead the percentage of min cadence change, the amount of ui16_cadence_sensor_ticks_stop?

On my code I am using the ui16_cadence_sensor_ticks_stop = (ui16_cadence_sensor_ticks + (ui16_cadence_sensor_ticks >> 3));
so the max cadence change rate is (cadence * 0.89). If I change to ui16_cadence_sensor_ticks >> 2, then it will be (cadence * 0,8).

Did you tested a different cadence change rate?

 

[vshitikov]

Casainho there is a problem in version 0.8.0. by 0.7 the engine stop time has been shortened. it is too short for my bike frame. this causes the engine to stop constantly on bumps and unevenness. It will be a big problem in some frames with full suspension where crank retraction occurs while bending the rear suspension. Could it be done so that this stop time could be adjusted by itself in the display?

@Casainho
They reported me the same problem with fix overrun in v.20, it is more evident with a full suspension.
I have tried to increase the value of PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP_MIN, I have had confirmation that it is much better. The ideal would be to set the value on the display.

Thanks! I will look at your current code here and use your values.

So the idea is to slow down the motor reaction when "cutting the power" (duty-cycle). Why not change instead the percentage of min cadence change, the amount of ui16_cadence_sensor_ticks_stop?

On my code I am using the ui16_cadence_sensor_ticks_stop = (ui16_cadence_sensor_ticks + (ui16_cadence_sensor_ticks >> 3));
so the max cadence change rate is (cadence * 0.89). If I change to ui16_cadence_sensor_ticks >> 2, then it will be (cadence * 0,8).

Did you tested a different cadence change rate?

Casainho I tested different configurations ui16_cadence_sensor_ticks >> 3 ,4 and 2.
What users report is the click that occurs when the motor stops and releases the chain. With different values it is more or less pronounced because the chain is more or less under the tension. The reason is that whatever is the value the motor stops in <255 PWM ticks which represents ~16ms. For the users with the hardtail fames like a majority of us, it doesn't matter. For the user with full suspension bikes, a quick release of the chain gives them "kick in a butt" like user r0mko mentioned. The solution would be to slow down this ramp and do not decrease pwm value each time the stop flag raised, but do it one out of two times or even less.
with the >>2 value it is barely noticeable though, but i'm on the longtail bike

 

[plpetrov]

Casainho there is a problem in version 0.8.0. by 0.7 the engine stop time has been shortened. it is too short for my bike frame. this causes the engine to stop constantly on bumps and unevenness. It will be a big problem in some frames with full suspension where crank retraction occurs while bending the rear suspension. Could it be done so that this stop time could be adjusted by itself in the display?

@Casainho
They reported me the same problem with fix overrun in v.20, it is more evident with a full suspension.
I have tried to increase the value of PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP_MIN, I have had confirmation that it is much better. The ideal would be to set the value on the display.

Thanks! I will look at your current code here and use your values.

So the idea is to slow down the motor reaction when "cutting the power" (duty-cycle). Why not change instead the percentage of min cadence change, the amount of ui16_cadence_sensor_ticks_stop?

On my code I am using the ui16_cadence_sensor_ticks_stop = (ui16_cadence_sensor_ticks + (ui16_cadence_sensor_ticks >> 3));
so the max cadence change rate is (cadence * 0.89). If I change to ui16_cadence_sensor_ticks >> 2, then it will be (cadence * 0,8).

Did you tested a different cadence change rate?

Casainho I tested different configurations ui16_cadence_sensor_ticks >> 3 ,4 and 2.
What users report is the click that occurs when the motor stops and releases the chain. With different values it is more or less pronounced because the chain is more or less under the tension. The reason is that whatever is the value the motor stops in <255 PWM ticks which represents ~16ms. For the users with the hardtail fames like a majority of us, it doesn't matter. For the user with full suspension bikes, a quick release of the chain gives them "kick in a butt" like user r0mko mentioned. The solution would be to slow down this ramp and do not decrease pwm value each time the stop flag raised, but do it one out of two times or even less.
with the >>2 value it is barely noticeable though, but i'm on the longtail bike

I don’t think the problem reported by r0mko is caused by the quick release of the chain but of the uneven power jump in function of the pedal position, the applied torque and the assist level. See the related post:

I've released a torque mod for FW v0.57: https://github.com/r0mko/TSDZ2-Smart-EBike/releases/tag/v0.57.10
Works fine for me, but motor stops way too early. If I go on pedalling after a brief pause, the motor gives a strong kick to butt. This is not a big deal and I learned quickly how to avoid this, but I would like to have this overrun fix as an option like "Coaster brake", that can be disabled.

Later he confirmed the the problem was minimises after torque sensor calibration. However his torque sensor has the same characteristics as mine, where the calibration values for 0 weight on the left and the right pedal are different. The current code is written with the assumption that they are the same. Workaround for me was to use an average value for the torque calibration sensor at 0 weight applied on both left and right pedals.

 

[mbrusa]

Thanks! I will look at your current code here and use your values.

So the idea is to slow down the motor reaction when "cutting the power" (duty-cycle). Why not change instead the percentage of min cadence change, the amount of ui16_cadence_sensor_ticks_stop?

On my code I am using the ui16_cadence_sensor_ticks_stop = (ui16_cadence_sensor_ticks + (ui16_cadence_sensor_ticks >> 3));
so the max cadence change rate is (cadence * 0.89). If I change to ui16_cadence_sensor_ticks >> 2, then it will be (cadence * 0,8).

Did you tested a different cadence change rate?

Yes, I had tried
(ui16_cadence_sensor_ticks + (ui16_cadence_sensor_ticks >> 2));
and also
(ui16_cadence_sensor_ticks + (ui16_cadence_sensor_ticks >> 1));
always works, slightly increases the overrun time.
I have a friend with a full suspension and he feel comfortable with >> 2 and PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP_MIN at 24, instead of 8.

 

[casainho]

Casainho there is a problem in version 0.8.0. by 0.7 the engine stop time has been shortened. it is too short for my bike frame. this causes the engine to stop constantly on bumps and unevenness. It will be a big problem in some frames with full suspension where crank retraction occurs while bending the rear suspension. Could it be done so that this stop time could be adjusted by itself in the display?

Please install the firmware v0.57.2, where I changed only the following code based on mbrusa feedback:

- #define PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP 20
+ #define PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP 24

- ui16_m_pas_min_cadence_pwm_cycles_ticks = (ui16_pas_pwm_cycles_ticks + (ui16_pas_pwm_cycles_ticks >> 3));
+ ui16_m_pas_min_cadence_pwm_cycles_ticks = (ui16_pas_pwm_cycles_ticks + (ui16_pas_pwm_cycles_ticks >> 2));

Thanks! I will look at your current code here and use your values.

So the idea is to slow down the motor reaction when "cutting the power" (duty-cycle). Why not change instead the percentage of min cadence change, the amount of ui16_cadence_sensor_ticks_stop?

On my code I am using the ui16_cadence_sensor_ticks_stop = (ui16_cadence_sensor_ticks + (ui16_cadence_sensor_ticks >> 3));
so the max cadence change rate is (cadence * 0.89). If I change to ui16_cadence_sensor_ticks >> 2, then it will be (cadence * 0,8).

Did you tested a different cadence change rate?

Yes, I had tried
(ui16_cadence_sensor_ticks + (ui16_cadence_sensor_ticks >> 2));
and also
(ui16_cadence_sensor_ticks + (ui16_cadence_sensor_ticks >> 1));
always works, slightly increases the overrun time.
I have a friend with a full suspension and he feel comfortable with >> 2 and PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP_MIN at 24, instead of 8.

 

[hetm4n]

Please install the firmware v0.57.2, where I changed only the following code based on mbrusa feedback:

- #define PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP 20
+ #define PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP 24

- ui16_m_pas_min_cadence_pwm_cycles_ticks = (ui16_pas_pwm_cycles_ticks + (ui16_pas_pwm_cycles_ticks >> 3));
+ ui16_m_pas_min_cadence_pwm_cycles_ticks = (ui16_pas_pwm_cycles_ticks + (ui16_pas_pwm_cycles_ticks >> 2));

I will try these changes today

 

[ilu]

Does anyone know wether there will be any problem if I have temperature sensor installed and I revert back to stock firmware? Mainly for making comparisons, I'm not planning to use stock for a long time so I wouldn't want to remove the sensor just for that.

 

[skestans]

Does anyone know wether there will be any problem if I have temperature sensor installed and I revert back to stock firmware? Mainly for making comparisons, I'm not planning to use stock for a long time so I wouldn't want to remove the sensor just for that.

Yes there will be problems because the original firmware will read the voltage output of the temperature sensor as you pressing the throttle. So you’ll have to disconnect the output of the sensor before using the original firmware again. Also note that you can’t dump the 8x0C original firmware so unless you obtained a mn image by other means you won’t have the original display firmware to restore. And I heard that putting back the original firmware after the OSS one doesn’t work, maybe because the flash layout differs.

 

[skestans]

For the last few days I’m having issues with initialization. When turning on the display, I keep the right pedal down as per the settings and wait until the startup message to go away. More often than not one of two things happen:

- the torque sensor reads insane values, like barely pressing on the pedals (probably 100W) registers as over 2000W on the display and makes the motor go full throttle on and off

- the torque sensor registers normal values but the motor never ever engages

To fix this I have to disconnect the battery completely and start it up again. After the tenth or twentieth try I get the whole thing to operate normally eventually.

Is this an issue with 0.6.5, or is it a hardware issue? I’m aware there are more recent versions but I depend on my bike 100% (it’s my only mode of transportation) and I’m a bit wary of trying out a newer version where serious bugs might not all have been ironed out like it happened with >0.6.5.

I’m very grateful for the considerable effort to make this firmware, this is not by any means a rant

 

[vshitikov]

Does anyone know wether there will be any problem if I have temperature sensor installed and I revert back to stock firmware? Mainly for making comparisons, I'm not planning to use stock for a long time so I wouldn't want to remove the sensor just for that.

Yes there will be problems because the original firmware will read the voltage output of the temperature sensor as you pressing the throttle. So you’ll have to disconnect the output of the sensor before using the original firmware again. Also note that you can’t dump the 8x0C original firmware so unless you obtained a mn image by other means you won’t have the original display firmware to restore. And I heard that putting back the original firmware after the OSS one doesn’t work, maybe because the flash layout differs.

Putting back the original firmware works but you have to restore option bytes to its original state. As the firmware posted on the eco-cycles website does not contain option bytes.

 

[skestans]

Does anyone know wether there will be any problem if I have temperature sensor installed and I revert back to stock firmware? Mainly for making comparisons, I'm not planning to use stock for a long time so I wouldn't want to remove the sensor just for that.

Yes there will be problems because the original firmware will read the voltage output of the temperature sensor as you pressing the throttle. So you’ll have to disconnect the output of the sensor before using the original firmware again. Also note that you can’t dump the 8x0C original firmware so unless you obtained a mn image by other means you won’t have the original display firmware to restore. And I heard that putting back the original firmware after the OSS one doesn’t work, maybe because the flash layout differs.

Putting back the original firmware works but you have to restore option bytes to its original state. As the firmware posted on the eco-cycles website does not contain option bytes.

That’s for the motor, right? I was talking about the display.

 

[hetm4n]

Please install the firmware v0.57.2, where I changed only the following code based on mbrusa feedback:

- #define PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP 20
+ #define PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP 24

- ui16_m_pas_min_cadence_pwm_cycles_ticks = (ui16_pas_pwm_cycles_ticks + (ui16_pas_pwm_cycles_ticks >> 3));
+ ui16_m_pas_min_cadence_pwm_cycles_ticks = (ui16_pas_pwm_cycles_ticks + (ui16_pas_pwm_cycles_ticks >> 2));

I tested 0.57.2. It is a bit better, the engine does not interrupt the support as often on unevenness as on 0.57.0. But you still need to extend this reaction.

 

[casainho]

Please install the firmware v0.57.2, where I changed only the following code based on mbrusa feedback:

- #define PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP 20
+ #define PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP 24

- ui16_m_pas_min_cadence_pwm_cycles_ticks = (ui16_pas_pwm_cycles_ticks + (ui16_pas_pwm_cycles_ticks >> 3));
+ ui16_m_pas_min_cadence_pwm_cycles_ticks = (ui16_pas_pwm_cycles_ticks + (ui16_pas_pwm_cycles_ticks >> 2));

I tested 0.57.2. It is a bit better, the engine does not interrupt the support as often on unevenness as on 0.57.0. But you still need to extend this reaction.

Did you noted any changed on the time the motor takes to stop once you stop pedaling? Is this a very important feature to you? could this feature be sacrificed to improve the issue you are currently having?

 

[vshitikov]

Does anyone know wether there will be any problem if I have temperature sensor installed and I revert back to stock firmware? Mainly for making comparisons, I'm not planning to use stock for a long time so I wouldn't want to remove the sensor just for that.

Yes there will be problems because the original firmware will read the voltage output of the temperature sensor as you pressing the throttle. So you’ll have to disconnect the output of the sensor before using the original firmware again. Also note that you can’t dump the 8x0C original firmware so unless you obtained a mn image by other means you won’t have the original display firmware to restore. And I heard that putting back the original firmware after the OSS one doesn’t work, maybe because the flash layout differs.

Putting back the original firmware works but you have to restore option bytes to its original state. As the firmware posted on the eco-cycles website does not contain option bytes.

That’s for the motor, right? I was talking about the display.

my bad, I didn't really play with the original display

 

[plpetrov]

Please install the firmware v0.57.2, where I changed only the following code based on mbrusa feedback:

- #define PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP 20
+ #define PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP 24

- ui16_m_pas_min_cadence_pwm_cycles_ticks = (ui16_pas_pwm_cycles_ticks + (ui16_pas_pwm_cycles_ticks >> 3));
+ ui16_m_pas_min_cadence_pwm_cycles_ticks = (ui16_pas_pwm_cycles_ticks + (ui16_pas_pwm_cycles_ticks >> 2));

I tested 0.57.2. It is a bit better, the engine does not interrupt the support as often on unevenness as on 0.57.0. But you still need to extend this reaction.

Did you noted any changed on the time the motor takes to stop once you stop pedaling? Is this a very important feature to you? could this feature be sacrificed to improve the issue you are currently having?

Casainho,
I tested both 0.57.1 and 0.57.2. Switched several time between them just to be sure that my observations are correct:

0.57.1 In terms of coaster braking is very good. The motor stops quickly with very low coater brake effort at slow cadence. At high cadence I could not feel any difference between 0.57.1 and 0.57.2. Both will stop as soon as I stop pedaling.

0.57.2 In terms of coaster braking behaves like the firmware version without the overrun issue fixed. Will require bigger coater brake effort at slow cadence. May be two or three time bigger than 0.57.1. At high cadence I could not feel any difference between 0.57.1 and 0.57.2. Both will stop as soon as I stop pedaling.

So there is a dependency. The time and the effort required for the motor to stop depends on how fast we rotate the pedals.

With both firmware versions I had the previous issue with the power burst above assist level 13. May be with 0.57.2 the situation was a bit worse. Can not really be sure.

And I started getting an error "e: 8 Comms". It will appear only after several tests with asset level greater than 13. Once the error appears on the screen, turning the power on and off will not clear it. Disconnecting the battery also. However after some time it disappears and the motor operates normally. The first time I did reset the display configuration and I think that cleared the error.

Do you have any idea what is causing this error and what condition is clearing it. I found in the code the part that prints it, but I could not identify yet the condition that causes and clears it.

 

[hetm4n]

Casainho Stopping the engine after stopping pedaling is probably identical, I can not distinguish it.

 

[r0mko]

I spent a day tinkering with the code to cope with jerks and bucking from the motor. As I'm pretty happy with the result, I've posted a new release for low-end torque fans. Here it is:
https://github.com/r0mko/TSDZ2-Smart-EBike/releases/tag/v0.57.12
What was done:

• Made overall response faster
• Made motor a bit low-end biased by sacrificing some performance at crazy high RPM
• Jerks and bucking are still present sometimes, but they became much gentler
• Shifting gears made softer, introducing less stress to transmission
• Removed startup boost feature completely. Communications part left for compatibility with the original display v0.8.0 firmware .

 

[casainho]

I spent a day tinkering with the code to cope with jerks and bucking from the motor. As I'm pretty happy with the result, I've posted a new release for low-end torque fans. Here it is:
https://github.com/r0mko/TSDZ2-Smart-EBike/releases/tag/v0.57.12
What was done:

• Made overall response faster
• Made motor a bit low-end biased by sacrificing some performance at crazy high RPM
• Jerks and bucking are still present sometimes, but they became much gentler
• Shifting gears made softer, introducing less stress to transmission
• Removed startup boost feature completely. Communications part left for compatibility with the original display v0.8.0 firmware .

Can you give technical details of changes on each point? And how did you validate?

I would like to re-use but it will only be possible by understanding what changes you did and why, as also how you did validate.

 

[r0mko]

Can you give technical details of changes on each point? And how did you validate?

I would like to re-use but it will only be possible by understanding what changes you did and why, as also how you did validate.

• Made overall response faster

Calling ebike_app_controller twice as often as before.

if((ui16_TIM3_counter - ui16_ebike_app_controller_counter) > 50) // every 50ms

I'm not sure whether it broken something important related to time/power calculation/etc. But it feels as noticeably reduced lag between applying force on pedals and getting assist. Since the ebike_app_controller() function claimed to execute in 35ms, this interval should be ok. Also I made current ramp 16 times steeper that original:

ui32_temp = (((uint32_t) 24375) / ((uint32_t) m_config_vars.ui8_ramp_up_amps_per_second_x10)) >> 4; // see note below

• Made motor a bit low-end biased by sacrificing some performance at crazy high RPM

Changed MOTOR_ROTOR_OFFSET_ANGLE 10 -> 8. Perhaps this should be adjusted for every single motor sample, but for me this led to noticeable increase of torque at low-mid RPM at the same current. With this setting motor can't get past 620 ERPS, and the current is quite low. So I've lost a bit of assist at high RPM, but got some increase in efficiency at normal and low RPM.

• Jerks and bucking are still present sometimes, but they became much gentler
• Shifting gears made softer, introducing less stress to transmission

Increased PWM_DUTY_CYCLE_RAMP_UP_INVERSE_STEP 20->40. This made the motor spin up slower without load (at low RPM, where jerk and bucking happens the most and during gear shift). Despite the fact that bucking still happens, it is so gentle that is almost not noticeable.

• Removed startup boost feature completely. Communications part left for compatibility with the original display v0.8.0 firmware.

The startup boost feature for torque-only mode is in fact pointless. I've removed it completely to kinda compensate increased CPU load due to 50 ms polling interval. This also reduced binary size a bit.

Overall impression is very pleasant, the bike is now much closer to stock FW in terms of responsivity, but much better in smoothness of power delivery and assist adjustment range.

 

[Tommyspar]

Hello Guys, I hope you can help me.

I just build a GT Avalanche with the TSDZ2 but I hate the big VLCD5 Display. Is it possible to use the SW102 Display with Stock Firmware if Yes what I have to do ?