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

andrea_104kg · Jul 21, 2019

Buba compliments again for the hard work.
I imagine that the cadence mode is more suitable for city bikes than mountain bikes. The original torque mode scares me a little because I hated the original engine. I hope the power mode is improved, that is the same as version 19. However, the non-expert user will have to test all the ways to choose the most suitable one, his routes and I don't think it will be easy. can you better explain how the emtb mode will work? Thanks again!

buba · Jul 21, 2019

casainho said:
buba said:

But I think that you would rather I remove the entire "Cadence Double Resolution" and save that particular thing for the future.

Click to expand...

Let's see first how all of this works.

If we are talking about shutoff, why not start using different cadence values, one for startup and other for shutoff?

Have implemented that: it changes the minimum cadence limit depending on wheel speed. To be able to have nice startups you need a lower limit. But that increases the power-off lag. So to decrease the lag we set the minimum cadence limit higher depending on the wheel speed.

Also, it is very important to use a software based Schmitt trigger and actually immediately decrease the minimum cadence limit slightly as soon as the pedals are rotating. This filters very slow pedal rotations and transitions between "off" and "on" in regard to measured cadence. Because when we are rotating the pedals very slowly at the minimum cadence limit without the Schmitt trigger it would transition very often between different states and cause the motor to jitter.

casainho · Jul 21, 2019

buba said:
casainho said:

buba said:

But I think that you would rather I remove the entire "Cadence Double Resolution" and save that particular thing for the future.

Click to expand...

Let's see first how all of this works.

If we are talking about shutoff, why not start using different cadence values, one for startup and other for shutoff?

Click to expand...

Have implemented that: it changes the minimum cadence limit depending on wheel speed. To be able to have nice startups you need a lower limit. But that increases the power-off lag. So to decrease the lag we set the minimum cadence limit higher depending on the wheel speed.

Also, it is very important to use a software based Schmitt trigger and actually immediately decrease the minimum cadence limit slightly as soon as the pedals are rotating. This filters very slow pedal rotations and transitions between "off" and "on" in regard to measured cadence. Because when we are rotating the pedals very slowly at the minimum cadence limit without the Schmitt trigger it would transition very often between different states and cause the motor to jitter.

ok, good to know.

buba · Jul 21, 2019

elfnino said:
casainho said:

buba said:

But I think that you would rather I remove the entire "Cadence Double Resolution" and save that particular thing for the future.

Click to expand...

Let's see first how all of this works.

If we are talking about shutoff, why not start using different cadence values, one for startup and other for shutoff?

Click to expand...

In my humble opinion minimizing any startup/shutoff delay should be always one of the highest priority even if it would require more complex configuration or calibration. It is more natural, it improves a lot user experience especially in more technical bike riding when higher delay can disturb rider balance
Anyway you are doing the great job! and I trust you that you will find the best compromise to mitigate the delay :wink:

Your and everyone else's opinion in this community is everything! If no one engages in the discussion we would be developing blindly. Thank you so much, elfnino!

Rafe · Jul 21, 2019

buba said:
Quick update to the community:

Will add Casainho's branch where the torque is measured and approximated every pedal revolution, then my local eMTB branch and then there are the suggestions from users I will implement the next couple of days. Also need to update the wiki.

We will have a 0.20.0 beta out this coming week!

I won't pretend to understand the recent discourse Buba but I hope it doesn't mean You will drop the modifications you have talked about for the next Beta, I for one have really been looking forward to them and I am sure others have too. Your hard work most of it behind the scenes is really appreciated

casainho · Jul 21, 2019

buba said:
Quick update to the community:

Will add Casainho's branch where the torque is measured and approximated every pedal revolution, then my local eMTB branch and then there are the suggestions from users I will implement the next couple of days. Also need to update the wiki.

Are you interested in implementing the torque sensor calibration (on motor controller firmware) for taking advantage of the full range up to the 110 kgs? -- I understand it probably will not work on KT-LCD3 but I can do it quickly on 850C.

If not, I can do it. My current focus is the 850C.

buba · Jul 21, 2019

andrea_104kg said:
Buba compliments again for the hard work.

Thank you, andrea_104kg!

andrea_104kg said:
Buba compliments again for the hard work.
I imagine that the cadence mode is more suitable for city bikes than mountain bikes. The original torque mode scares me a little because I hated the original engine. I hope the power mode is improved, that is the same as version 19.

It will be improved and the control is much better!

