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

[ezrider1199]

Just tested the updated firmware and there are still issues with throttle control. At 0 assist throttle doesnt work. At >0 assist, power delivery is erratic, it will go 15amp then lower to 0 then try 15amp again. I think it's a little better than the previous but still definitely buggy.

 

[casainho]

If I had the development environment I would have tested the following solution:
1. Will introduce a correction parameter that represent the difference between the torque value sensor at the calibration point and and the maximum value for each pedal side.
2. Try to equalise the values at 0 kg for the left and right pedal sides in order to avoid jumps at the point at which we switch from left to right or back.
3. Try to smooth the torque values reading in order to avoid jump up and down. E.G. the value used in the control loop will be the average lets say of the last 3 values received from the torque sensor.

Any of the three options will improve the situation, however he smoothest operation we will achieve only by implementing the thee of them.

Am I right about my conclusions or I am missing something. There could be also other options but this is what I can propose based on my limited experience with this project.

1. So, if I understand correctly, you calibrate a value on the torque sensor, like on the left side and it says 134 but after you rotating the pedals that value can be up to 140. That happens to me also, the torque sensor is like that, do not give precise values, there is no point to expect that.

2. When the pedal switch from left <-> right, theoretically the torque value is 0 or minimum so no need to do any transition / equalize.

3. Smooth/average means it will also have a delay so the motor would react even slower than it does right now, so, I think this should be avoided.

Well, would be great to be able to log real time values of the torque sensor ADC, calculated KGs and position of PAS / angle position of pedals. I think this is a needed step to see what is really happening. Let's see if I have the energy and time to do this.

 

[casainho]

Just tested the updated firmware and there are still issues with throttle control. At 0 assist throttle doesnt work. At >0 assist, power delivery is erratic, it will go 15amp then lower to 0 then try 15amp again. I think it's a little better than the previous but still definitely buggy.

I want to have assist level 0 to safe disable the motor, so, when I stop riding for a bit and decide to lean the bicycle to tree or a wall, the motor will not start if the pedals rotate because they touched anywhere and rotated not intentionally - the same for touching the throttle not intentionally!!

When you say 15 amps, you mean you tested riding or with the wheel on the air??

 

[plpetrov]

1. So, if I understand correctly, you calibrate a value on the torque sensor, like on the left side and it says 134 but after you rotating the pedals that value can be up to 140. That happens to me also, the torque sensor is like that, do not give precise values, there is no point to expect that.

Thank you for this information. So it works as designed!

2. When the pedal switch from left <-> right, theoretically the torque value is 0 or minimum so no need to do any transition / equalize.

This minimum is causing the power burst for me. I tested three scenarios here based on my 0 calibration values for the left pedal 134 and 140 for the right one:
1. Aligning the two values at the highest one. Both left and right torque sensor calibration values for 0 set at 140.
2. Aligning the two values at the average one. Both left and right torque sensor calibration values for 0 set at 137.
3. Aligning the two values at the lowest one. Both left and right torque sensor calibration values for 0 set at 134.

The three of them solve the problem with the power burst. The second options gives better results for me. However this approach will lead to false calibration and shifting the calculated values. On my torque sensor the 4 units subtracted or added is a difference of 1 kg of force applied on the pedals.

3. Smooth/average means it will also have a delay so the motor would react even slower than it does right now, so, I think this should be avoided.

I would not say that this will be always wrong. It was a suggestion only and may be improved after better understanding on what event you are reading the torque sensor. Is it time based, event based e.g. on pedals positions or something else. Once this is known, based on the time interval and or the position / positions of reading during a pedals revolution, we may think of something else. E.G. using different weights for the different values ...

If I remember correctly in another post someone mentioned for the other firmwares the solution was to introduce a minimum value of the torque sensor value change that will lead to change of the calculated torques. Something like ignoring changes with 1, two or more units. This will bring some insensitivity of the system but will smooth the work of the motor and lead to less dynamics stress on the motor parts. Now for one rotation of the pedals I hear and I also see the data on the display fluctuating. This fluctuations at assist value of 20 are very serious and will be better to avoid them. The better will be to have dependancy on the assist lever.

Well, would be great to be able to log real time values of the torque sensor ADC, calculated KGs and position of PAS / angle position of pedals. I think this is a needed step to see what is really happening. Let's see if I have the energy and time to do this.

