TSDZ2 OSF for all displays, VLCD5-VLCD6-XH18, LCD3, 860C-850C-SW102.

[plpetrov]

Hello, I am sorry for the thread cross-referencing but it seems that there is a common issue for all forks of the firmware. See the post below:

I had forgotten that there was still the annoying problem of the power delay on restarts.
Here then a new version that solves, or at least significantly improves, the situation.

New v12 version of the controller firmware (only controller fw need to be updated):
https://github.com/TSDZ2-ESP32/TSDZ2-ESP32-Wiki/blob/master/bin/STM8/TSDZ2-v12.zip

For those interested in the changes made, just see the changes made with the last commit on github.

The good news is that there is progress and willingness to resolve the issue. I hope soon or later a solution will be found and implemented in all forks ... At least to the ones being developed and supported ....

 

[michih.]

As far as I can imagine, the ADC values ​​of the torque sensor are converted to variable values ​​with a different range of numbers. The conversion factor is most likely given by the calibration and offset values ​​of the torque sensor. Further, these values ​​are processed and summed up with other variables and only after that they are converted into a PWM signal for the motor. Thus, the reduced numeric range of the ADC of torque sensor can't create any feedback delays. Did you write the code for the latest firmware yourself? Could you just show me the places in the code where the described delay can occur? Then I myself will conduct all the tests and report the results.

There is a delay caused by the software but it does not create problems, indeed it is necessary, a too abrupt stop is not good.
Look for threads related to overrun.
There are 3 reasons for the software delay:
1 - deceleration ramp, step from 0.5 ms up to 2.5 ms at maximum speed.
2 - cadence sensor control time for stationary pedals, max 210 ms, this delay decreases as cadence increases.
3 - ebike_app.c recall time every 25 ms.
These are functional times cannot be changed.

Regarding the torque sensor, it is true that with a limited range it is remapped, bringing it to optimal values ​​(calibration is for this), but the resolution is not the same. With intermediate values ​​it is not important, but at the beginning and at the end of the pedal stroke it is.
Then there is another aspect, a sensor with limited range is also "hard" as sensitivity at the start of pedaling and it is "slow" to return to zero when you stop pedaling.
I have an motor with a range of 160 and an 80, the difference is evident.
Consider a mechanical calibration, in your case I think it is the solution.

would be really nice if you could turn off these deliberate delays for the MTB faction.

MFG Michael

 

[HughF]

As far as I can imagine, the ADC values ​​of the torque sensor are converted to variable values ​​with a different range of numbers. The conversion factor is most likely given by the calibration and offset values ​​of the torque sensor. Further, these values ​​are processed and summed up with other variables and only after that they are converted into a PWM signal for the motor. Thus, the reduced numeric range of the ADC of torque sensor can't create any feedback delays. Did you write the code for the latest firmware yourself? Could you just show me the places in the code where the described delay can occur? Then I myself will conduct all the tests and report the results.

There is a delay caused by the software but it does not create problems, indeed it is necessary, a too abrupt stop is not good.
Look for threads related to overrun.
There are 3 reasons for the software delay:
1 - deceleration ramp, step from 0.5 ms up to 2.5 ms at maximum speed.
2 - cadence sensor control time for stationary pedals, max 210 ms, this delay decreases as cadence increases.
3 - ebike_app.c recall time every 25 ms.
These are functional times cannot be changed.

Regarding the torque sensor, it is true that with a limited range it is remapped, bringing it to optimal values ​​(calibration is for this), but the resolution is not the same. With intermediate values ​​it is not important, but at the beginning and at the end of the pedal stroke it is.
Then there is another aspect, a sensor with limited range is also "hard" as sensitivity at the start of pedaling and it is "slow" to return to zero when you stop pedaling.
I have an motor with a range of 160 and an 80, the difference is evident.
Consider a mechanical calibration, in your case I think it is the solution.

would be really nice if you could turn off these deliberate delays for the MTB faction.

MFG Michael

Reason 2 doesn't apply to the eMTB/Torque mode as neither of these modes use the cadence sensor as part of the current calculation.

 

[Waynemarlow]

