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

Good afternoon, tested version 0.19 Beta 08, excellent smooth 48 km without recistence back, my opinion is the best I've tried. Many thanks to all the developers. Greetings from Melilla Spanish city in North Africa. :bigthumb:
 
Uturn said:
Uturn said:
buba said:
If no one reports any errors
assist seems to switch on less quick than on 0.18
I think this is related to having set the support level a bit lower than before, so it's not a problem.

Glad you sorted it out!



dameri said:
I took ride with v0.19.0-beta8 and it worked fine.
Tested walk assist, cruise and boost.

Big thanks once again for developers :bigthumb:

Great! :bigthumb:



Popo15 said:
Good afternoon, tested version 0.19 Beta 08, excellent smooth 48 km without recistence back, my opinion is the best I've tried. Many thanks to all the developers. Greetings from Melilla Spanish city in North Africa. :bigthumb:

Cool! :D


--------------------------------------

Very good feedback on the 0.19.0 beta 8!

The last thing I would like to know is if the throttle function operates as intended. Supposedly it did not work in a previous beta(?). Am not sure but there is an old issue posted on GitHub. Can someone confirm it does work? If it does, I see no reason to not release the official 0.19.0 for all users!

Seems like there are a lot of people using the watt-hour measurement to keep track on the SOC. Just wanted to mention that it is even more accurate on the 0.19.0!
 
Possible suggestion for the future: the new vlcd5 version of Marcoq has an "EMTB" level similar to the bosch. Implementing such a thing on lcd03?
 
andrea_104kg said:
Possible suggestion for the future: the new vlcd5 version of Marcoq has an "EMTB" level similar to the bosch. Implementing such a thing on lcd03?

Interesting! Actually, another user, bart594, brought that to my attention before and I was curios how it felt. Anyone know how it feels?

Can not promise anything but there is a possibility!


buba said:
bart594 said:
Hi buba,

i have one request for next release(s) which i find interesting for all users - trial/emtb mode like on bikes with brose or bosch motors. It is described here:
https://ebike-mtb.com/en/emtb-mode-bosch-cx-review/

To use trial mode user needs to set assist to factor >10 on one of assist levels and in the code on motor controller side it will look like this
if(m_configuration_variables.ui8_assist_level_factor_x10 > 9) then ->trial mode where
ui16_pedal_power_x10 <10% -> ui8_assist_level_factor_x10 = 0.3
10% < ui16_pedal_power_x10 <15% -> ui8_assist_level_factor_x10 = 0.5
15% < ui16_pedal_power_x10 <20% -> ui8_assist_level_factor_x10 = 0.7
and so on

This way this mode can be set up freely under one of assist level from 1-9 and final setup could looks like this:
assist level 1 - eco mode- let's say factor 0.3 for assistance,
then assist level 2 - trial where assistance depends on pedal power and varies between 0.3-3.2x
and assist level 3 - boost mode - 3.0x,
assist level 4 - 3.5x
and so on

For brose motors assistance in trial mode looks like on the screen (Eingabe - torque/pedal power and Leistung - % of motor assistance level which is our power motor factor )
In every review of bikes with this motor one of best thing that is always mentioned is the ride feeling that is very smooth and natural in this mode So having this feature can make our bikes closer to the 5000 USD and up machines ;)

Interesting and can't help but wonder how this feels. Would definitely be fun to try out! It is always possible to make a simple prototype version in the future!
 
buba said:
andrea_104kg said:
Possible suggestion for the future: the new vlcd5 version of Marcoq has an "EMTB" level similar to the bosch. Implementing such a thing on lcd03?

Interesting! Actually, another user, bart594, brought that to my attention before and I was curios how it felt. Anyone know how it feels?

Can not promise anything but there is a possibility!


buba said:
bart594 said:
Hi buba,

i have one request for next release(s) which i find interesting for all users - trial/emtb mode like on bikes with brose or bosch motors. It is described here:
https://ebike-mtb.com/en/emtb-mode-bosch-cx-review/

