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

Electric Motors and Controllers
casainho   10 GW

10 GW
Posts: 4377
Joined: Feb 14 2011 2:43pm

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

Post by casainho » Apr 09 2020 7:13am

James Broadhurst wrote:
Apr 09 2020 7:10am
Sorry but not even the grandchildren could fix this, why can I not change the colour of the odometer and trip displays from red to white, please? V0.7.0 850C
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.
- TSDZ2 FAQ: issues and repairs, etc
- TSDZ2 OpenSource firmware

Developer of the Flexible OpenSource firmware for EBikes: TSDZ2 mid drive motor, KT motor controllers and displays: Bafang 850C color, SW102 Bluetooth and KT-LCD3.

If you like my work, please consider making a donation. I am being using the donations to buy needed resources for my developments. My paypal: casainho AT gmail.com.

stefkrger   1 mW

1 mW
Posts: 18
Joined: Dec 03 2018 11:49am

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

Post by stefkrger » Apr 09 2020 7:33am

r0mko wrote:
Apr 09 2020 6:48am
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   10 W

10 W
Posts: 79
Joined: Jan 20 2017 8:06pm

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

Post by r0mko » Apr 09 2020 7:38am

stefkrger wrote:
Apr 09 2020 7:33am
r0mko wrote:
Apr 09 2020 6:48am
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-EB ... g/v0.57.10
and the older version:
https://github.com/r0mko/TSDZ2-Smart-EB ... perimental

vshitikov   10 W

10 W
Posts: 69
Joined: Mar 05 2020 7:24am

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

Post by vshitikov » Apr 09 2020 8:12am

stefkrger wrote:
Apr 09 2020 7:33am
r0mko wrote:
Apr 09 2020 6:48am
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-Sma ... eta1.A.pdf

James Broadhurst   10 W

10 W
Posts: 98
Joined: Nov 10 2016 3:29pm
Location: Oxford, England

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

Post by James Broadhurst » Apr 09 2020 1:10pm

casainho wrote:
Apr 09 2020 7:13am
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.

User avatar
windburner   1 W

1 W
Posts: 54
Joined: Sep 24 2019 3:45pm

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

Post by windburner » Apr 10 2020 12:09am

ilu wrote:
Apr 09 2020 6:50am
stefkrger wrote:
Apr 09 2020 4:54am
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-cyc ... rogramming

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.
TerraTrike Rover Tandem - TSDZ2 48V 750W - 13AH Batteries - VLCD6-->SW102/v0.6.8 OSF-->VLCD6 -->XH18

casainho   10 GW

10 GW
Posts: 4377
Joined: Feb 14 2011 2:43pm

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

Post by casainho » Apr 10 2020 4:18am

mbrusa wrote:
Apr 08 2020 2:17pm
hetm4n wrote:
Apr 08 2020 8:36am
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?
- TSDZ2 FAQ: issues and repairs, etc
- TSDZ2 OpenSource firmware

Developer of the Flexible OpenSource firmware for EBikes: TSDZ2 mid drive motor, KT motor controllers and displays: Bafang 850C color, SW102 Bluetooth and KT-LCD3.

If you like my work, please consider making a donation. I am being using the donations to buy needed resources for my developments. My paypal: casainho AT gmail.com.

vshitikov   10 W

10 W
Posts: 69
Joined: Mar 05 2020 7:24am

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

Post by vshitikov » Apr 10 2020 8:58am

casainho wrote:
Apr 10 2020 4:18am
mbrusa wrote:
Apr 08 2020 2:17pm
hetm4n wrote:
Apr 08 2020 8:36am
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   1 W

1 W
Posts: 63
Joined: Oct 22 2019 7:25am

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

Post by plpetrov » Apr 10 2020 10:04am

vshitikov wrote:
Apr 10 2020 8:58am
casainho wrote:
Apr 10 2020 4:18am
mbrusa wrote:
Apr 08 2020 2:17pm
hetm4n wrote:
Apr 08 2020 8:36am
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:
r0mko wrote:
Apr 08 2020 1:37pm
I've released a torque mod for FW v0.57: https://github.com/r0mko/TSDZ2-Smart-EB ... g/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   10 W

10 W
Posts: 97
Joined: Dec 11 2019 12:13am

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

Post by mbrusa » Apr 10 2020 11:43am

casainho wrote:
Apr 10 2020 4:18am
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.
Flexible OpenSource firmware for TongSheng TSDZ2 motor and VLCD5 VLCD6 XH18 displays
https://github.com/emmebrusa/TSDZ2-Smart-EBike-1

casainho   10 GW

10 GW
Posts: 4377
Joined: Feb 14 2011 2:43pm

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

Post by casainho » Apr 10 2020 3:45pm

hetm4n wrote:
Apr 08 2020 8:36am
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:

Code: Select all

- #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));
mbrusa wrote:
Apr 10 2020 11:43am
casainho wrote:
Apr 10 2020 4:18am
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.
- TSDZ2 FAQ: issues and repairs, etc
- TSDZ2 OpenSource firmware

Developer of the Flexible OpenSource firmware for EBikes: TSDZ2 mid drive motor, KT motor controllers and displays: Bafang 850C color, SW102 Bluetooth and KT-LCD3.

If you like my work, please consider making a donation. I am being using the donations to buy needed resources for my developments. My paypal: casainho AT gmail.com.

