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

[Dirkro]

Just some testing on the inverse ramp factor to reduce lag

Hello,
I'm new to this forum. I just installed and flushed Kt-lcd3 with my TSDZ2. I also experience this lag which you have mentioned before and would love to fix if but I don't now how. I already checked WiKi and watched your video about it and still didn't figure it out.
It it's not too much to ask could you please step by step guide me what exactly I have to do.
How to compile?
How to flash if back to the controller?

P. S. I really like your videos about installing and flashing Kt-lcd3 with TSDZ2.

Grisham I made one change to the variable using version 16 and that eliminated the drag for me. As I have not moved to any newer versions of the firmware I cannot comment as to whether it has been addressed or not. At the time boost mode was causing issues and had to be disabled. Perhaps someone else can answer. If this is fixed then you won’t need to compile it yourself.
Thanks
JB

I think the function is implemented in the setup menue under item 7.2 Curent ramp up per second . Standard is 5, can be set up to 10. I would like to set it up to 12-15 if you ask me.

[Dirkro]

Hi,
I made mesurments with input by an old style analog torque wrench and the values shown at menue 9.2
Input Value 9.2
0 Nm 50
10 Nm 60
20 Nm 69
30 Nm 78
40 Nm 91
50 Nm (98) maybe not fuly correct

I hope this helps to improve the calculation of input power. I am ready for testing
Maybe we can try the simple way by calculating the power evey 1/10 second (I think that is the cycle in the software)
Use the average of last 4 (last 0.4 second ) values of rpms and torque.

[daenny]

I just upgraded from 0.17 to 0.19 beta 8 I have to say I am very impressed! I just did a quick 500m around the block, and the bike feels as if I upgraded the motor
Of course, this is just an initial impression. I will commute to work ~9km one way tomorrow, so hopefully my first good impressions will be confirmed.

My setup is: 12s LiPo, 48V motor (set now on High Cadence mode), boost always enabled, start-without pedal rotation disabled (no ebrakes), no throttle, no tempsensor, no walk-assist, no cruise-control. Street-mode (limited to 27km/h) is enabled on startup

Things I have noticed:

- New button logic in settings is much more intuitive. One thing to consider might be to also allow short on/off presses to go back one level when in the lowest level, i.e. after changing a value. For instance, in the bike screen setup somehow all my settings were set to 0. So I needed to do: Short press on/off (go into level change mode), press up (change value to 1), long press on/off (go back), press up (select next sublevel), short-press on/off (select), press up (change value), long press on/off (go back), etc.
For me, in would have felt intuitive to short-press on/off to go back after changing the value.
- The motor is much quicker to respond, (I did not test 48v without high cadence mode yet)
- High cadence mode allows 110rpm cadence with just little power loss, whereas before the motor drastically lost power above 80-90 rpm
- I did not encounter the dreaded 2 second lags yet
- on very low torque, e.g. riding slowly in a low gear on a even surface, I previously had the the motor was switching on and off, this seemed a lot better in my first test
- Drag will pushing the bike back is gone

Thank you guys for the hard work!

[buba]

I think the function is implemented in the setup menue under item 7.2 Curent ramp up per second . Standard is 5, can be set up to 10. I would like to set it up to 12-15 if you ask me.

Will remember this for the next version. Definitely possible to increase the current ramp up.

Hi,
I made mesurments with input by an old style analog torque wrench and the values shown at menu 9.2:

Input Value 9.2
0 Nm 50
10 Nm 60
20 Nm 69
30 Nm 78
40 Nm 91
50 Nm (98) maybe not fully correct

I hope this helps to improve the calculation of input power. I am ready for testing
Maybe we can try the simple way by calculating the power evey 1/10 second (I think that is the cycle in the software)
Use the average of last 4 (last 0.4 second ) values of rpms and torque.

Thank you very much for the data and the willingness to test! The more data we have the better!

After the stable 0.19.0 release we can take a look at improving everything even more.

In short, you wish for a faster updating cadence value and more accurate human power measurements?

[buba]