Guys, any chance we can let MBrusa and the other developers have a bit of space and time on this, these guys are doing it voluntarily and to make the demands some of you are making, is taking the whole project into the realms that you have paid top dollar for what is a free upgrade you yourselves have voluntarily downloaded.

If you don’t like the free firmware as it is, then you have two choices. You can revert back to the original factory firmware or you can actually get coding and create a fork that the motor responds in the manner you desire.

If the coders right now opted out and went and enjoyed the fruits of their free time this last winter, over the summer, then I would personally thank them for getting the project as far as it has developed and I to will enjoy their work over the summer, as the present version is very good in comparison to the factory firmware.

For those of you who are still unhappy that the firmware is not to their personal satisfaction then I can only say, create your own thread here on ES, get coding and let’s see what you can create.

 

[mbrusa]

would be really nice if you could turn off these deliberate delays for the MTB faction.
MFG Michael

The step of the deceleration ramp could be adjustable as is the acceleration one.
The minimum and maximum limits must be well established. It can be done.

Reason 2 doesn't apply to the eMTB/Torque mode as neither of these modes use the cadence sensor as part of the current calculation.

Exact.

 

[mbrusa]

Hello, I am sorry for the thread cross-referencing but it seems that there is a common issue for all forks of the firmware. See the post below:

I had forgotten that there was still the annoying problem of the power delay on restarts.
Here then a new version that solves, or at least significantly improves, the situation.

New v12 version of the controller firmware (only controller fw need to be updated):
https://github.com/TSDZ2-ESP32/TSDZ2-ESP32-Wiki/blob/master/bin/STM8/TSDZ2-v12.zip

For those interested in the changes made, just see the changes made with the last commit on github.

The good news is that there is progress and willingness to resolve the issue. I hope soon or later a solution will be found and implemented in all forks ... At least to the ones being developed and supported ....

I saw the new version of mspider65, I will try it.
However, taking all the changes from v7 to v12 and trying them out takes a long time.
With the warm season the time to devote to programming will be less and less!

 

[AZUR]

To everyone complaining about the startup/restart delay, this is my experience with 1 year of tinkering and using various firmware versions:

1. You will always experience a small startup/restart delay when motor current is calculated in 'power' mode - the solution to this is to never use power mode

2. Casainho's 1.0.0-1.1.1 are the worst performers for startup/restart delay even when the motor current calculation is set to 'torque mode' - I don't know why it is the worst, but it is. I have posted settings many times in the other thread, these settings will help to get the best off the line performance.

3. r0mko's 'torque mode only' fork of version 0.80 works very well, but this is probably because of the 3x hard coded startup current ramp. I don't see a need to use this fork anymore now that we have v0.20C.

4. mbrusa's v0.20C has the best performance for me, but only when used in 'hybrid mode' - you always want to use torque mode when starting out because the tsdz2 cadence sensor has such poor low-cadence resolution. If you use it in 'power mode' you will still have poor starts unless you use startup boost.

5. AWOP (assistance without pedal rotation) I always recommend people use this, brake sensors or not - it gives assistance whenever there is pressure on the pedals, which is something that I figure everyone is expecting from and eBike.

6. eMTB mode can be considered a button-less torque mode - the assistance is torque calculated, with the assistance multiplier automatically increasing with pedal pressure - it is excellent offroad.

To summarise - I ride in eMTB when in technical offroad sections and in hybrid mode when commuting/travelling along hard pack offroad trails. I don't see why anyone would need to use anything else. Power mode on it's own is junk, torque mode is jerky at high cadence - they must be combined and I am very glad that they now are.

.

Thank you HughF for your contribution.

What I would like to know is if you feel the "power Delay Issue", as I have measured and described it in the videos I made?

Do you feel the delay, as I described it in the videos, in eMTB mode and Hybrid mode?

Do you feel a delay of 400ms, 700ms, 1000 ms, or whatever?

Or, on the other hand, you feel the delay, but is it not important to you?

I am not complaining. I am working and spending a lot of my time to improve the firmware. I think that is the goal of everyone in this forum.


I discovered the problem in September 2020 and have been silent until now, waiting for someone to be interested and able to solve the problem.


The firmware is free, and I didn't pay anything for the firmware. So I can't complain.