User avatar
hetm4n   100 mW

100 mW
Posts: 37
Joined: Aug 29 2019 6:30am

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

Post by hetm4n » Apr 10 2020 7:30pm

casainho wrote:
Apr 10 2020 3:45pm


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

Code: Select all

- #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 :)
mongoose teocali comp 2014 TSDZ2 750W 13s3p & 13s7p
dartmoor primal 2017 bafang BBS02b 750W 13s6p

ilu   1 W

1 W
Posts: 62
Joined: Oct 18 2019 10:51am

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

Post by ilu » Apr 11 2020 4:27am

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   100 W

100 W
Posts: 150
Joined: Jul 12 2019 12:42am
Location: Switzerland

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

Post by skestans » Apr 11 2020 5:25am

ilu wrote: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   100 W

100 W
Posts: 150
Joined: Jul 12 2019 12:42am
Location: Switzerland

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

Post by skestans » Apr 11 2020 5:31am

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   10 W

10 W
Posts: 69
Joined: Mar 05 2020 7:24am

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

Post by vshitikov » Apr 11 2020 8:31am

skestans wrote:
Apr 11 2020 5:25am
ilu wrote: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   100 W

100 W
Posts: 150
Joined: Jul 12 2019 12:42am
Location: Switzerland

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

Post by skestans » Apr 11 2020 8:51am

vshitikov wrote:
skestans wrote:
Apr 11 2020 5:25am
ilu wrote: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.

User avatar
hetm4n   100 mW

100 mW
Posts: 37
Joined: Aug 29 2019 6:30am

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

Post by hetm4n » Apr 11 2020 9:22am

casainho wrote:
Apr 10 2020 3:45pm


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

Code: Select all

- #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.
mongoose teocali comp 2014 TSDZ2 750W 13s3p & 13s7p
dartmoor primal 2017 bafang BBS02b 750W 13s6p

casainho   10 GW

10 GW
Posts: 4377
Joined: Feb 14 2011 2:43pm

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

Post by casainho » Apr 11 2020 9:30am

hetm4n wrote:
Apr 11 2020 9:22am
casainho wrote:
Apr 10 2020 3:45pm


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

Code: Select all

- #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?
- TSDZ2 FAQ: issues and repairs, etc
- TSDZ2 OpenSource firmware

Developer of the Flexible OpenSource firmware for EBikes: TSDZ2 mid drive motor, KT motor controllers and displays: Bafang 850C color, SW102 Bluetooth and KT-LCD3.

If you like my work, please consider making a donation. I am being using the donations to buy needed resources for my developments. My paypal: casainho AT gmail.com.

vshitikov   10 W

10 W
Posts: 69
Joined: Mar 05 2020 7:24am

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

Post by vshitikov » Apr 11 2020 9:37am

skestans wrote:
Apr 11 2020 8:51am
vshitikov wrote:
skestans wrote:
Apr 11 2020 5:25am
ilu wrote: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   1 W

1 W
Posts: 63
Joined: Oct 22 2019 7:25am

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

Post by plpetrov » Apr 11 2020 10:05am

casainho wrote:
Apr 11 2020 9:30am
hetm4n wrote:
Apr 11 2020 9:22am
casainho wrote:
Apr 10 2020 3:45pm


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

Code: Select all

- #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.

User avatar
hetm4n   100 mW

100 mW
Posts: 37
Joined: Aug 29 2019 6:30am

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

Post by hetm4n » Apr 11 2020 11:51am

Casainho Stopping the engine after stopping pedaling is probably identical, I can not distinguish it.
mongoose teocali comp 2014 TSDZ2 750W 13s3p & 13s7p
dartmoor primal 2017 bafang BBS02b 750W 13s6p

r0mko   10 W

10 W
Posts: 79
Joined: Jan 20 2017 8:06pm

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

Post by r0mko » Apr 11 2020 1:49pm

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-EB ... g/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   10 GW

10 GW
Posts: 4377
Joined: Feb 14 2011 2:43pm

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

Post by casainho » Apr 11 2020 2:35pm

r0mko wrote:
Apr 11 2020 1:49pm
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-EB ... g/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.
- TSDZ2 FAQ: issues and repairs, etc
- TSDZ2 OpenSource firmware

Developer of the Flexible OpenSource firmware for EBikes: TSDZ2 mid drive motor, KT motor controllers and displays: Bafang 850C color, SW102 Bluetooth and KT-LCD3.

If you like my work, please consider making a donation. I am being using the donations to buy needed resources for my developments. My paypal: casainho AT gmail.com.

r0mko   10 W

10 W
Posts: 79
Joined: Jan 20 2017 8:06pm

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

Post by r0mko » Apr 11 2020 3:00pm

casainho wrote:
Apr 11 2020 2:35pm

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 wrote:
Apr 11 2020 1:49pm
  • Made overall response faster
Calling ebike_app_controller twice as often as before.

Code: Select all

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:

Code: Select all

ui32_temp = (((uint32_t) 24375) / ((uint32_t) m_config_vars.ui8_ramp_up_amps_per_second_x10)) >> 4; // see note below
r0mko wrote:
Apr 11 2020 1:49pm
  • 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.
r0mko wrote:
Apr 11 2020 1:49pm
  • 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.
r0mko wrote:
Apr 11 2020 1:49pm
  • 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.

Post Reply