To use trial mode user needs to set assist to factor >10 on one of assist levels and in the code on motor controller side it will look like this
if(m_configuration_variables.ui8_assist_level_factor_x10 > 9) then ->trial mode where
ui16_pedal_power_x10 <10% -> ui8_assist_level_factor_x10 = 0.3
10% < ui16_pedal_power_x10 <15% -> ui8_assist_level_factor_x10 = 0.5
15% < ui16_pedal_power_x10 <20% -> ui8_assist_level_factor_x10 = 0.7
and so on

This way this mode can be set up freely under one of assist level from 1-9 and final setup could looks like this:
assist level 1 - eco mode- let's say factor 0.3 for assistance,
then assist level 2 - trial where assistance depends on pedal power and varies between 0.3-3.2x
and assist level 3 - boost mode - 3.0x,
assist level 4 - 3.5x
and so on

For brose motors assistance in trial mode looks like on the screen (Eingabe - torque/pedal power and Leistung - % of motor assistance level which is our power motor factor )
In every review of bikes with this motor one of best thing that is always mentioned is the ride feeling that is very smooth and natural in this mode So having this feature can make our bikes closer to the 5000 USD and up machines ;)

Interesting and can't help but wonder how this feels. Would definitely be fun to try out! It is always possible to make a simple prototype version in the future!

I have one bike with opensource firmware + LCD3 and one with the marcoq firmware, the latter looks smoother in the walk assist start (I make reference to what casainho said about its walk assist "rough start" and security related issues).
Maybe it worth to look at marcoq code to see both walk assist and eMTB functions.. perhaps some improvements can be taken out!
 
thineight said:
buba said:
andrea_104kg said:
Possible suggestion for the future: the new vlcd5 version of Marcoq has an "EMTB" level similar to the bosch. Implementing such a thing on lcd03?

Interesting! Actually, another user, bart594, brought that to my attention before and I was curios how it felt. Anyone know how it feels?

Can not promise anything but there is a possibility!

I have one bike with opensource firmware + LCD3 and one with the marcoq firmware, the latter looks smoother in the walk assist start (I make reference to what casainho said about its walk assist "rough start" and security related issues).
Maybe it worth to look at marcoq code to see both walk assist and eMTB functions.. perhaps some improvements can be taken out!

I was specifically asking how the eMTB mode feels like and not necessarily the marcoq firmware. The planned improvements for Walk Assist are very simple to implement. Not possible to use the Marcoq firmware as the community has discussed to make the Walk Assist safer, closed loop controlled, more predictable, with better user interface using the buttons, etc. Not difficult just takes time. And I have always used my time to make other changes I felt are more of a priority than improving the original Walk Assist.

The eMTB mode is simple to develop as well. But what takes time is making room and optimizing the function in the KT-LCD3, creating a menu and logic that makes for a great user experience, creating an "E" symbol in the assist level field, making the display and controller communicate with new parameters without compromising anything else, making it modular and simple for anyone to change which is important for the several developers working with different displays and lastly updating the wiki with explanations for the users.

But am still curious to hear if anyone has tried the eMTB mode and what they think of it. Be it on the marcoq TSDZ2 firmware or Bosch.

------------------------------

I might as well mention another improvement that both I and my father wanted to have for a very long time. And you, thineight, have also mentioned this in your feedback.

This is the resolution of motor power for every ADC current step limited by the resolution of the ADC:


Motor Power for every ADC Current Step.png


And this is the improved resolution, notice that the steps are not even noticeable in this scale:


Motor Power for every Current Step.png


This would make the entire operating range very smooth. Would be especially noticeable in the low range. Every start would be very predictable with instant assist. Smooth acceleration and no noticeable "power steps". The blue and the metal gear would experience less stress and last longer. The entire drive train would experience less stress and the motor would feel much smoother in its operation.

To do this you need to model the characteristics of the two different motors, 36 and 48 volt, and the controller. Then use the model to calculate and approximate the motor current on other known parameters except the ADC value from the shunt resistor. It would be possible to increase the resolution by a factor of 5, at least. This is very advanced and time consuming to develop. Best would be to have a dyno connected to the crank and then read the data directly from the system. The result would be a current model based on all the parameters that affect the current, working in conjunction with the ADC measurement.
 
