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

[buba]

With the new mode Bosch e-mtb instead the logic of operation is very different. In a simple stretch, when the cyclist pushes little, his power is multiplied to 120%. When it is pushing to the maximum, its power is multiplied to 300%. With all the gradations between one extreme and the other. It's like being able to automatically switch from the Tour level to the Turbo level, gradually. Bosch does not provide precise details on the operating algorithms, but in summary this is how it works."

Potentially they are measuring torque and using that to scale the assist multiplier ... if you equate pushing to pushing the pedal harder

They prob have more CPU cycles too

Like to hear that! Seems that we are slowly getting there. And with the torque sensor calibration together with all the other improvements we will maybe exceed Bosch in some ways!

 

[casainho]

1. "In the classic system, each level of assistance provides a certain power calculated as a percentage of the power delivered by the cyclist.
For example, the Tour level provides 120%; this means that if the cyclist pushes to 100W, the engine delivers another 120; if the cyclist pushes 200W, the engine delivers 240.
Or: the Turbo level supplies 300%; so if the rider pushes to 100W, the engine delivers 300W; if the cyclist pushes to 200W, the engine delivers 600W (even 250W engines can reach these powers for a short time).

2. With the new mode Bosch e-mtb instead the logic of operation is very different. In a simple stretch, when the cyclist pushes little, his power is multiplied to 120%. When it is pushing to the maximum, its power is multiplied to 300%. With all the gradations between one extreme and the other. It's like being able to automatically switch from the Tour level to the Turbo level, gradually. Bosch does not provide precise details on the operating algorithms, but in summary this is how it works."

1. So the classic system is just like our actual pedal human power * assist level factor. Where the pedal human power = pedal torque sensor * pedal cadence.

2. emtb mode is using a curve. I think we can apply that curve just like I did for the torque sensor full calibration:

See this comparison, the torque sensor signal output is a curve as seen on bellow image and we apply an algorithm so the final output is a straight line / linear, so for instance if we increase the force on pedals by x2 (maintaining the same pedal cadence), the human power will increase x2 and so the motor assistance will follow that increase of x2. If on top of this we apply another curve (to transform the pedal human power straight line to a curve one) we will get the emtb!! It is like the emtb is the mirror operation of the full torque sensor calibration... and if we implement like this, we will let user tweak the emtb curve by changing the 8 points values on the display.

 

[buba]

For me Buba the greatest thing you have achieved with version 20 is to make it possible to go back to the blue gear again. The power is still there but is now delivered in a controlled manner. A couple of hundred miles of testing has given me the confidence to take the metal gear out and put the plastic gear back in and the silence is golden.

The gear train is the Achilles heel of the TSDZ2 and in the absence of a tougher plastic gear you have achieved a real breakthrough with version 20.

Thank you for sharing that so other users get excited to try out the 0.20.0! It has been a process of many improvements in parallel and they all came together in Alpha 1. I have destroyed a couple of blue gears just so that we know where the limits are. Actually was able to deform the metal gear as well with long term high power testing. I am very glad that you mentioned this and that you are satisfied!

I personally prefer the blue gear as well but always thought the firmware needs to be clever enough to limit the power so as not to exceed the shear strength of the plastic teeth. In the future we could have a stress value configurable in percentage units. Where 100 % is at the absolute limits but gives insane power very quickly. 40 % would make the blue gear last a life time. But for now, I think everything is tuned to be very safe and controlled as is, in all riding modes, all the time.

 

[buba]

First try installing the Alpha 7 from my Google Drive:

https://drive.google.com/open?id=1CPGT-V1ZX7FCzfhgbrPMYfbYtY4_JH2R

Press the POWER button a little longer on the display when you want to start it up.

When you have verified that everything works then you can try to build the .ihx from my branch. Start by checking the SDCC version you have installed: sdcc -v

Install the 3.9.0 if you have an earlier version.

Let me know how it goes and if I can help in any way!

So now in order to start I need a long press power button similar for off? For 0.18.2 short press was enough.

No, just slightly longer the first time. Not even noticeable but am trying to cover all bases.

For the code I used this configuration since the beginning and worked fine for 0.18.2 included. Did you changed the compiler version since 0.19+? I am getting warns that there is unreachable code for both motor and lcd.

Thanks,
Max.

I have updated because I have validated that it works fine and will not cause any problems. The new version is more efficient and solves a couple of bugs. It is also better at space optimization.

That one and only warning has always been there in all firmware versions... Am now considering to remove the unreachable line but who knows, maybe it will come in handy in the future when there are a lot of changes being made and we really need to stop the micro-controller in a defined and controlled manner.

Just let me know if you have more questions!

 

[buba]