I just upgraded from 0.17 to 0.19 beta 8 I have to say I am very impressed! I just did a quick 500m around the block, and the bike feels as if I upgraded the motor
Of course, this is just an initial impression. I will commute to work ~9km one way tomorrow, so hopefully my first good impressions will be confirmed.

My setup is: 12s LiPo, 48V motor (set now on High Cadence mode), boost always enabled, start-without pedal rotation disabled (no ebrakes), no throttle, no tempsensor, no walk-assist, no cruise-control. Street-mode (limited to 27km/h) is enabled on startup

- New button logic in settings is much more intuitive. One thing to consider might be to also allow short on/off presses to go back one level when in the lowest level, i.e. after changing a value. For instance, in the bike screen setup somehow all my settings were set to 0. So I needed to do: Short press on/off (go into level change mode), press up (change value to 1), long press on/off (go back), press up (select next sublevel), short-press on/off (select), press up (change value), long press on/off (go back), etc.
For me, in would have felt intuitive to short-press on/off to go back after changing the value.

The user elfnino mentioned something similar when testing a previous beta.

#new button logic - to exit the submenu once the value is set the long press of on/off button is required however I think just a short press would be enough.
Now by exiting submenu with the long press I have ended occasionally two levels higher than initially wanted as well it takes more time to configure parameters.

Good note! I have decreased the time needed to hold the button. Much faster now but still not a click. I strongly believe it is best to have two different button events/actions for different menu actions so as to have a clear logic. I truly recommend this and would love that you test the new faster logic in the next beta as it should be better!

So after the feedback from elfnino, the button hold time was drastically reduced for the beta 8, daenny. But I understand you still feel it is slow. If you do not mind I will take a look at it and try to improve it for future versions. This is so that we can release a new stable version for all users and finally finish the development on the 0.19.0.

- The motor is much quicker to respond, (I did not test 48v without high cadence mode yet)
- High cadence mode allows 110rpm cadence with just little power loss, whereas before the motor drastically lost power above 80-90 rpm
- I did not encounter the dreaded 2 second lags yet
- on very low torque, e.g. riding slowly in a low gear on a even surface, I previously had the the motor was switching on and off, this seemed a lot better in my first test
- Drag will pushing the bike back is gone

Thank you guys for the hard work!

Thanks for the analysis and feedback! Always interesting to hear. Especially when it seems that you are very satisfied with the 0.19.0 beta 8.

[btslo]

Just some testing on the inverse ramp factor to reduce lag

Hello,
I'm new to this forum. I just installed and flushed Kt-lcd3 with my TSDZ2. I also experience this lag which you have mentioned before and would love to fix if but I don't now how. I already checked WiKi and watched your video about it and still didn't figure it out.
It it's not too much to ask could you please step by step guide me what exactly I have to do.
How to compile?
How to flash if back to the controller?

P. S. I really like your videos about installing and flashing Kt-lcd3 with TSDZ2.

Grisham I made one change to the variable using version 16 and that eliminated the drag for me. As I have not moved to any newer versions of the firmware I cannot comment as to whether it has been addressed or not. At the time boost mode was causing issues and had to be disabled. Perhaps someone else can answer. If this is fixed then you won’t need to compile it yourself.
Thanks
JB

I think the function is implemented in the setup menue under item 7.2 Curent ramp up per second . Standard is 5, can be set up to 10. I would like to set it up to 12-15 if you ask me.

Is this used to reduce lag? There is still too much lag from 0 for my taste, for example it's impossible to wheelie from a standstill as power comes on later after about a second (I don't use boost as there is even more lag probably) Max ramp up I tried was 7 since I assumed higher values could damage the controller or blue gear. Torque values change instantly after you push on the pedals but takes some time for the power to come.

Also is it normal for the motor to still deliver power for about 1-2RPM after you stop pedalling? (especially in higher assists, similar to stock turbo mode, I have boost disabled)

And it seems the motor is louder than on stock firmware. Will try to grease it but it's already loud by design.

[Dirkro]

I think the function is implemented in the setup menue under item 7.2 Curent ramp up per second . Standard is 5, can be set up to 10. I would like to set it up to 12-15 if you ask me.

Will remember this for the next version. Definitely possible to increase the current ramp up.

Hi,
I made mesurments with input by an old style analog torque wrench and the values shown at menu 9.2:

Input Value 9.2
0 Nm 50
10 Nm 60
20 Nm 69
30 Nm 78
40 Nm 91
50 Nm (98) maybe not fully correct

I hope this helps to improve the calculation of input power. I am ready for testing
Maybe we can try the simple way by calculating the power evey 1/10 second (I think that is the cycle in the software)
Use the average of last 4 (last 0.4 second ) values of rpms and torque.

Thank you very much for the data and the willingness to test! The more data we have the better!

After the stable 0.19.0 release we can take a look at improving everything even more.

In short, you wish for a faster updating cadence value and more accurate human power measurements?

Yes,you are right
There might be a bug in the calculation!!
In my setup, at a cadence of maybe 90 it takes about (feeling) 20 Seconds to climnb from 70 to 89. Zero is reached in one second , when stoping pedealing, when I start agaín (feels like 80 to 85) it is starting with 50,then climbing 60 , 70 but takes time !

Another thing, what can maybe be solved fast:
Could you please change the maximum Ramp maybe 15 A/s , it is 10A/s now (Menue 7.2)
Thank you very much!

[buba]

Thank you very much for the data and the willingness to test! The more data we have the better!

After the stable 0.19.0 release we can take a look at improving everything even more.

In short, you wish for a faster updating cadence value and more accurate human power measurements?

Yes,you are right
There might be a bug in the calculation!!
In my setup, at a cadence of maybe 90 it takes about (feeling) 20 Seconds to climnb from 70 to 89. Zero is reached in one second , when stoping pedealing, when I start agaín (feels like 80 to 85) it is starting with 50,then climbing 60 , 70 but takes time !

Another thing, what can maybe be solved fast:
Could you please change the maximum Ramp maybe 15 A/s , it is 10A/s now (Menue 7.2)
Thank you very much!

There is a filter in the KT-LCD3 that filters the values. Have not developed this so can not say anything more about this except I will take a look at it. Thank you for the explanation, always great with detailed feedback!

Will change the current ramp up so a higher value can be used. But this will be made after the official 0.19.0 release. This is so the community can switch over to the stable 0.19.0 without creating another beta.

[thineight]

Hello! Is the stable 0.19 released soon? If so, I just avoid to install the beta8.. or is it the same?

[buba]

Hello! Is the stable 0.19 released soon? If so, I just avoid to install the beta8.. or is it the same?

Hello! I recommend to install the beta 8. If no one reports any errors the beta 8 will become the stable release. So you do not need to update then.

[thineight]

Hello! Is the stable 0.19 released soon? If so, I just avoid to install the beta8.. or is it the same?

Hello! I recommend to install the beta 8. If no one reports any errors the beta 8 will become the stable release. So you do not need to update then.

Done it! Looks great so far!!
There is just some wording mistakes left on the wiki due to the street-offroad logic change (e.g. menu 5-9).

As I consider more logic to have the street mode without the blinking ASSIST, I was wondering if I can invert the power and speed settings between the street and off-road menus, or if other functions act different between the two modes.

One last thing: in my case the assist 1 and 2 are set to 0.1 and 0.2 respectively (i.e. lower than most of the people here), as a consequence I have a delay in motor start due to the, let me call it this way, "actual resolution" of the motor.
With assistance 0.1 my motor kicks in with the minimum 20W only when my human power is 200W from the display, so after a little while. I guess there is a sort of ROUND function somewhere that cuts to 0 the motor power below 20W..
I guess this is happening only at very low assistance levels (not many people affected then), maybe after the release of the stable 0.19 we could evaluate to keep the minimum motor power instead of zero in the low ranges.

2019-06-11_232244.png (54.06 KiB) Viewed 1401 times

I think the actual logic follows the yellow path, leading to no assistance for the time from 0 to t0.
My idea is that the minimum motor power (20W) could be delivered also from 0 to t0, and after keep following the yellow path at higher assistance.
Please correct me if this idea is not applicable.
Many thanks.

[buba]

Hello! Is the stable 0.19 released soon? If so, I just avoid to install the beta8.. or is it the same?