Thats is the right approach to start our analysis.
In RC controlled aircrafts we are using and SD card for logging embedded in the flight controller. In the older models when this option was not available and external board with SD card and something else was used. In case we have an option to connect an external logging device that will be a good start of gathering data for further analysis.

 

[casainho]

If I remember correctly in another post someone mentioned for the other firmwares the solution was to introduce a minimum value of the torque sensor value change that will lead to change of the calculated torques. Something like ignoring changes with 1, two or more units. This will bring some insensitivity of the system but will smooth the work of the motor and lead to less dynamics stress on the motor parts. Now for one rotation of the pedals I hear and I also see the data on the display fluctuating. This fluctuations at assist value of 20 are very serious and will be better to avoid them. The better will be to have dependancy on the assist lever.

The thing is that assist level 20 has a factor of 1.500, which means that when user does 12 kgs on the torque sensor the motor current will be 16 amps. My leg when resting on the pedals weight 12 kgs!! The thing is that the assist level 20 is to much, it should be used only as a kind of on / off motor switch, very light pedaling and motor runs at max power.

You should not expect all this to work well because probably all the TSDZ2 was not developed to have such high sensitivity and still work well. You can't have this high assistance levels on original firmware.

2. When the pedal switch from left <-> right, theoretically the torque value is 0 or minimum so no need to do any transition / equalize.

This minimum is causing the power burst for me. I tested three scenarios here based on my 0 calibration values for the left pedal 134 and 140 for the right one:
1. Aligning the two values at the highest one. Both left and right torque sensor calibration values for 0 set at 140.
2. Aligning the two values at the average one. Both left and right torque sensor calibration values for 0 set at 137.
3. Aligning the two values at the lowest one. Both left and right torque sensor calibration values for 0 set at 134.

The three of them solve the problem with the power burst. The second options gives better results for me. However this approach will lead to false calibration and shifting the calculated values. On my torque sensor the 4 units subtracted or added is a difference of 1 kg of force applied on the pedals.
[/quote]
1 kg of incorrect value is nothing!! This torque sensor can't measure so well.

So, I would say, until we have a better solution (if possible?) the wiki should alert users to expect some oscillations when using assist level > 10 and on torque sensor calibration to do the same you did on 2.2.

 

[ezrider1199]

I took it outside. Also at assist 0, you can still use throttle control but it's a trickle of power, like a walk mode almost.

Just tested the updated firmware and there are still issues with throttle control. At 0 assist throttle doesnt work. At >0 assist, power delivery is erratic, it will go 15amp then lower to 0 then try 15amp again. I think it's a little better than the previous but still definitely buggy.

I want to have assist level 0 to safe disable the motor, so, when I stop riding for a bit and decide to lean the bicycle to tree or a wall, the motor will not start if the pedals rotate because they touched anywhere and rotated not intentionally - the same for touching the throttle not intentionally!!

When you say 15 amps, you mean you tested riding or with the wheel on the air??

 

[plpetrov]

The thing is that assist level 20 has a factor of 1.500, which means that when user does 12 kgs on the torque sensor the motor current will be 16 amps. My leg when resting on the pedals weight 12 kgs!! The thing is that the assist level 20 is to much, it should be used only as a kind of on / off motor switch, very light pedaling and motor runs at max power.

You should not expect all this to work well because probably all the TSDZ2 was not developed to have such high sensitivity and still work well. You can't have this high assistance levels on original firmware.

So, I would say, until we have a better solution (if possible?) the wiki should alert users to expect some oscillations when using assist level > 10 and on torque sensor calibration to do the same you did on 2.2.

Combining the info from these three paragraphs, and taking into account the major difference between the standard and the coaster brake version, gives us the answer:

In the coaster brake version we are missing one of the clutches. This means that the pedals always rotate together with the front sprocket like in the non motorisée version. In this case no light pedaling is possible, as the pedals will turn as fast as the front sprocket driven by the motor.

At high assist levels this might be dangerous as the pedals might kick your legs or hands in case you lose control for some reason. It might be even worse for the people that drive the bikes with their hands.

From technical point of view we have one more effect. The addition inertial moment introduced by the pedals due to the missing clutch is feeder back to the control system with a positive value. I think the English term is “positive system feedback control”. This makes the system not stable and under certain conditions will lead to saturation and maximum power output. If we compare this with mic connected to amplifier and speaker, I think in English this is called frequency howling https://electronics.howstuffworks.com/gadgets/audio-music/question263.htm