I mentioned the power mode, because it was in this mode that I made the videos.

But I also tested Torque mode, and I also felt the delay.

I spent 4 months (June to September 2020) until I was able to understand the problem and to be able to measure it.

I tested every possible hypothesis.

I tested the variables:
Current Ramp
min current ADC step
with and without the field weakening
Torque and power mode
I calibrated the torque sensor
startup boost
Assist w / o Rotation pedal
etc

Other users have already stated that the delay exists. They have also stated that the problem is more "visible" in power mode.

Even Mbrusa, he already admitted that he knows the problem. And that will try to solve it.

And I will help mbrusa, if I can and know.

If the problem is solved in torque mode, hybrid mode or eMTB mode, fantastic, great. I am very satisfied.

I repeat:

What I would like to know is if you feel the "Power Delay Issue" as I measured it and describe it in the videos I made?
Do you feel the delay as I described it in the videos in eMTB mode and Hybrid mode?
Or, on the other hand, you feel the delay, but is it not important to you?


Thanks,

Azur

 

[AZUR]

Guys, any chance we can let MBrusa and the other developers have a bit of space and time on this, these guys are doing it voluntarily and to make the demands some of you are making, is taking the whole project into the realms that you have paid top dollar for what is a free upgrade you yourselves have voluntarily downloaded.

If you don’t like the free firmware as it is, then you have two choices. You can revert back to the original factory firmware or you can actually get coding and create a fork that the motor responds in the manner you desire.

If the coders right now opted out and went and enjoyed the fruits of their free time this last winter, over the summer, then I would personally thank them for getting the project as far as it has developed and I to will enjoy their work over the summer, as the present version is very good in comparison to the factory firmware.

For those of you who are still unhappy that the firmware is not to their personal satisfaction then I can only say, create your own thread here on ES, get coding and let’s see what you can create.

.

Hi Waynemarlow,

I think you are misunderstanding what is being talked about in this forum, lately.

We are all in good faith, and trying to help.

This forum is not a "fight" between football fans.

What should motivate participants is to contribute to improving the firmware.

Each one contributed with their work and their experience.

As I said in the previous post, the firmware is free, and I didn't pay anything for the firmware. So I can't complain.

Each of us is giving information to mbrusa, and the others, to improve the software.

If you don't understand this, the problem is with you, not with the other members of the forum.

Even Mbrusa has already realized that we are helping.

But you still don't understand.

You're just introducing noise.

But I personally believe that you must have misunderstood what motivates the other participants. And so I don't blame you for your post.

Be happy.

Azur

 

[HughF]

What I would like to know is if you feel the "Power Delay Issue" as I measured it and describe it in the videos I made?
Do you feel the delay as I described it in the videos in eMTB mode and Hybrid mode?
Or, on the other hand, you feel the delay, but is it not important to you?

That is a hard one for me to clarify - I don't think I feel a delay, and any delay I do feel, perhaps that is my sprag bearing, perhaps it is the internals of my Alfine gearhub? I don't know...

I suppose I don't pay any attention to it. I will try and pay more attention when I ride this firmware again. I have a road bike that has normal gears and a nearly new TSDZ2, I will try and ride this next to see if the gearing and the sprag bearing are tighter.

If there is a delay there, it is 1/5th as bad as the 1.1.1 firmware.

 

[plpetrov]

Hello, I am sorry for the thread cross-referencing but it seems that there is a common issue for all forks of the firmware. See the post below:

I had forgotten that there was still the annoying problem of the power delay on restarts.
Here then a new version that solves, or at least significantly improves, the situation.

New v12 version of the controller firmware (only controller fw need to be updated):
https://github.com/TSDZ2-ESP32/TSDZ2-ESP32-Wiki/blob/master/bin/STM8/TSDZ2-v12.zip

For those interested in the changes made, just see the changes made with the last commit on github.

The good news is that there is progress and willingness to resolve the issue. I hope soon or later a solution will be found and implemented in all forks ... At least to the ones being developed and supported ....

I saw the new version of mspider65, I will try it.
However, taking all the changes from v7 to v12 and trying them out takes a long time.
With the warm season the time to devote to programming will be less and less!