Hello! I recommend to install the beta 8. If no one reports any errors the beta 8 will become the stable release. So you do not need to update then.

Done it! Looks great so far!!
There is just some wording mistakes left on the wiki due to the street-offroad logic change (e.g. menu 5-9).

Great!

Fixed! As always, thanks!

Wiki: https://github.com/OpenSource-EBike-fir ... ion-0.19.X

As I consider more logic to have the street mode without the blinking ASSIST, I was wondering if I can invert the power and speed settings between the street and off-road menus, or if other functions act different between the two modes.

Totally possible but the quick-set-power-menu will not be accessible in Street Mode. And if you wish to have throttle disabled in Street Mode (new feature) it will only work when in Street Mode. But if you are not using these features there is no problem at all.

I think there will be a future update where users can choose if they wish to have it blinking in Offroad Mode, Street Mode or not at all.

One last thing: in my case the assist 1 and 2 are set to 0.1 and 0.2 respectively (i.e. lower than most of the people here), as a consequence I have a delay in motor start due to the, let me call it this way, "actual resolution" of the motor.
With assistance 0.1 my motor kicks in with the minimum 20W only when my human power is 200W from the display, so after a little while. I guess there is a sort of ROUND function somewhere that cuts to 0 the motor power below 20W..
I guess this is happening only at very low assistance levels (not many people affected then), maybe after the release of the stable 0.19 we could evaluate to keep the minimum motor power instead of zero in the low ranges.

2019-06-11_232244.png

I think the actual logic follows the yellow path, leading to no assistance for the time from 0 to t0.
My idea is that the minimum motor power (20W) could be delivered also from 0 to t0, and after keep following the yellow path at higher assistance.
Please correct me if this idea is not applicable.
Many thanks.

The "actual resolution" of the motor you speak of is actually extended throughout the operating range of the motor. This is due to the control algorithm relying on low resolution analog-to-digital-converters.

human power and motor power.png (6.76 KiB) Viewed 1398 times

But it is basically not noticeable except at the lower range.

I would presume that you wish for a smoother start with more resolution in said range. That is possible to implement in one way or another and something I have wanted to improve!

[thineight]

Thanks buba, crystal clear!

For the blinking assist I can wait without problem.. this is a very low priority task.

For the initial power at low assistance I guess I can tackle the issue using the boost function (which I did not use so far), set for instance to 2.0 at assistance 1 (0.1) and 1.0 to the others where the delay is negligible.
Any future improvement is welcome anyway.

I will try to setup the boost and will report.
Thanks.

[Uturn]

If no one reports any errors

I have the tiny problem that the assist seems to switch on less quick than on 0.18. I drive PAS mode, and before, motor power came after 1/4 pedal turn. Now with 0.19 beta 8 I feel sometimes it will take 360° till the motor kicks in. (Motor only on torque sensor I tried but I do not like it).

[casainho]

Usage of battery SOC based on Coulomb counting

I wounder how many users are using this feature on LCD3.

LCD3 implements 2 different ways to measure SOC: battery voltage and Coulomb counting.

There is an user reporting incorrect working of Coulomb counting SOC but I think is a bad configuration he did on LCD3 because he does not understand the configuration parameters. Battery voltage SOC on the other way is very simple to configure and seems good enough for me however, at begin of this project, I though battery voltage way would not be good enough.

If no one is using the SOC based on Coulomb counting, we could just remove it and that would make short the number of options on LCD3, avoid configuration error by the user, etc.

[Dirkro]

Usage of battery SOC based on Coulomb counting

I wounder how many users are using this feature on LCD3.

LCD3 implements 2 different ways to measure SOC: battery voltage and Coulomb counting.

There is an user reporting incorrect working of Coulomb counting SOC but I think is a bad configuration he did on LCD3 because he does not understand the configuration parameters. Battery voltage SOC on the other way is very simple to configure and seems good enough for me however, at begin of this project, I though battery voltage way would not be good enough.

If no one is using the SOC based on Coulomb counting, we could just remove it and that would make short the number of options on LCD3, avoid configuration error by the user, etc.

Hi,
if you mean the backwards (forward) counting of the battery mW , then I can say that I am a fan of this feature and I use it regulary! For me one of the highlights