1. "In the classic system, each level of assistance provides a certain power calculated as a percentage of the power delivered by the cyclist.
For example, the Tour level provides 120%; this means that if the cyclist pushes to 100W, the engine delivers another 120; if the cyclist pushes 200W, the engine delivers 240.
Or: the Turbo level supplies 300%; so if the rider pushes to 100W, the engine delivers 300W; if the cyclist pushes to 200W, the engine delivers 600W (even 250W engines can reach these powers for a short time).

2. With the new mode Bosch e-mtb instead the logic of operation is very different. In a simple stretch, when the cyclist pushes little, his power is multiplied to 120%. When it is pushing to the maximum, its power is multiplied to 300%. With all the gradations between one extreme and the other. It's like being able to automatically switch from the Tour level to the Turbo level, gradually. Bosch does not provide precise details on the operating algorithms, but in summary this is how it works."

1. So the classic system is just like our actual pedal human power * assist level factor. Where the pedal human power = pedal torque sensor * pedal cadence.

2. emtb mode is using a curve. I think we can apply that curve just like I did for the torque sensor full calibration:

See this comparison, the torque sensor signal output is a curve as seen on bellow image and we apply an algorithm so the final output is a straight line / linear, so for instance if we increase the force on pedals by x2 (maintaining the same pedal cadence), the human power will increase x2 and so the motor assistance will follow that increase of x2. If on top of this we apply another curve (to transform the pedal human power straight line to a curve one) we will get the emtb!! It is like the emtb is the mirror operation of the full torque sensor calibration... and if we implement like this, we will let user tweak the emtb curve by changing the 8 points values on the display.

Speaking of the torque calibration, is it correct for me to look at this branch to get the latest code? This is so I am looking at the latest changes and the finished implementation.

Motor controller:
https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/tree/torque_sensor_calibration

Display:
Has no calibration function yet, instead the values are hard coded in the motor controller.

 

[casainho]

Speaking of the torque calibration, is it correct for me to look at this branch to get the latest code? This is so I am looking at the latest changes and the finished implementation.

Motor controller:
https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/tree/torque_sensor_calibration

Display:
Has no calibration function yet, instead the values are hard coded in the motor controller.

Yes, that branch.

On 850C/SW102 we can quickly add the calibration points. Is up to you to see if it should be done for KT-LCD3. I think we will need to add 8 x 2 x 16 bits and probably implement a specific configurations package on communications since it will grow a lot. And this package could be a structure, would avoid every bitshift operations we currently do for every variable that is not 8 bits.

 

[buba]

Speaking of the torque calibration, is it correct for me to look at this branch to get the latest code? This is so I am looking at the latest changes and the finished implementation.

Motor controller:
https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/tree/torque_sensor_calibration

Display:
Has no calibration function yet, instead the values are hard coded in the motor controller.

Yes, that branch.

On 850C/SW102 we can quickly add the calibration points. Is up to you to see if it should be done for KT-LCD3. I think we will need to add 8 x 2 x 16 bits and probably implement a specific configurations package on communications since it will grow a lot. And this package could be a structure, would avoid every bitshift operations we currently do for every variable that is not 8 bits.

Thanks!

And may I ask how large the average difference is between the right and left pedals when comparing on several bikes? Is there an absolute need to calibrate both sides and have the user always start with the pedals in a certain position? I am thinking that maybe the majority has "good enough" values between the both sides so we can average the value. This would make the calibration and use of the system much easier. But I am just asking.

You have already potentially increased the range up to four times just by calibrating the torque sensor. So maybe a "double" calibration on both sides is not necessary and would have diminishing return for most users?

 

[emyr666]

Is there easy access to any spare I/O pins on the controller board ?

I was wondering if it would be feasible to use a digital temperature sensor such as this one : https://datasheets.maximintegrated.com/en/ds/DS18B20-PAR.pdf

That would mean we could still use a throttle. It would be a matter of figuring out the best way to solder in the connections and then writing the bit banging code to read the sensor data periodically.

 

[emyr666]

Is there easy access to any spare I/O pins on the controller board ?

I was wondering if it would be feasible to use a digital temperature sensor such as this one : https://datasheets.maximintegrated.com/en/ds/DS18B20-PAR.pdf

That would mean we could still use a throttle. It would be a matter of figuring out the best way to solder in the connections and then writing the bit banging code to read the sensor data periodically.

Just found this which has code for this sensor for an stm8 mcpu : http://embedded-lab.com/blog/stm8-microcontrollers-final-chapters/5/

 

[e3s]

I posted how to remove the board without damaging it. So you can make as you want. For soldering I suggest to use a thin silicone wire.

 

[emyr666]

Is there easy access to any spare I/O pins on the controller board ?

I was wondering if it would be feasible to use a digital temperature sensor such as this one : https://datasheets.maximintegrated.com/en/ds/DS18B20-PAR.pdf