It's not about taking all the changes up to version 12. It is only about the changes between 11 and 12, that mspider65 mentions and that deal with the specific delay issue. May be the same solution could be applied in your firmware.

I am still expecting the warm season in order to upgrade from 1.0.0 to your latest firmware.

 

[Waynemarlow]

But you still don't understand.

You're just introducing noise.

Azur

So can I ask with all your persistence in repeatedly bringing the subject up that you personally think there is a problem, how you personally are going to solve the problem ? It’s obvious that you cannot code nor fully understand the electrical problems that you perceive.

If I was in MBrusa’s situation of some random guy repeatedly complaining on a thread that I had created and a problem, if at all a problem, was something that I was probably not to concerned about as very few others are concerned by, I would probably pack my coding skills up for the summer and go and enjoy my cycling Any further coding gains I can test with others on a more quiet basis without all the hassles of maintaining a thread on ES.

 

[AZUR]

Hello, I am sorry for the thread cross-referencing but it seems that there is a common issue for all forks of the firmware. See the post below:

I had forgotten that there was still the annoying problem of the power delay on restarts.
Here then a new version that solves, or at least significantly improves, the situation.

New v12 version of the controller firmware (only controller fw need to be updated):
https://github.com/TSDZ2-ESP32/TSDZ2-ESP32-Wiki/blob/master/bin/STM8/TSDZ2-v12.zip

For those interested in the changes made, just see the changes made with the last commit on github.

The good news is that there is progress and willingness to resolve the issue. I hope soon or later a solution will be found and implemented in all forks ... At least to the ones being developed and supported ....

I saw the new version of mspider65, I will try it.
However, taking all the changes from v7 to v12 and trying them out takes a long time.
With the warm season the time to devote to programming will be less and less!

Hi Mbrusa,

I think mspider65, made version v12, on March 14th, on purpose to try to minimize the restart power delay.

Like you and him, both live in Italy, why don't you talk to mspyder65, over the phone or chat, to try to find out what he did?

So, maybe, you don't have to analyze all the modifications from V7 to V12.


And as you said, in hot weather, it is better to be cycling than to be at home developing software.

Thanks

Azur

 

[Elinx]

.....
I have change in basic settings
Motor acceleration
Wheel size
Battery settings

Assistansen settings
Nothing at first but just for an experiment i raised Assist level eMTB mode and it did got a little better.

Advanced settings
No change

I cant figure out how to calibrating the torque sensor with the VLCD 6 display.

Original FW is best compared with power mode.
eMTB is not always working as you thought, so try other modes too.
It is possible to change this on display, but need enabling "set parameters on startup", which is not the case now.

There are 3 options that influences the response of starting the motor.
1 startup without pedaling
2 startup boost
3 hybrid mode

Edit: For saving your blue gear, try these options only one at a time

Boost does only work with Power mode.
If you use hybrid, the motor start with torque mode and when your are pedaling it is power mode.

For calibration of the torque sensor "set parameters on startup" must be enabled.
After start up the display (level 1 eco), push light 6 times, when E04 flashing, push again (7e)
You see the first min. value.
Stand on the right pedal with full weight and you have the max. value.
These values give the range of your torque sensor.
If this is a bit low (under 100) with default settings the motor responsive could be low too.
With enabling advanced torque and insert calibrated values it could be improved.

 

[Waynemarlow]

It's not about taking all the changes up to version 12. It is only about the changes between 11 and 12, that mspider65 mentions and that deal with the specific delay issue. May be the same solution could be applied in your firmware

I am still expecting the warm season in order to upgrade from 1.0.0 to your latest firmware.

Umm so what you are saying for all your posts is that you have read about a perceived or actual problem on the internet and so without actually trying V20.1C you can advise a guy who has bought so much to this community, to change his whole coding from V20.1C, which will take a large number of his personal time, to a new relatively untested code just for your benefit.

Interesting concept.

 

[HughF]

It's not about taking all the changes up to version 12. It is only about the changes between 11 and 12, that mspider65 mentions and that deal with the specific delay issue. May be the same solution could be applied in your firmware

I am still expecting the warm season in order to upgrade from 1.0.0 to your latest firmware.