[casainho]

Hi,
if you mean the backwards (forward) counting of the battery mW , then I can say that I am a fan of this feature and I use it regulary! For me one of the highlights

And why? Can you please elaborate and compare with the other mode??

[zappan]

I installed the ver. 0.19.08 the best I've ever tried, starting from Ver. 07 almost a year ago.
Congratulations to all the developers.

[thineight]

Hi,
if you mean the backwards (forward) counting of the battery mW , then I can say that I am a fan of this feature and I use it regulary! For me one of the highlights

And why? Can you please elaborate and compare with the other mode??

If the function you mention is the SoC from 100 to 0 based on the Wh consumed Vs the battery capacity.. I like that one as well.
It is easier to read than relying on a voltage reading (that is non linear with the discharge as far as I remember)..

But I also understand the fact that if you guys need more space for other useful function.. we can live without that indicator.

[Nick]

Usage of battery SOC based on Coulomb counting

I wounder how many users are using this feature on LCD3.

LCD3 implements 2 different ways to measure SOC: battery voltage and Coulomb counting.

There is an user reporting incorrect working of Coulomb counting SOC but I think is a bad configuration he did on LCD3 because he does not understand the configuration parameters. Battery voltage SOC on the other way is very simple to configure and seems good enough for me however, at begin of this project, I though battery voltage way would not be good enough.

If no one is using the SOC based on Coulomb counting, we could just remove it and that would make short the number of options on LCD3, avoid configuration error by the user, etc.

+1

I use the counting of consumed Wh, too! Found my battery cell used in my pack here:
http://www.dampfakkus.de/akkutest.php?id=537
They tested the real Wh of one cell say at 2A and I can calculate the real Wh of my battery pack with this.
Even if the voltage drop is quite linear in the middle, some cells drop very fast at the end and Voltage-SOC will be quite unreliable there (when it is most important for me ).

Best regards
Niklas

[Dirkro]

Hi,
if you mean the backwards (forward) counting of the battery mW , then I can say that I am a fan of this feature and I use it regulary! For me one of the highlights

And why? Can you please elaborate and compare with the other mode??

For me this is the only reliable way to calculate the expected range while riding.
I have a battery with a quite high resistance (> 200 mOhm ) When I look at the current while I am standing still after a ride it is slowly going up during the first one or two in the range of 0.4V

My Battery is able to give me 350 Wh, counting back. So this counting is much more precise then the Voltage .

[casainho]

Well, then maybe we could consider to make the graph change with this SOC instead of voltage and this be a configuration -- and I mean for future LCDs like SW102 and 850C because they have enough memory to implement that.

I really thought no one was using this feature...

[Uturn]

If no one reports any errors

assist seems to switch on less quick than on 0.18

I think this is related to having set the support level a bit lower than before, so it's not a problem.

[daenny]

Well, then maybe we could consider to make the graph change with this SOC instead of voltage and this be a configuration -- and I mean for future LCDs like SW102 and 850C because they have enough memory to implement that.

I really thought no one was using this feature...

I am also using the Wh counting, as I only use my LiPo cells from ~3.6V-4.1V as this prolongs the life of the cells. Thus the voltage based icon is useless for me as it shows half, when the cells are actually empty. I think it would be a great addition that the Icon uses Wh counting as SOC indication when this feature is enabled and Voltage if the Wh counting is disabled.

[spiked]

Well, then maybe we could consider to make the graph change with this SOC instead of voltage and this be a configuration -- and I mean for future LCDs like SW102 and 850C because they have enough memory to implement that.

I really thought no one was using this feature...

I am also using the Wh counting, as I only use my LiPo cells from ~3.6V-4.1V as this prolongs the life of the cells. Thus the voltage based icon is useless for me as it shows half, when the cells are actually empty. I think it would be a great addition that the Icon uses Wh counting as SOC indication when this feature is enabled and Voltage if the Wh counting is disabled.

I also rely heavily on the Wh counting feature, with my old Ping LiFePO4 battery. 5+ years old and still going strong!

Wh counting seems to work well for me - what was the problem reported?

Neil

P.S. I'm still on 17, about to make the move to 19.8.