That would mean we could still use a throttle. It would be a matter of figuring out the best way to solder in the connections and then writing the bit banging code to read the sensor data periodically.

Just found this which has code for this sensor for an stm8 mcpu : http://embedded-lab.com/blog/stm8-microcontrollers-final-chapters/5/

Hmmm...this was mentioned on Oct 15 2018. Is it definitely not possible to use this sensor ? Even with the code posted above?

 

[casainho]

Is there easy access to any spare I/O pins on the controller board ?

I was wondering if it would be feasible to use a digital temperature sensor such as this one : https://datasheets.maximintegrated.com/en/ds/DS18B20-PAR.pdf

That would mean we could still use a throttle. It would be a matter of figuring out the best way to solder in the connections and then writing the bit banging code to read the sensor data periodically.

Us there are free digital pins kind of easy to access.

I evaluated that sensor before decided to go with current one. The issue with that sensor is that the communications are very hard to do and probably would be impossible to implement because would not let the motor controller code working as it need to work -- lack of processing speed of the STM8 for do motor controller and that communications for DS18.

 

[thineight]

Will take a look and come up with something!

+1 :thumb: I think this would be useful as well as its easy to have your fingers bounced of the button for a short time and loose all walk assist when you are needing it most.

Just a couple of suggestions for the walk assist, buba please evaluate if this is applicable:

- once activated, the w.a. should stop 1 (or 2) seconds after you release the DOWN button, so you are allowed to repress it if the finger slips off
- if the finger slips off, within the allowed time (1 or 2 seconds) you need just a simple press to keep the w.a. working, not a long one as when you want to activate it
- during the w.a. the DOWN button should not change the current assistance level
- of course the brake sensors shall reset everything, if activated

Hope this may work :wink:
Cheers

 

[e3s]

Casainho when you reached 63v in the controller to test the motor have you seen some anomalies in the controller? I'm looking for change the capacitors to overvoltage the controller

 

[casainho]

And may I ask how large the average difference is between the right and left pedals when comparing on several bikes? Is there an absolute need to calibrate both sides and have the user always start with the pedals in a certain position? I am thinking that maybe the majority has "good enough" values between the both sides so we can average the value. This would make the calibration and use of the system much easier. But I am just asking.

You have already potentially increased the range up to four times just by calibrating the torque sensor. So maybe a "double" calibration on both sides is not necessary and would have diminishing return for most users?

If I use the same values, here an example when I put my self on the right or left pedal:
- right pedal measures correctly: 105 kgs
- left pedal measures incorrectly: 65 kgs

That is an error of 40 kgs / 38%, that is to much.

So yes, there is need for calibration of left and right pedals, as also user need to power up the motor with one of the pedals positioned in direction to ground. On SW102/850C we can display a quick message at power up saying for user removed the feet from the pedal and keep one in direction to the ground because is it needed for automatic torque sensor calibration.

I don't have a better idea but here we are clearly adding very advanced features to this motor, fine calibration of the torque sensor as also "calibration" of the emtb curve.

Maybe we could keep this features disabled as default and keep the firmware running as it is on v0.19.0 on this case. When enabling this features, user would need to validate and possible do own calibration.

I think the users with SW102 and Strava integration will want the torque sensor well calibrated since the pedal human power will be sent to Strava.

Also I hope it will be easy to manage the configurations on a mobile app when using the SW102. At least I hope user will be able to save them as a backup and apply them to other TSDZ2 ebikes.

 

[casainho]

Casainho when you reached 63v in the controller to test the motor have you seen some anomalies in the controller? I'm looking for change the capacitors to overvoltage the controller

Since I remember, I could only reach 62V on my lab power supply and the controller worked well.

 

[e3s]

Thanks a lot

 

[buba]

And may I ask how large the average difference is between the right and left pedals when comparing on several bikes? Is there an absolute need to calibrate both sides and have the user always start with the pedals in a certain position? I am thinking that maybe the majority has "good enough" values between the both sides so we can average the value. This would make the calibration and use of the system much easier. But I am just asking.

You have already potentially increased the range up to four times just by calibrating the torque sensor. So maybe a "double" calibration on both sides is not necessary and would have diminishing return for most users?

If I use the same values, here an example when I put my self on the right or left pedal:
- right pedal measures correctly: 105 kgs
- left pedal measures incorrectly: 65 kgs

That is an error of 40 kgs / 38%, that is to much.

So yes, there is need for calibration of left and right pedals, as also user need to power up the motor with one of the pedals positioned in direction to ground. On SW102/850C we can display a quick message at power up saying for user removed the feet from the pedal and keep one in direction to the ground because is it needed for automatic torque sensor calibration.

I don't have a better idea but here we are clearly adding very advanced features to this motor, fine calibration of the torque sensor as also "calibration" of the emtb curve.