A nice and important safety feature will be an algorithm that could detect such situation like predefined power or pedals rotation burst for a very short predefined time interval. Could it be the case that we have it and this could be one of the reasons for the motor power oscillation?

 

[plpetrov]

Well, would be great to be able to log real time values of the torque sensor ADC, calculated KGs and position of PAS / angle position of pedals. I think this is a needed step to see what is really happening. Let's see if I have the energy and time to do this.

Thats is the right approach to start our analysis.
In RC controlled aircrafts we are using and SD card for logging embedded in the flight controller. In the older models when this option was not available and external board with SD card and something else was used. In case we have an option to connect an external logging device that will be a good start of gathering data for further analysis.

This is the device I mentioned:

http://www.helipal.com/blackbox-flight-data-recorder-for-cleanflight-betaflight.html


And this is how you connect it with your flight controller :

https://www.dronetrest.com/t/openlog-black-box-flight-data-recorder-setup-guide/1618

We may use this device or better esp8266 or even better esp32 with an added SD card.

The question is do we have all the data available in the serial interface between the motor and the display, how the interface is structured and do we have enough bandwidth/speed?

In the same thread if I remember correctly some had such device connected for the purpose of remote morning. May be we can take this as a starting point of it is open source.

In case you think that this idea might be valuable, we can start a new small project. I will be the first volunteer...

 

[casainho]

The question is do we have all the data available in the serial interface between the motor and the display, how the interface is structured and do we have enough bandwidth/speed?

In the same thread if I remember correctly some had such device connected for the purpose of remote morning. May be we can take this as a starting point of it is open source.

In case you think that this idea might be valuable, we can start a new small project. I will be the first volunteer...

I would use the SW102 display. After getting the data on the display, I would forward by UART over Bluetooth and then record on mobile phone the data received.

The motor controller sends data every 100ms to display. It also evaluates the torque sensor and cadence data at every 100ms, not less, so, the same data the motor controller uses is forward to the display.

I would send to display and then to mobile phone:
- ADC torque sensor
- KG torque sensor
- cadence
- pedal position

The only one that is not sent right now is the pedal position but is can be exchanged for other variable, like throttle.

 

[plpetrov]

The question is do we have all the data available in the serial interface between the motor and the display, how the interface is structured and do we have enough bandwidth/speed?

In the same thread if I remember correctly some had such device connected for the purpose of remote morning. May be we can take this as a starting point of it is open source.

In case you think that this idea might be valuable, we can start a new small project. I will be the first volunteer...

I would use the SW102 display. After getting the data on the display, I would forward by UART over Bluetooth and then record on mobile phone the data received.

The motor controller sends data every 100ms to display. It also evaluates the torque sensor and cadence data at every 100ms, not less, so, the same data the motor controller uses is forward to the display.

I would send to display and then to mobile phone:
- ADC torque sensor
- KG torque sensor
- cadence
- pedal position

The only one that is not sent right now is the pedal position but is can be exchanged for other variable, like throttle.

It is a nice solution. Unfortunately I do not have the SW102 and that’s why I suggested the SD card logging.

 

[hetm4n]

Casainho there is a problem in version 0.8.0. by 0.7 the engine stop time has been shortened. it is too short for my bike frame. this causes the engine to stop constantly on bumps and unevenness. It will be a big problem in some frames with full suspension where crank retraction occurs while bending the rear suspension. Could it be done so that this stop time could be adjusted by itself in the display?

 

[plpetrov]

I think this is because of the overrun. @Casainho, did you check the original fix from mbrusa. He had to modify ebike_app.c in order not to use overrrun fix when throttle is configured, otherwise it cuts the power if user is not pedaling.
Another question, did you managed to sort what user plpetrov had reported with weird behaviour at assist levels greater than 10?
Thank you

Yes, you were right about the throttle - it is fixed now.

About the weird behaviour at assist levels greater than 10, I don't know... I hope you guys can provide more feedback of your tests as I am not having this issues.

About the negative torque to brake on the coast brake version, I prepared a display firmware version that shows the ADC torque sensor value instead of the odometer so seeing the odometer on main screen will help to debug and see how the ADC torque sensor value when braking.

https://github.com/OpenSource-EBike-firmware/Color_LCD/tree/testing_coast_brake/firmware/releases/0.8.1