Umm so what you are saying for all your posts is that you have read about a perceived or actual problem on the internet and so without actually trying V20.1C you can advise a guy who has bought so much to this community, to change his whole coding from V20.1C, which will take a large number of his personal time, to a new relatively untested code just for your benefit.

Interesting concept.

Interesting indeed.... :wink: :wink:

 

[Waynemarlow]

There are 3 options that influences the response of starting the motor.
1 startup without pedaling
2 startup boost
3 hybrid mode

Guys you can play with these parameters but please respect that the faster you ramp up the power from a motor standstill, the more likely you will damage the plastic gear inside the motor.

On some testing a few months ago I had both startup without peddling and startup boost engaged and I damaged a plastic gear. It was in an extreme situation of trying to push through 700W momentarily and my bike had momentarily wedged the front wheel against a fallen log, it was rider error but never the less in higher power and a fast ramp up, you have been warned.

 

[plpetrov]

It's not about taking all the changes up to version 12. It is only about the changes between 11 and 12, that mspider65 mentions and that deal with the specific delay issue. May be the same solution could be applied in your firmware

I am still expecting the warm season in order to upgrade from 1.0.0 to your latest firmware.

Umm so what you are saying for all your posts is that you have read about a perceived or actual problem on the internet and so without actually trying V20.1C you can advise a guy who has bought so much to this community, to change his whole coding from V20.1C, which will take a large number of his personal time, to a new relatively untested code just for your benefit.

Interesting concept.

Interesting indeed.... :wink: :wink:

And what is my benefit? I do not think I have any at all in addition the time spent to read this forums. May be also the time for testing and provide feedback ...

I simply found the same or similar complains about same or similar issue in the different threads. And in the last thread there is a solution proposed. This means someone has spent time and effort to analyse, implement and test a potential solution.

In my opinion it is more meaningful and time saving to use the shared experience and knowledge. That is the base of the open source software.

I personally have no issues with any delays or whatsoever except the fact that my motor is not working when I switch on my headlight ...

 

[Elinx]

There are 3 options that influences the response of starting the motor.
1 startup without pedaling
2 startup boost
3 hybrid mode

Guys you can play with these parameters but please respect that the faster you ramp up the power from a motor standstill, the more likely you will damage the plastic gear inside the motor. .....

Yes, thanks for the addition , The advice is to try these options not combined, but one at a time

 

[Alfie]

Guys, any chance we can let MBrusa and the other developers have a bit of space and time on this, these guys are doing it voluntarily and to make the demands some of you are making, is taking the whole project into the realms that you have paid top dollar for what is a free upgrade you yourselves have voluntarily downloaded.

If you don’t like the free firmware as it is, then you have two choices. You can revert back to the original factory firmware or you can actually get coding and create a fork that the motor responds in the manner you desire.

If the coders right now opted out and went and enjoyed the fruits of their free time this last winter, over the summer, then I would personally thank them for getting the project as far as it has developed and I to will enjoy their work over the summer, as the present version is very good in comparison to the factory firmware.

For those of you who are still unhappy that the firmware is not to their personal satisfaction then I can only say, create your own thread here on ES, get coding and let’s see what you can create.

Waynemarlow, I couldn't agree more. I was thinking the same thing myself. This thread has been plagued by people whining. What started as a great post has been turned into pages of nonsense. Very off-putting for anyone having to read through it all.

 

[plpetrov]

It's not about taking all the changes up to version 12. It is only about the changes between 11 and 12, that mspider65 mentions and that deal with the specific delay issue. May be the same solution could be applied in your firmware

I am still expecting the warm season in order to upgrade from 1.0.0 to your latest firmware.

Umm so what you are saying for all your posts is that you have read about a perceived or actual problem on the internet and so without actually trying V20.1C you can advise a guy who has bought so much to this community, to change his whole coding from V20.1C, which will take a large number of his personal time, to a new relatively untested code just for your benefit.

Interesting concept.

Interesting indeed.... :wink: :wink:

And what is my benefit? I do not think I have any at all in addition the time spent to read this forums. May be also the time for testing and provide feedback ...