Good morning, eMTB mode or automatic mode :thumb: :thumb: it would be great, battery saving in the field, excellent improvement.
 
buba said:
The last thing I would like to know is if the throttle function operates as intended. Supposedly it did not work in a previous beta(?). Am not sure but there is an old issue posted on GitHub. Can someone confirm it does work? If it does, I see no reason to not release the official 0.19.0 for all users!

Seems like there are a lot of people using the watt-hour measurement to keep track on the SOC. Just wanted to mention that it is even more accurate on the 0.19.0!

I don't use throttle anymore. I think I can use cruise instead. I don't even use cruise when I'm riding. But it is good to have for example foot injury when you cannot pedal anymore.
 
I have the Trek Powerfly with Bosch eMTB mode. I always use it by default.

For off road mountain biking it is so good I never have to change modes. It will help me when I go up steep hills and back off when I am just cruising. It seems to work out how much assist to give by what speed and how much pressure you exert but it is quick to give you full power when you need it so you dont get stuck half way up a hill.

On the other hand I find it very tiring on the road. It feels like it keeps backing off the assist especially when I am tired and going slow, occasionally I just stand on the pedals and get my speed up so it can help me again. Mind you I'm running 3 inch tyres and without assist I would be going no where. It still beats using Turbo mode which would eat the battery up in no time.

To be honest I really enjoy the way version 16 of the TSDZ2 opensource power is applied (sorry I havent tested any of the newer version yet). The only difference is I would switch between level 2, 3, and 4, depending on what I am doing. I guess the eMTB mode would try and make those decisions for you.

20190607_160000.jpg
 
jbalat said:
For off road mountain biking it is so good I never have to change modes. It will help me when I go up steep hills and back off when I am just cruising. It seems to work out how much assist to give by what speed and how much pressure you exert but it is quick to give you full power when you need it so you dont get stuck half way up a hill.
So you mention steep hills. Before, someone did mention using an accelerometer and inclinometer to detect the start of hills and so increase automatically the motor power assistance.

All data variables like wheel speed, motor current, etc are sent to LCD. The SW102 Bluetooth LCD can also receive information from a mobile phone and I hope from other devices, like a standalone Arduino with an accelerometer and inclinometer. SW102 would then be able to change motor power assistance when detecting start of hills and also use acceleration value for maybe as input to that algorithm to improve it.

To add input to TSDZ2 of accelerometer and inclinometer without having to solder wires to the motor controller board, I think SW102 LCD will be the easiest path to do it for the final user.
 
buba said:
The eMTB mode is simple to develop as well. But what takes time is making room and optimizing the function in the KT-LCD3, creating a menu and logic that makes for a great user experience, creating an "E" symbol in the assist level field, making the display and controller communicate with new parameters without compromising anything else, making it modular and simple for anyone to change which is important for the several developers working with different displays and lastly updating the wiki with explanations for the users.

But am still curious to hear if anyone has tried the eMTB mode and what they think of it. Be it on the marcoq TSDZ2 firmware

Isn’t this just a simple exponential factor rather than a flat multiplication factor. Simply look at the set user value of say 125% and then as the ADC value becomes higher, multiply that factor by itself ( or percentage of to prevent reaching max motor power to quickly ) for each of the ADC steps ? From old school days I think there was a set way of doing this to ramp up motors even in the simplist codes we were using then. If remember it as a feedback loop
 
buba said:
Not possible to use the Marcoq firmware as the community has discussed to make the Walk Assist safer, closed loop controlled, more predictable, with better user interface using the buttons, etc. Not difficult just takes time. And I have always used my time to make other changes I felt are more of a priority than improving the original Walk Assist.

------------------------------

I might as well mention another improvement that both I and my father wanted to have for a very long time. And you, thineight, have also mentioned this in your feedback.

This is the resolution of motor power for every ADC current step limited by the resolution of the ADC:


Motor Power for every ADC Current Step.png


And this is the improved resolution, notice that the steps are not even noticeable in this scale:


Motor Power for every Current Step.png


This would make the entire operating range very smooth. Would be especially noticeable in the low range. Every start would be very predictable with instant assist. Smooth acceleration and no noticeable "power steps". The blue and the metal gear would experience less stress and last longer. The entire drive train would experience less stress and the motor would feel much smoother in its operation.

To do this you need to model the characteristics of the two different motors, 36 and 48 volt, and the controller. Then use the model to calculate and approximate the motor current on other known parameters except the ADC value from the shunt resistor. It would be possible to increase the resolution by a factor of 5, at least. This is very advanced and time consuming to develop. Best would be to have a dyno connected to the crank and then read the data directly from the system. The result would be a current model based on all the parameters that affect the current, working in conjunction with the ADC measurement.

Hello buba, I just mentioned marcoq walk assist because it is smoother during the initial phase. This is regardless the "automatic" (and potentially unsafe) always-on.
So, if applicable and useful, marcoq code may be of interest to have a look for the smooth ramp algorithm.

Regarding the power ramp resolution increase, I think this will be a great improvement! :thumb:
I'm not an expert in coding of motor firmware so I do not understand the technical implication behind, anyway I think that a "resolution" increase of 3 times is more than enough even at lower assistance (0.1).
The boost function did not help as much as expected to tackle the initial lack of assistance at 0.1 assistance.
Question: is the boost factor a multiplier of the base level (e.g. if I set 2.0 it multiplies the 0.1 assistance=0.2) or is it the absolute assistance level during the boost duration?
Thanks as always!
 
Hi

here is marcoq's take on emtb mode

// calculate delta value between TOUR assist level and TURBO assist level
ui8_delta_assit_level = configuration_variables.ui8_assist_level_power[TURBO] - configuration_variables.ui8_assist_level_power[TOUR];

// calculate pedal (torque * cadence) step, related to delta assist level
ui16_step_pedal_torque_x_cadence = (uint16_t) (ui16_max_pedal_torque_x_max_cadence / ui8_delta_assit_level);

// calculate actual assist level power for assist pedal level 3 (eMTB)
configuration_variables.ui8_assist_level_power[EMTB] = (uint8_t) ((ui16_pedal_torque_x_cadence / ui16_step_pedal_torque_x_cadence) + configuration_variables.ui8_assist_level_power[TOUR]);

// update assist level factor x10 for assist pedal level 3 (eMTB)
configuration_variables.ui8_assist_level_factor_x10 = configuration_variables.ui8_assist_level_power[EMTB];

and here calculations for

// calculate max pedal torque * max cadence rpm
uint16_t ui16_temp = (uint16_t) ((PEDAL_TORQUE_X100 * (uint16_t) CADENCE_RPM_FOR_EMTB_MAX_POWER) / 100);
ui16_max_pedal_torque_x_max_cadence = (uint16_t) (ui16_temp * 255);

// calculate actual pedal torque * cadence rpm
ui16_pedal_torque_x_cadence = (uint16_t) (((uint32_t) ui16_pedal_torque_x100 * (uint32_t) ui8_pas_cadence_rpm) / 100);

To implement this we basically need 3 additional variables on LCD : min assist level, max assist level and max pedal cadence where motor riches max support
But for testing purposes for now all values could be hardcoded like 0.4-3 for min/max assist levels and pedal cadence = 95 and enable eMTB mode only if assist level factor is set up over factor 5
if(m_configuration_variables.ui8_assist_level_factor_x10 > 49) like in my original post
 
thineight said:
buba said:
Not possible to use the Marcoq firmware as the community has discussed to make the Walk Assist safer, closed loop controlled, more predictable, with better user interface using the buttons, etc. Not difficult just takes time. And I have always used my time to make other changes I felt are more of a priority than improving the original Walk Assist.

Hello buba, I just mentioned marcoq walk assist because it is smoother during the initial phase. This is regardless the "automatic" (and potentially unsafe) always-on.
So, if applicable and useful, marcoq code may be of interest to have a look for the smooth ramp algorithm.