I have missed this post. I will use it for my next testing. My understanding is that this is for monitoring only. My previous experience shows that the values we see on the display are a bit delayed and fluctuating. More helpful will be if there is a way that we can configure the value required in order to initiate the braking? I remember I send you some suggestions but what is the current hardcoded value that was implemented in the firmware?

 

[jeff.page.rides]

I've been watching all the effort that's been going on in the last few weeks and I'm very excited about the prospects.
On my handcycle with a coaster brake motor in version 20 with all the latest fixes, it's working well. But there is room for improvement. As I stated before I need to hold back on the pedals to apply negative forced to the torque sensor as I turn on the system so that it has the power I need for it to work for me. When it's turned up that sensitive you can take your hands off the pedals and it will continue to go forward on its own, but it takes very little effort to stop the rotation. Reading all these updates it appears that I'll be able to turn up the sensitivity of the torque sensor to get the same result without having to pull back on the cranks as I turn on the system. That is very appealing to me and I can't wait to try it. The only reason I haven't tried it yet is that it is so much work to change displays flash everything, then try it and have something not work and then have to change everything back to the way it was. Also if you can set the torque sensor sensitivity in that way without pulling back on the cranks it will also work on a standard non-coaster brake motor, that a lot of hand cyclists use but can't get the power they need.
Thanks for all the hard work. As soon as you think the software is ready for me to try without having to go back to the old setup let me know? I'm ready to switch to my 860C!

 

[r0mko]

I've released a torque mod for FW v0.57: https://github.com/r0mko/TSDZ2-Smart-EBike/releases/tag/v0.57.10
Works fine for me, but motor stops way too early. If I go on pedalling after a brief pause, the motor gives a strong kick to butt. This is not a big deal and I learned quickly how to avoid this, but I would like to have this overrun fix as an option like "Coaster brake", that can be disabled.

 

[mbrusa]

Casainho there is a problem in version 0.8.0. by 0.7 the engine stop time has been shortened. it is too short for my bike frame. this causes the engine to stop constantly on bumps and unevenness. It will be a big problem in some frames with full suspension where crank retraction occurs while bending the rear suspension. Could it be done so that this stop time could be adjusted by itself in the display?

@Casainho
They reported me the same problem with fix overrun in v.20, it is more evident with a full suspension.
I have tried to increase the value of PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP_MIN, I have had confirmation that it is much better. The ideal would be to set the value on the display.

 

[plpetrov]

I've released a torque mod for FW v0.57: https://github.com/r0mko/TSDZ2-Smart-EBike/releases/tag/v0.57.10
Works fine for me, but motor stops way too early. If I go on pedalling after a brief pause, the motor gives a strong kick to butt. This is not a big deal and I learned quickly how to avoid this, but I would like to have this overrun fix as an option like "Coaster brake", that can be disabled.

What do you mean by “motor gives a strong kick to butt“. Is there a relationship between the assist level and the power of this kick? How do you avoid it?
I just want to compare my observations with yours in order to try to catch a pattern.

 

[r0mko]

I've released a torque mod for FW v0.57: https://github.com/r0mko/TSDZ2-Smart-EBike/releases/tag/v0.57.10
Works fine for me, but motor stops way too early. If I go on pedalling after a brief pause, the motor gives a strong kick to butt. This is not a big deal and I learned quickly how to avoid this, but I would like to have this overrun fix as an option like "Coaster brake", that can be disabled.

What do you mean by “motor gives a strong kick to butt“. Is there a relationship between the assist level and the power of this kick? How do you avoid it?
I just want to compare my observations with yours in order to try to catch a pattern.

Force of butt-kick definitely depends on assist ratio. Also after applying torque calibration it became much milder, now it is not even a kick, but a gentle push. But anyway it kinda bothers me. It happens when you briefly stop pedalling around the point, when pedals are vertical. The motor instantly stops and immediately starts again, making kind of a jerk or buck. I'm terrible in putting things into words today.

 

[plpetrov]

I've released a torque mod for FW v0.57: https://github.com/r0mko/TSDZ2-Smart-EBike/releases/tag/v0.57.10
Works fine for me, but motor stops way too early. If I go on pedalling after a brief pause, the motor gives a strong kick to butt. This is not a big deal and I learned quickly how to avoid this, but I would like to have this overrun fix as an option like "Coaster brake", that can be disabled.

What do you mean by “motor gives a strong kick to butt“. Is there a relationship between the assist level and the power of this kick? How do you avoid it?
I just want to compare my observations with yours in order to try to catch a pattern.