I simply found the same or similar complains about same or similar issue in the different threads. And in the last thread there is a solution proposed. This means someone has spent time and effort to analyse, implement and test a potential solution.

In my opinion it is more meaningful and time saving to use the shared experience and knowledge. That is the base of the open source software.

I personally have no issues with any delays or whatsoever except the fact that my motor is not working when I switch on my headlight ...

And the implemented changes in the code are evident and easily traceable. Same with the logic behind them. Check the link below:

https://github.com/TSDZ2-ESP32/TSDZ2-Smart-EBike/commit/320699cb9b9d5f6af7d6b944d9ba639fc279d251

And at the end of the day, this is just a suggestion for improvement. It is up to mbrusa to agree or disagree with the implementation approach ...

And last but not least, testing code is not always related to pushing the pedals or playing with configuration values ...

 

[AZUR]

What I would like to know is if you feel the "Power Delay Issue" as I measured it and describe it in the videos I made?
Do you feel the delay as I described it in the videos in eMTB mode and Hybrid mode?
Or, on the other hand, you feel the delay, but is it not important to you?

That is a hard one for me to clarify - I don't think I feel a delay, and any delay I do feel, perhaps that is my sprag bearing, perhaps it is the internals of my Alfine gearhub? I don't know...

I suppose I don't pay any attention to it. I will try and pay more attention when I ride this firmware again. I have a road bike that has normal gears and a nearly new TSDZ2, I will try and ride this next to see if the gearing and the sprag bearing are tighter.

If there is a delay there, it is 1/5th as bad as the 1.1.1 firmware.

Thanks HughF,

If you want to test, perform the test on an uphill road, with at least 8%. Repeat the test several times, on the same climb.

I managed to replicate the problem on a flat road, by chance. I only saw the problem when I saw the video. On the road, in progress, I didn't feel it. The inertia of the movement, the speed and the fact of being on a flat road hid the problem.

But on an uphill road it is easier to feel.

Thanks

Azur

 

[StormTD5]

.....
I have change in basic settings
Motor acceleration
Wheel size
Battery settings

Assistansen settings
Nothing at first but just for an experiment i raised Assist level eMTB mode and it did got a little better.

Advanced settings
No change

I cant figure out how to calibrating the torque sensor with the VLCD 6 display.

Original FW is best compared with power mode.
eMTB is not always working as you thought, so try other modes too.
It is possible to change this on display, but need enabling "set parameters on startup", which is not the case now.

There are 3 options that influences the response of starting the motor.
1 startup without pedaling
2 startup boost
3 hybrid mode

Boost does only work with Power mode.
If you use hybrid the motor start with torque and when your are pedaling it is power mode.

For calibration of the torque sensor "set parameters on startup" must be enabled.
After start up the display (level 1 eco), push light 6 times, when E04 flashing, push again (7e)
You see the first min. value.
Stand on the right pedal with full weight and you have the max. value.
These values give the range of your torque sensor.
If this is a bit low (under 100) with default settings the motor responsive could be low too.
With enabling advanced torque and insert calibrated values it could be improved.

I have tried diffrent mode on startup, weak assist on every mode...

Ok, just flash the controller again
Set parameters on startup, check!
Calibrating the torque sensor
Hope its the torque sensor that is the trouble

Thanks for the support!!

 

[Nfer]

I have tried diffrent mode on startup, weak assist on every mode...

Ok, just flash the controller again
Set parameters on startup, check!
Calibrating the torque sensor
Hope its the torque sensor that is the trouble

Thanks for the support!!

Make sure the speed sensor is correctly installed

 

[StormTD5]

I have tried diffrent mode on startup, weak assist on every mode...

Ok, just flash the controller again
Set parameters on startup, check!
Calibrating the torque sensor
Hope its the torque sensor that is the trouble

Thanks for the support!!

Make sure the speed sensor is correctly installed

I'll check that to, it did however work with the stock firmware but just in case :wink:

 

[Elinx]

I have tried diffrent mode on startup, weak assist on every mode...

.....
Calibrating the torque sensor
Hope its the torque sensor that is the trouble...

If the sensitivity of the torque sensor is low, a calibration could help a bit, but is not ideal.