Hey thineight, thanks! I understood what you meant but it is not applicable on the new Walk Assist code that will be written. I should have been more clear in my first response so sorry about that. The ramp up is very easy to do by the way and it is just a simple loop counter for PWM based Walk Assist. But thank you for the consideration!



thineight said:
buba said:
I might as well mention another improvement that both I and my father wanted to have for a very long time. And you, thineight, have also mentioned this in your feedback.

This is the resolution of motor power for every ADC current step limited by the resolution of the ADC:


Motor Power for every ADC Current Step.png


And this is the improved resolution, notice that the steps are not even noticeable in this scale:


Motor Power for every Current Step.png


This would make the entire operating range very smooth. Would be especially noticeable in the low range. Every start would be very predictable with instant assist. Smooth acceleration and no noticeable "power steps". The blue and the metal gear would experience less stress and last longer. The entire drive train would experience less stress and the motor would feel much smoother in its operation.

Regarding the power ramp resolution increase, I think this will be a great improvement! :thumb:
I'm not an expert in coding of motor firmware so I do not understand the technical implication behind, anyway I think that a "resolution" increase of 3 times is more than enough even at lower assistance (0.1).

I am very glad you liked the suggestion! This would be a very big improvement!

Can not say anything on what path the development will take except that there have been a lot of great suggestions from the community so far. As soon as 0.19.0 is officially released I will try to make a list on all the suggestions and then the community can decide what the priority is.



thineight said:
The boost function did not help as much as expected to tackle the initial lack of assistance at 0.1 assistance.
Question: is the boost factor a multiplier of the base level (e.g. if I set 2.0 it multiplies the 0.1 assistance=0.2) or is it the absolute assistance level during the boost duration?
Thanks as always!

Sorry to hear that! This will hopefully be improved in future versions. And to answer your question, it should be the absolute assistance level during the Boost.

Thank you!
 
bart594 said:
Hi

here is marcoq's take on emtb mode

...

To implement this we basically need 3 additional variables on LCD : min assist level, max assist level and max pedal cadence where motor riches max support
But for testing purposes for now all values could be hardcoded like 0.4-3 for min/max assist levels and pedal cadence = 95 and enable eMTB mode only if assist level factor is set up over factor 5
if(m_configuration_variables.ui8_assist_level_factor_x10 > 49) like in my original post

Have you tried the eMTB mode? And if so, I would like to hear what you think of it!
 
jbalat said:
I have the Trek Powerfly with Bosch eMTB mode. I always use it by default.

For off road mountain biking it is so good I never have to change modes. It will help me when I go up steep hills and back off when I am just cruising. It seems to work out how much assist to give by what speed and how much pressure you exert but it is quick to give you full power when you need it so you dont get stuck half way up a hill.

On the other hand I find it very tiring on the road. It feels like it keeps backing off the assist especially when I am tired and going slow, occasionally I just stand on the pedals and get my speed up so it can help me again. Mind you I'm running 3 inch tyres and without assist I would be going no where. It still beats using Turbo mode which would eat the battery up in no time.

To be honest I really enjoy the way version 16 of the TSDZ2 opensource power is applied (sorry I havent tested any of the newer version yet). The only difference is I would switch between level 2, 3, and 4, depending on what I am doing. I guess the eMTB mode would try and make those decisions for you.

20190607_160000.jpg

I very much appreciate your feedback!

Interesting that you do not even need to change modes when mountain biking. That means it responds very naturally from user input in that particular situation. And then again maybe lacking ever so slightly when on the road due to bias on speed together with applying less crank torque. You mention it is solved by standing on the pedals and getting up to speed again.

I take it you are satisfied with the eMTB mode overall. And maybe one simple improvement would be to have it configurable in regards to speed. That is to say actual bike speed and not cadence or anything else.

------------------------------------