Maybe we could keep this features disabled as default and keep the firmware running as it is on v0.19.0 on this case. When enabling this features, user would need to validate and possible do own calibration.

I think the users with SW102 and Strava integration will want the torque sensor well calibrated since the pedal human power will be sent to Strava.

Also I hope it will be easy to manage the configurations on a mobile app when using the SW102. At least I hope user will be able to save them as a backup and apply them to other TSDZ2 ebikes.

Okay, good to know that! Thanks!

 

[buba]

Will take a look and come up with something!

+1 :thumb: I think this would be useful as well as its easy to have your fingers bounced of the button for a short time and loose all walk assist when you are needing it most.

Just a couple of suggestions for the walk assist, buba please evaluate if this is applicable:

- once activated, the w.a. should stop 1 (or 2) seconds after you release the DOWN button, so you are allowed to repress it if the finger slips off
- if the finger slips off, within the allowed time (1 or 2 seconds) you need just a simple press to keep the w.a. working, not a long one as when you want to activate it
- during the w.a. the DOWN button should not change the current assistance level
- of course the brake sensors shall reset everything, if activated

Hope this may work :wink:
Cheers

I have something in mind that is very safe and still has a very nice button debounce

 

[Peetsyo]

If the motor overheats , does it switch off as if switched off from button (display goes off) or motor just becomes unresponsive and display stays on ?
Can you switch on immediately after that and ride on ?

I am not sure if i have problem with battery connection or the motor actually overheats.

 

[maximusdm]

Press the POWER button a little longer on the display when you want to start it up.

When you have verified that everything works then you can try to build the .ihx from my branch. Start by checking the SDCC version you have installed: sdcc -v
Install the 3.9.0 if you have an earlier version.

Let me know how it goes and if I can help in any way!

I had SDCC 3.8 which was previously recomanded. Indeed the current LCD soft exeeds the current memory if compiled with 3.8 or lower. Very good idea to use 3.9 to save memory.
I installed 3.9 stable and all works like a charm . Indeed the power requires a long press to start. Sry I did not know that was changed.

I only managed to test 3km with simple power mode with calibration done and defaults. One of the best releases ever!
Good power delivery and the motor responds better to your actions.
I also had the nice surprise of the new menus. Very intuitive and easy to use. I almost do not need a map .
I will come back with additional feedback.

Thank you for the passion invested in this release!

 

[casainho]

If the motor overheats , does it switch off as if switched off from button (display goes off) or motor just becomes unresponsive and display stays on ?
Can you switch on immediately after that and ride on ?

I am not sure if i have problem with battery connection or the motor actually overheats.

Which version of our OpenSource firmware are you using?

 

[buba]

Press the POWER button a little longer on the display when you want to start it up.

When you have verified that everything works then you can try to build the .ihx from my branch. Start by checking the SDCC version you have installed: sdcc -v
Install the 3.9.0 if you have an earlier version.

Let me know how it goes and if I can help in any way!

I had SDCC 3.8 which was previously recomanded. Indeed the current LCD soft exeeds the current memory if compiled with 3.8 or lower. Very good idea to use 3.9 to save memory.
I installed 3.9 stable and all works like a charm . Indeed the power requires a long press to start. Sry I did not know that was changed.

I only managed to test 3km with simple power mode with calibration done and defaults. One of the best releases ever!
Good power delivery and the motor responds better to your actions.
I also had the nice surprise of the new menus. Very intuitive and easy to use. I almost do not need a map .
I will come back with additional feedback.

Thank you for the passion invested in this release!

That is wonderful to read!

Thank you for the kind feedback and your appreciation for the 0.20.0! It means a lot!

 

[buba]

Alpha 8 is soon here!

Alpha 8 will introduce a better eMTB with more options for sensitivity. At the same time it will be drastically space and speed optimized. That means it takes up less program space and executes faster. So the result is that we will have much more available space in the motor controller and not compromise on functionality.

The Walk Assist and Cruise will have a really clever button debounce feature that can differentiate accidental activation from real activation. If you accidentally and quickly press the DOWN button it will immediately deactivate Walk Assist or Cruise as soon as you let go. But if you are holding the DOWN button for a longer time the system will understand and allow for some button debouncing. Cruise has a lower debounce time than Walk Assist but that is by design. This is actually a really safe implementation and I hope it will be approved by the community. It is also dynamic so it adjusts for the time the user holds down the button and so on. Needs to be tested and I look forward to feedback.

There will also be some other small changes and improvements in the Alpha 8.

Expect Alpha 8 tomorrow, within 24 hours!

 

[andrea_104kg]

what's the logic of new emtb?
Thank's for your hard work!
Thank's for your hard work!
Thank's for your hard work!
Thank's for your hard work!
Thank's for your hard work!
Thank's for your hard work!
Thank's for your hard work!