andrea_104kg said:
However, the non-expert user will have to test all the ways to choose the most suitable one, his routes and I don't think it will be easy. can you better explain how the emtb mode will work? Thanks again!

Will try to give a better explanation of all riding modes! Will also try to finish the development the next couple of days so we can have a beta out for testing. A test ride will be the best way to judge a riding mode and I hope you will enjoy it!

buba · Jul 21, 2019

Rafe said:
buba said:

Quick update to the community:

Will add Casainho's branch where the torque is measured and approximated every pedal revolution, then my local eMTB branch and then there are the suggestions from users I will implement the next couple of days. Also need to update the wiki.

We will have a 0.20.0 beta out this coming week!

Click to expand...

I won't pretend to understand the recent discourse Buba but I hope it doesn't mean You will drop the modifications you have talked about for the next Beta, I for one have really been looking forward to them and I am sure others have too. Your hard work most of it behind the scenes is really appreciated

Thank you, Rafe! Appreciate it!

We will try to keep everything as planned for now. I will focus on completing my development version the next couple of days so a beta can be released with all my work included.

buba · Jul 21, 2019

casainho said:
buba said:

Quick update to the community:

Will add Casainho's branch where the torque is measured and approximated every pedal revolution, then my local eMTB branch and then there are the suggestions from users I will implement the next couple of days. Also need to update the wiki.

Click to expand...

Are you interested in implementing the torque sensor calibration (on motor controller firmware) for taking advantage of the full range up to the 110 kgs? -- I understand it probably will not work on KT-LCD3 but I can do it quickly on 850C.

If not, I can do it. My current focus is the 850C.

I will focus on completing my development version so it can be merged in master. Look forward to adding your torque sensing for every pedal rotation as I think there is a possibility that it not only will give us better human power values but also add a better response when user is pedaling in a higher cadence. Have a really nice implementation in mind I think you will like.

casainho · Jul 21, 2019

buba said:
casainho said:

buba said:

Quick update to the community:

Will add Casainho's branch where the torque is measured and approximated every pedal revolution, then my local eMTB branch and then there are the suggestions from users I will implement the next couple of days. Also need to update the wiki.

Click to expand...

Are you interested in implementing the torque sensor calibration (on motor controller firmware) for taking advantage of the full range up to the 110 kgs? -- I understand it probably will not work on KT-LCD3 but I can do it quickly on 850C.

If not, I can do it. My current focus is the 850C.

Click to expand...

I will focus on completing my development version so it can be merged in master. Look forward to add your torque sensing for every pedal rotation as I think there is a possibility that it not only will give us better human power values but also add a better response when user is pedaling in a higher cadence. Have a really nice implementation in mind I think you will like.

I really think we should go with that full calibration, even if it is for a next version after 0.20.0. I think is is not very hard for user to do it, it needs a cheap digital fish scale bought on eBay/China. For a start, we should use default calibration values that works ok for everyone, should not be worst than what is currently -- so user will do it only if is really interested in having a much better motor response to the real human power in pedals.

From the technical point, this is not hard to implement and also does not represent any big risk to the current stable firmware.

I suggest you to remove the more simple torque sensor calibration you did so that way will not bring confusion to users between different firmware versions as also LCDs.

buba · Jul 21, 2019

casainho said:
buba said:

casainho said:

buba said:

Quick update to the community:

Will add Casainho's branch where the torque is measured and approximated every pedal revolution, then my local eMTB branch and then there are the suggestions from users I will implement the next couple of days. Also need to update the wiki.

Click to expand...

Are you interested in implementing the torque sensor calibration (on motor controller firmware) for taking advantage of the full range up to the 110 kgs? -- I understand it probably will not work on KT-LCD3 but I can do it quickly on 850C.

If not, I can do it. My current focus is the 850C.

Click to expand...

I will focus on completing my development version so it can be merged in master. Look forward to add your torque sensing for every pedal rotation as I think there is a possibility that it not only will give us better human power values but also add a better response when user is pedaling in a higher cadence. Have a really nice implementation in mind I think you will like.

Click to expand...

I really think we should go with that full calibration, even if it is for a next version after 0.20.0. I think is is not very hard for user to do it, it needs a cheap digital fish scale bought on eBay/China. For a start, we should use default calibration values that works ok for everyone, should not be worst than what is currently -- so user will do it only if is really interested in having a much better motor response to the real human power in pedals.

From the technical point, this is not hard to implement and also does not represent any big risk to the current stable firmware.