The fact that eMTB would take speed in consideration is something I think makes sense. Some time ago I tried to improve the resolution on the assist level multipliers. But, due to space limitations in the KT-LCD3 at the time, it was just too time consuming to simply increase the variable sizes. One workaround I had in mind was to have the assist multipliers follow the graph i posted back then (see below).


funGraphs.png

The increasing power required to make a change in speed is something to consider when air resistance stops being negligible.
 
Yes I think Wayne also mentioned EXPO as you have shown on the graphs above..

The user could set levels 1 to 5 as normal for their riding style and eMTB mode could be level 6 which interpolates between levels 2 and 5 in an exponential curve.

This should be easy to implement.
 
jbalat said:
This should be easy to implement.

Yes, just need to take a decision on how configurable it should be when and if the time comes to develop this.

Anyway, seems to be a very cool function!



Waynemarlow said:
buba said:
The eMTB mode is simple to develop as well. But what takes time is making room and optimizing the function in the KT-LCD3, creating a menu and logic that makes for a great user experience, creating an "E" symbol in the assist level field, making the display and controller communicate with new parameters without compromising anything else, making it modular and simple for anyone to change which is important for the several developers working with different displays and lastly updating the wiki with explanations for the users.

But am still curious to hear if anyone has tried the eMTB mode and what they think of it. Be it on the marcoq TSDZ2 firmware

Isn’t this just a simple exponential factor rather than a flat multiplication factor. Simply look at the set user value of say 125% and then as the ADC value becomes higher, multiply that factor by itself ( or percentage of to prevent reaching max motor power to quickly ) for each of the ADC steps ? From old school days I think there was a set way of doing this to ramp up motors even in the simplist codes we were using then. If remember it as a feedback loop

Sorry, missed your reply! Not technically an exponential function. But I think you meant to say there should be a function calculating how much motor power to give instead of just multiplying the user input with a factor. If so, that would be completely correct to say. The feedback loop controlling the motor power is the same regardless of mode of operation. Only difference is in the calculation determining the amount of motor power to give for any given user input. Hope this helped and was clear!
 
Hi Buba, in my bike I am using the code of Marcoq in the EMTB mode, I set the cadence at 100 rpm, the pedaling sensation in off-road is fantastic, there is no more reason to intervene on the levels of assistance in fact if you find in front of a steep climb you just need to push more on the pedals and get the maximum assistance, when you are on the plain the 80W max engine, in my off-road laps the battery consumption has increased a bit.
If I could have in the other bike with LCD3 I would be happy.
 
buba said:
I might as well mention another improvement that both I and my father wanted to have for a very long time. And you, thineight, have also mentioned this in your feedback.

This is the resolution of motor power for every ADC current step limited by the resolution of the ADC:
My first question: is this a real issue or desire for optimization? -- I ask this because I never felt anything that I think this can the source of an issue.

I wrote my notes about the decision I took at start of the project to use 8 bits instead of 16 bits variables when possible. I am sure that having higher resolution can be better but there are disadvantages as well and we just need to understand what matters most.

Here my notes: https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Development:-Why-reducing-the-ADC-and-PWM-resolution-to-8-bits

---

Development: Why reducing the ADC and PWM resolution to 8 bits
This notes were written on 2019.06.17 by Casainho.

When I started this firmware, I had already developed a lot of it on the KT motor controllers OpenSource firmware. The TSDZ2 motor controller uses the same 8 bits 16MHz microcontroller STM8S105xx and so I just reused the most part of the code. The mainly big difference is the way the "low resolution FOC" algorithm is implemented because KT motor controllers has a specific part of the hardware to do it and on TSDZ2 it was to be done on a different way.

The STM8S105xx PWM channels that are in use have 16 bits resolution but I decided to use only 8 bits. The ADC channels have the resolution of 10 bits but I decided to use only 8 bits. The main advantages of using 8 bits are:

1. Faster processing speed
This microcontroller is very limited in terms of processing speed and to handle FOC we need to do it fast as possible. Also, we would like to increase the PWM frequency to make possible the motor to rotate faster with higher voltage and for that, we need more processing speed.