Force of butt-kick definitely depends on assist ratio. Also after applying torque calibration it became much milder, now it is not even a kick, but a gentle push. But anyway it kinda bothers me. It happens when you briefly stop pedalling around the point, when pedals are vertical. The motor instantly stops and immediately starts again, making kind of a jerk or buck. I'm terrible in putting things into words today.

In my opinion this is exactly what I am experiencing as a problem. For me it starts about 15 degrees before the left pedal reaches the top position and continues for the next 30 to 46 degrees of rotation. Problem becomes evident as of assist level 13 and with higher levels gets worse.
Are your torque sensor calibration values for the left and the the right pedal for the first calibration point with 0 weight the same? If not please configure the average of the two values on both sides.
For better results we need to wait for the investigation of Casainho.

 

[r0mko]

Force of butt-kick definitely depends on assist ratio. Also after applying torque calibration it became much milder, now it is not even a kick, but a gentle push. But anyway it kinda bothers me. It happens when you briefly stop pedalling around the point, when pedals are vertical. The motor instantly stops and immediately starts again, making kind of a jerk or buck. I'm terrible in putting things into words today.

In my opinion this is exactly what I am experiencing as a problem. For me it starts about 15 degrees before the left pedal reaches the top position and continues for the next 30 to 46 degrees of rotation. Problem becomes evident as of assist level 13 and with higher levels gets worse.
Are your torque sensor calibration values for the left and the the right pedal the same? If not please configure the average of the two values on both sides.
For better results we need to wait for the investigation of Casainho.

Apparently we're talking about the same problem. My torque sensor appears to be quite uniform. I will try to enter average values tomorrow and will also try to tinker with COASTER_BRAKE_TORQUE_THRESHOLD.

 

[plpetrov]

Force of butt-kick definitely depends on assist ratio. Also after applying torque calibration it became much milder, now it is not even a kick, but a gentle push. But anyway it kinda bothers me. It happens when you briefly stop pedalling around the point, when pedals are vertical. The motor instantly stops and immediately starts again, making kind of a jerk or buck. I'm terrible in putting things into words today.

In my opinion this is exactly what I am experiencing as a problem. For me it starts about 15 degrees before the left pedal reaches the top position and continues for the next 30 to 46 degrees of rotation. Problem becomes evident as of assist level 13 and with higher levels gets worse.
Are your torque sensor calibration values for the left and the the right pedal the same? If not please configure the average of the two values on both sides.
For better results we need to wait for the investigation of Casainho.

Apparently we're talking about the same problem. My torque sensor appears to be quite uniform. I will try to enter average values tomorrow and will also try to tinker with COASTER_BRAKE_TORQUE_THRESHOLD.
Screenshot 2020-04-08 at 22.08.12 copy.jpg

I did a mistake in my previous post. The average is necessary only for the torque calibration value with 0 weight. The rest may remain as they are. Sorry for that.

 

[stefkrger]

Has anyone tried to go back to the stock motor firmware from the OpenSource one?
I found some stock FW files posted here:
https://www.eco-ebike.com/blogs/eco-cycles-instructionals/tsdz2-motor-firmware-programming

I have a stock VLCD5 which I would use. Should I expect any problems when flashing the motor back?

 

[r0mko]

Has anyone tried to go back to the stock motor firmware from the OpenSource one?
I found some stock FW files posted here:
https://www.eco-ebike.com/blogs/eco-cycles-instructionals/tsdz2-motor-firmware-programming

I have a stock VLCD5 which I would use. Should I expect any problems when flashing the motor back?

What made you switch back to stock firmware?

 

[ilu]

Has anyone tried to go back to the stock motor firmware from the OpenSource one?
I found some stock FW files posted here:
https://www.eco-ebike.com/blogs/eco-cycles-instructionals/tsdz2-motor-firmware-programming

I have a stock VLCD5 which I would use. Should I expect any problems when flashing the motor back?

Expect no problems, the guide you linked to is very clear and thorough. If the option byte settings after read from the controller are different, just change them according to the image before continuing.

 

[James Broadhurst]

Sorry but not even the grandchildren could fix this, why can I not change the colour of the odometer and trip displays from red to white, please? V0.7.0 850C

 

[casainho]

Sorry but not even the grandchildren could fix this, why can I not change the colour of the odometer and trip displays from red to white, please? V0.7.0 850C

Go to configurations and then variables, then odometer and trip distance. Read the wiki page about features and configurations to see how they should be configured.