I suggest you to remove the more simple torque sensor calibration you did so that way will not bring confusion to users between different firmware versions as also LCDs.

I totally agree! We can focus on the calibration for the 0.21.0 and improve everything even more in that version. Even if it is only for the 850C due to the lack of program space in KT-LCD3.

0.20.0 has some great changes and I think it will be a nice upgrade from 0.19.0!

casainho said:
For a start, we should use default calibration values that works ok for everyone, should not be worst than what is currently -- so user will do it only if is really interested in having a much better motor response to the real human power in pedals.

Just wanted to add that it is great that users will have the option to choose if they want to calibrate the torque sensor or not. If someone wants more torque sensor range it is possible to setup. For others that want a more simple system you can just use the default values.

thineight · Jul 21, 2019

Really thanks for the hard work buba.
Look great the improvements you mentioned in this new beta, looking forward to try it out.

In case we need more space in the LCD3 (I guess it's the most used display for this firmware) have you considered to remove some functions? Hard to scrap some work done.. but perhaps beneficial.
My personal opinion for functions that can be removed, if needed:

- startup boost (as suggested by a user couple of weeks ago), with the quicker response from the system the boost function results perhaps not strictly necessary

- estimated range left: I was a promoter of this function long ago, but the way was implemented is not really useful because it does not update the range "live" as it uses the watts consumed from the startup instead of the actual consumption.

Not sure if this, in case the community considers viable, can free up enough memory for the new features.

Again, thanks for the proactivity, the great ideas and all the effort you put in the coding! :bigthumb:

buba · Jul 21, 2019

thineight said:
Really thanks for the hard work buba.
Look great the improvements you mentioned in this new beta, looking forward to try it out.

Appreciate it, thineight! Hope you will like the changes and improvements!

thineight said:
In case we need more space in the LCD3 (I guess it's the most used display for this firmware) have you considered to remove some functions? Hard to scrap some work done.. but perhaps beneficial.
My personal opinion for functions that can be removed, if needed:

- startup boost (as suggested by a user couple of weeks ago), with the quicker response from the system the boost function results perhaps not strictly necessary

- estimated range left: I was a promoter of this function long ago, but the way was implemented is not really useful because it does not update the range "live" as it uses the watts consumed from the startup instead of the actual consumption.

Not sure if this, in case the community considers viable, can free up enough memory for the new features.

Think it will be possible to manage everything just by optimizing but if it becomes a problem I will definitely ask the community for advice such as yours! Thank you for sharing your view as it helps to know what the community is thinking!

thineight said:
Again, thanks for the proactivity, the great ideas and all the effort you put in the coding!

Thank you! And do not forget to use and test your bike in the meantime :wink: When testing the 0.20.0 there will be a difference in pretty much everything so it is good to remember how it used to be! I hope all users test and get to know the 0.19.0 so we can better evaluate the 0.20.0!

casainho · Jul 21, 2019

thineight said:
In case we need more space in the LCD3 (I guess it's the most used display for this firmware) have you considered to remove some functions? Hard to scrap some work done.. but perhaps beneficial.
My personal opinion for functions that can be removed, if needed:

- startup boost (as suggested by a user couple of weeks ago), with the quicker response from the system the boost function results perhaps not strictly necessary

- estimated range left: I was a promoter of this function long ago, but the way was implemented is not really useful because it does not update the range "live" as it uses the watts consumed from the startup instead of the actual consumption.

I don't use anymore LCD3 so this is not about me but what I think the project should be.

I clear remember some users saying that they use the Startup Boost feature, but maybe they are now riding instead of being here following this thread and giving feedback.

I also think that users decided to use this project (like buying a product) based on the features on that time and the features should not be removed anymore.

I think that KT-LCD3 firmware + TSDZ2 motor controller firmware pair should be closed to new features and be in maintenance mode only.

The 850C LCD firmware + TSDZ2 motor controller firmware pair should be another project and with specific features if makes sense. And we need to be very careful with new adding features, maybe marking versions as experimental/testing before release as stable and decide to keep the new features or not.

jimmyfergus · Jul 21, 2019

casainho said:
I clear remember some users saying that they use the Startup Boost feature, but maybe they are now riding instead of being here following this thread and giving feedback.

I'm one user who said I liked boost, but only because I thought it made the system seem more responsive. My preference would be to have dev continue and be fairly ruthless and opinionated with features. Users don't have to upgrade. But I may be underestimating why and how much others appreciate boost. I certainly salute your concern for users needs.

Also, while I'm expressing personal preference, for displays, I'm interested in small and subtle like that little Bluetooth one, presumably with fancy diagnostics deferred to a phone app in future.

casainho · Jul 21, 2019

jimmyfergus said:
Also, while I'm expressing personal preference, for displays, I'm interested in small and subtle like that little Bluetooth one, presumably with fancy diagnostics deferred to a phone app in future.

We have the big 850C and the tiny SW102 with Bluetooth.

I am working on 850C and there is already a release for it.

SW102 has already most of the difficult work done but now is waiting for a developer to implement the main screen and configuration screen, where most of the code can be copied from the 850C code.

Both of this LCDs have way more memory than the LCD3 which is very important. 850C for instance, has now half of the memory available and most of the features are already implemented.

dameri · Jul 21, 2019

i used the start up boost in winter when the roads were rough and lots of snow. It was very useful. In the spring when the snow melted I had not used it and I didn't feel I needed it. Now pedolepers has made program much more better. If the program boosts the motor already when start pedalling then you may not need a start up boost.

thineight · Jul 22, 2019

jimmyfergus said:
I'm one user who said I liked boost, but only because I thought it made the system seem more responsive. My preference would be to have dev continue and be fairly ruthless and opinionated with features. Users don't have to upgrade. But I may be underestimating why and how much others appreciate boost. I certainly salute your concern for users needs.

Yes, that's what I meant, the feeling was that the boost was used mainly as "patch" to improve the responsiveness of the motor startup, which is now improved with v.20.
We know that sooner or later a new display will replace by default the LCD3, but I think up to now the latter is still the master choice because it is, in my opinion, a reasonable compromise between size and functionality, and moreover wide spreaded among users.

Perhaps when we have also the small sw102 display working, then the only choice will be between size (sw102) and display size (850c)..

We'll see, the project is taking giant steps ahead lately!
Thanks

AZUR · Jul 22, 2019

casainho said:
thineight said:

In case we need more space in the LCD3 (I guess it's the most used display for this firmware) have you considered to remove some functions? Hard to scrap some work done.. but perhaps beneficial.
My personal opinion for functions that can be removed, if needed:

- startup boost (as suggested by a user couple of weeks ago), with the quicker response from the system the boost function results perhaps not strictly necessary

- estimated range left: I was a promoter of this function long ago, but the way was implemented is not really useful because it does not update the range "live" as it uses the watts consumed from the startup instead of the actual consumption.

Click to expand...

I don't use anymore LCD3 so this is not about me but what I think the project should be.

I clear remember some users saying that they use the Startup Boost feature, but maybe they are now riding instead of being here following this thread and giving feedback.

I also think that users decided to use this project (like buying a product) based on the features on that time and the features should not be removed anymore.

I think that KT-LCD3 firmware + TSDZ2 motor controller firmware pair should be closed to new features and be in maintenance mode only.

The 850C LCD firmware + TSDZ2 motor controller firmware pair should be another project and with specific features if makes sense. And we need to be very careful with new adding features, maybe marking versions as experimental/testing before release as stable and decide to keep the new features or not.

Hi,

I agree with Casainho.

“I think that KT-LCD3 firmware + TSDZ2 motor controller firmware pair should be closed to new features and be in maintenance mode only.”

“The 850C LCD firmware + TSDZ2 motor controller firmware pair should be another project and with specific features if makes sense. And we need to be very careful with new adding features, maybe marking versions as experimental/testing before release as stable and decide to keep the new features or not.”

If we don´t go in this direction it will be difficult for all the users to understand our “Flexible Opensource Software fo TSDZ2”

Thanks to all. Casainho, Buba and the others.

Best Regards

andrea_104kg · Jul 22, 2019

I would first like to say that mine is a personal opinion. This is so that no one is offended, my opinion counts very little.
I like riding bikes more than setting engines and it doesn't matter if the display isn't colored.
I also have a turbo levo and I can make direct comparisons. With tsdz2 I can do more or less the same things and this in itself is exceptional. I don't care how easy it is to set up because I make the adjustment and then I don't change it anymore for months. For me, therefore, switching to the 850c display is not essential, unless there are really substantial advantages that go beyond aesthetics. I repeat it is a personal opinion.

casainho · Jul 22, 2019

andrea_104kg said:
I would first like to say that mine is a personal opinion. This is so that no one is offended, my opinion counts very little.
I like riding bikes more than setting engines and it doesn't matter if the display isn't colored.
I also have a turbo levo and I can make direct comparisons. With tsdz2 I can do more or less the same things and this in itself is exceptional. I don't care how easy it is to set up because I make the adjustment and then I don't change it anymore for months. For me, therefore, switching to the 850c display is not essential, unless there are really substantial advantages that go beyond aesthetics. I repeat it is a personal opinion.

Advantages of 850C LCD:
- has a lot of memory and so we are not limited as on KT-LCD3
- the big display let us show big numbers for the ones that have difficult to see tiny
- 4 numeric fields and 1 graph
- easy to understand configuration menu
- time!!
- USB charger

The SW102:
- tiny for the ones that prefer a small LCD
- more memory than LCD3 and way less than 850C
- tiny numbers, hard to see
- can't show much information on LCD because it is tiny
- Bluetooth
- no time but maybe we will be able to implement something more or less reliable
- no USB charger

I think both of this are way better than LCD3.

andrea_104kg · Jul 22, 2019

the turbo levo 2016/17/18 has no display, no usb port, no time, and it works

(in truth it is really too limited, to see the battery charge you have to stop and count the LEDs placed on the sx side : - ( )
The things I consider essential are for me the wattmeter, the battery voltage and the percentage of charge. Things that work very well on LCD03. This is because on an electric bike I think it is essential not to stay on a dead battery.
If I start thinking about the cadence, the power of the legs and the motor, the time, the graphic, etc. I don't enjoy myself anymore. I repeat only a personal opinion.

casainho · Jul 22, 2019

andrea_104kg said:
the turbo levo 2016/17/18 has no display, no usb port, no time, and it works (in truth it is really too limited, to see the battery charge you have to stop and count the LEDs placed on the sx side : - ( )
The things I consider essential are for me the wattmeter, the battery voltage and the percentage of charge. Things that work very well on LCD03. This is because on an electric bike I think it is essential not to stay on a dead battery.
If I start thinking about the cadence, the power of the legs and the motor, the time, the graphic, etc. I don't enjoy myself anymore. I repeat only a personal opinion.

LCD3 has relatively big numbers. If tiny numbers isn't an issue for you and if you prefer a small display, then I think SW102 will be your preference as it will show the data you are asking for:

Or you can just keep using the LCD3, if you prefer it over SW102.

bart594 · Jul 22, 2019

casainho said:
SW102 has already most of the difficult work done but now is waiting for a developer to implement the main screen and configuration screen, where most of the code can be copied from the 850C code.

Hi casainho,

i think developing configuration screen for this lcd is waste of time and resources. We have now like 80 menu items for different settings and this number getting bigger and bigger. On the big screen like 850c it takes lot of time to go through all the menus. SW102 with tiny screen is for showing infos like speed, battery level, assistance levels, trip distance, time and maybe cadence and human power All the settings should be done in android app. In the future maybe some kind of dashboard too in this app with all the extra informations, graphs etc. So yes we need some tsdz2 owner with android/java skills

Cool feature would be some kind of navigation too. You have connected smartphone in your backpack and on the SW102 screen you are getting displayed commands like turn left in 300m or turn right now and so on.

And thanks for hard work on 850c!

casainho · Jul 22, 2019

bart594 said:
i think developing configuration screen for this lcd is waste of time and resources. We have now like 80 menu items for different settings and this number getting bigger and bigger. On the big screen like 850c it takes lot of time to go through all the menus. SW102 with tiny screen is for showing infos like speed, battery level, assistance levels, trip distance, time and maybe cadence and human power All the settings should be done in android app.

I understand what you mean but I have different perspective: we can be on a long trip on mountains and some sensor can fail like magnet of the brake sensor, magnet of wheel speed sensor, torque sensor fail, etc, and then we need to survive and be able to disable that sensors on the configuration menu. We should not depend on the mobile phone because again it can fail, like being without battery or simple a lost phone.
I am not talking about something that is hard to happen, this things did happen to me or to members of my family.

Yes, configuration is big but I plan to implement a way to compress/expand the sections so it get short.

And I think mobile app can do also the configuration menu and that other features no possible to do with the LCD like the navigation.

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

1 kW

10 kW

10 GW

10 kW

10 W

10 GW

10 kW

10 kW

10 kW

10 GW

10 kW

100 W

10 kW

10 GW

100 mW

10 GW

100 W

100 W

100 W

1 kW

10 GW

1 kW

10 GW

1 mW

10 GW

Similar threads