If not using the 8 bits resolution, the variables would be of 16 bits and the processing time would increase to a factor like x5 -- this would mean that probably FOC could not be implemented or would be worst resulting in the motor having less torque and the battery range would be lower.

2. Low pass filter of analog signals
This motor has wires with high peak currents and PWM high frequency, meaning the electric signals should be noisy.

On the analog signals measured by the ADC, the first 2 bits of the 10 bits are being discarded and this results in a fast way that filters the noisy analog signals.

3. Reducing programming memory usage
This microcontroller has very low memory size and so we need to save it if we want to implement advanced features like FOC.

The operations with 16 bits would increase to a factor like x4 the programming memory usage comparing to the 8 bits.
 
Proposal for validating measured human power

As others did mention before, I wish we could validate our current measurement of human power as it seems an high value.

Human power is pedal cadence * force applied on the pedals. For pedal cadence, I think we can trust very well on our current measurement.

For force, I took measures using a digital fish scale with a good repeatability and resolution and the signal output is very linear.
I am afraid of incorrect measurements here because:
- we are not applying a constant force all over the 360 degrees of pedal rotation. On current code we consider a sinewave and the value is multiplied by an average coefficient of 0.637, still, final value seems high.
- the force measurement was done with pedal stopped, at 90 degrees from ground, however, with pedal rotation the signal may change, maybe it can have a positive increase with cadence increase, who knows??
- force signal change due to low pass filter on hardware, maybe with increase of cadence the signal increases??

I don't know about commercial bicycle pedal torque sensors but I guess they are very expensive. I don't want to buy and do such work for calibration and so I was thinking on alternatives and here is my idea:

1. by now, I think we trust well on the measurements done by TSDZ2 for battery(motor) current and battery voltage. I did calibrate with a good multimeter that measurements and other did validate after.
2. we could try to compare the battery power usage VERSUS human power usage to move a bicycle on the same external conditions: same ground inclination, same wind, same speed, same gear, etc.

Can anyone do some repetitive measurements like this:
1. pedal in medium inclination hill to achieve a constant wheel speed of like 10 kms/h (with TSDZ2 motor disabled) and take note of the measured human power on LCD3.
2. using walk assist and not pedaling, configure a PWM duty-cycle value in a way to achieve a constant wheel speed of 10 kms/h. Take note of the measured battery(motor) power on LCD3.
3. Repeat for different motor power values like: 100, 200, 400, 600 and 800 watts.
 
casainho said:
Proposal for validating measured human power

As others did mention before, I wish we could validate our current measurement of human power as it seems an high value.

Human power is pedal cadence * force applied on the pedals. For pedal cadence, I think we can trust very well on our current measurement.

For force, I took measures using a digital fish scale with a good repeatability and resolution and the signal output is very linear.
I am afraid of incorrect measurements here because:
- we are not applying a constant force all over the 360 degrees of pedal rotation. On current code we consider a sinewave and the value is multiplied by an average coefficient of 0.637, still, final value seems high.
- the force measurement was done with pedal stopped, at 90 degrees from ground, however, with pedal rotation the signal may change, maybe it can have a positive increase with cadence increase, who knows??
- force signal change due to low pass filter on hardware, maybe with increase of cadence the signal increases??

I don't know about commercial bicycle pedal torque sensors but I guess they are very expensive. I don't want to buy and do such work for calibration and so I was thinking on alternatives and here is my idea:

1. by now, I think we trust well on the measurements done by TSDZ2 for battery(motor) current and battery voltage. I did calibrate with a good multimeter that measurements and other did validate after.
2. we could try to compare the battery power usage VERSUS human power usage to move a bicycle on the same external conditions: same ground inclination, same wind, same speed, same gear, etc.

Can anyone do some repetitive measurements like this:
1. pedal in medium inclination hill to achieve a constant wheel speed of like 10 kms/h (with TSDZ2 motor disabled) and take note of the measured human power on LCD3.
2. using walk assist and not pedaling, configure a PWM duty-cycle value in a way to achieve a constant wheel speed of 10 kms/h. Take note of the measured battery(motor) power on LCD3.
3. Repeat for different motor power values like: 100, 200, 400, 600 and 800 watts.

Sorry, in my opinion, by doing these tests, you add a lot of uncertain factors: weight, steepness of road, speed, lost in the drive, lost of tires.

Î did mesurments with a analog torque wrench, diretly on the axle . they where good repeatable would guess 10% error, see below.


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

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


When using a sinus factor simplified on 0.5
My idea to keep it simple and good: :

Cadence = rpm ´(per minute)
rounds per second =n = rpm/60
Torque =T (Nm) (for my engine T = "9.2 Value" -50)
basicaly the power in Watts is P = n *2* pi*T
Asuming the 0.5 corection P = n*2*3.14*(9.2value-50)*0.5
n=rpm/60

P=(9.2value -50) *0.052*rpm



What does this formula show when you compare it with the existing calculation?
 
Dirkro said:
Sorry, in my opinion, by doing the tests, you add a lot of centerpieces from weight, steepness of road, speed, lost in the drive, lost of tires.
And that are the same conditions on both tests, right??

Both motor and pedals pull the bicycle wheel using the same chain. I guess we would have to discount some loss inside TSDZ2 gears and motor inefficiency. At least, in the end we could have an idea if we are around +- 25% of the real value, I think.

Dirkro said:
Î did mesurments with a analog torque wrench, diretly on the axle . they where good repeatable would guess 10% error, see below.

What does this formula show when you compare it with the existing calculation?
Please check by yourself here: calc_pedal_force_and_torque(void)
https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/blob/master/src/controller/ebike_app.c
 
casainho said:
My first question: is this a real issue or desire for optimization? -- I ask this because I never felt anything that I think this can the source of an issue.

The issue is noticeable only at very low assistance (0.1 in my case), where you need to reach a certain amount of human power to activate the motor. I guess not so many user adopt this low coefficient therefore I consider it a nice to have rather than a real bug.
If this implies a major rework that may jeopardize already tested function and memory, we can stay as it is.
 
casainho said:
- the force measurement was done with pedal stopped,

Code:
// torque sensor
#define PEDAL_TORQUE_X100                         52

/*---------------------------------------------------------
  NOTE: regarding torque sensor
  Torque (force) value found experimentaly.
  
  Measured with a cheap digital hook scale, we found that
  each torque sensor unit is equal to 0.52 Nm. Using the 
  scale it was found that 0.33 kg was measured as 1 torque 
  sensor unit.
  
  Force (Nm) = 1 Kg * 9.18 * 0.17 (0.17 = arm cranks size)
---------------------------------------------------------*/

Is the value of 0,52Nm per step based on the 32 steps between min and max value, or per unprocessed ADC value or per 1 of 1 ... 255?


Code:
  ui8_g_adc_torque_sensor_min_value = ((uint8_t) ui16_adc_torque_sensor_offset) + ADC_TORQUE_SENSOR_THRESHOLD;
  ui8_g_adc_torque_sensor_max_value = ui8_g_adc_torque_sensor_min_value + 32;

On the other hand you map the ADC-value to the range 0 .... 255

Code:
  ui8_torque_sensor_raw = (uint8_t) (map (  UI8_ADC_TORQUE_SENSOR,
                                            (uint8_t) ui8_g_adc_torque_sensor_min_value,
                                            (uint8_t) ui8_g_adc_torque_sensor_max_value,
                                            (uint8_t) 0,
                                            (uint8_t) 255));

and then

Code:
 ui16_pedal_power_x10 = (uint16_t) ((((uint32_t) ui16_pedal_torque_x100 * (uint32_t) ui8_pas_cadence_rpm)) / (uint32_t) 150);

Perhaps we should calculate the pedals revolutions per second from the erps, this must be a constant ratio.

I don't understand why you are dividing by 150 in the end.

Code:
power * 10 = torque * 100 * rpm/60 * 2* PI *10/100
--> take all constants of the right side together --> PI/3 = approximatly 1. :shock:

regards
stancecoke
 
Back
Top