Dirkro
10 W
casainho said:
I am not good in programming but I found following formular: 95.5 * (1/0.637) = 150 ...
Shouldn't it be 95.5*0.637=60.8 instead , (I rounded from 0.637 to 0.5 , *100 , so find good corelation then ?
TSDZ2 mid drive with 860C, 850C or SW102 displays only -- Flexible OpenSource firmware (Casainho code only)
- Thread starter casainho
- Start date
I am not good in programming but I found following formular: 95.5 * (1/0.637) = 150 ...
Shouldn't it be 95.5*0.637=60.8 instead , (I rounded from 0.637 to 0.5 , *100 , so find good corelation then ?
Hi,
I'm going to buy a new TSDZ2 motor.
I will use this motor to remove parts to replace the parts that would fail in the engine that I have installed.
From what I read, a few months ago, the TSDZ2 motors that are now being manufactured have new gears.
Do you know of any seller in Aliexpress that has these new engines?
Do you also know if both 36V and 48V motors have the new gears?
I'm going to buy a 48V motor.
I think the controller is the same on the 36V and 48V motor? Do you confirm?
Thanks
I'm going to buy a new TSDZ2 motor.
I will use this motor to remove parts to replace the parts that would fail in the engine that I have installed.
From what I read, a few months ago, the TSDZ2 motors that are now being manufactured have new gears.
Do you know of any seller in Aliexpress that has these new engines?
Do you also know if both 36V and 48V motors have the new gears?
I'm going to buy a 48V motor.
I think the controller is the same on the 36V and 48V motor? Do you confirm?
Thanks
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,045
Thanks. I need to review that code as there are parts that does not make sense now, like that mapping that were being used before we started to use the human power as a factor for motor power.stancecoke said:
0.52NM per unprocessed ADC step. The comments are at least correct, I clear remember to make 0.33kgs of force on the digital fish scale for every ADC step.
stancecoke
100 kW
- Joined
- Aug 2, 2017
- Messages
- 1,810
OK, but if you limit the allowed range to 32 ADC steps, the sensitivity of the sensor is very poor... The max value, you can dissolve is 32 * 0,52 = 16,64 Nmcasainho said:
If you put your 80 kg on the horizontal crank, you will get 800N * 0,17m (crank length) = 136 Nm Torque.
regards
stancecoke
andrea_104kg
1 kW
- Joined
- Mar 5, 2018
- Messages
- 344
Actually when I asked for the emtb mode I was interested above all because many users on the Italian forum say that it has an infinite extension ... which on the 48v I miss a lot. I don't know how it is done.
I think the tsdz2 is already very emtb. It is possible to dose the pedaling force going from low assistance values to very high values.
I also think that such a mode in the absence of memory space on the LCD03 can simply be realized on the motor part without adjusting anything on the LCD03. For example, you could use level 1 for a fixed emtb. After all it works on vlcd5 which has no parameters to adjust.
I think the tsdz2 is already very emtb. It is possible to dose the pedaling force going from low assistance values to very high values.
I also think that such a mode in the absence of memory space on the LCD03 can simply be realized on the motor part without adjusting anything on the LCD03. For example, you could use level 1 for a fixed emtb. After all it works on vlcd5 which has no parameters to adjust.
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,045
I just measured again.stancecoke said:OK, but if you limit the allowed range to 32 ADC steps, the sensitivity of the sensor is very poor... The max value, you can dissolve is 32 * 0,52 = 16,64 Nmcasainho said:
If you put your 80 kg on the horizontal crank, you will get 800N * 0,17m (crank length) = 136 Nm Torque.
My torque sensor shows on LCD3 the value 46 on rest. If I put 10kgs, it shows 59, so a delta of 13 --> 0.77 kgs for each ADC step (8 bits). This means in the full ADC range of 12 bits, it can measure as low as 0.19 kgs but that also probably would need low pass filtering to get that resolution and so a delay on the signal/delay on reaction of torque sensor signal.
With my full weight of 100 kgs on the pedal I got max value of 103, a delta of 57, so max read of 43.9 kgs.
@Buba, can we repair the code on the human power math for next stable version??
stancecoke
100 kW
- Joined
- Aug 2, 2017
- Messages
- 1,810
casainho said:
So the output of the sensor is not linear. If you feed the three points 0 kg (0Nm), 10kg (17Nm) and 100kg (170Nm) to Excel and make a polinomal approximation you'll get this:
Perhaps you can do some more tests with e.g. 40kg and 60kg (let your child and your wife step on the pedal :wink: ) to get a better approximation.
regards
stancecoke
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,045
dameri said:
1. I tried that and LCD3 shows 0 (menu 9:5)
2. Walk assist worked in the beginning then motor make attack. It suddenly added more power and walk assist stop working.
I had motor power 400 W.
[/quote]
1. Well, human power value shown on odometer field (I should mention that before)!!
2. Seems an issue with walk assist?
Maybe you can put max assist level possible and pedal just a little to make motor running at max power BUT limit max power to the values you desired like 100W, 200W, etc. That way the power will be limited to a fixed value and maybe you can also look at odometer to see your pedal power and discount that at the end or simple ignore very low values of it.
But please wait because we found that math is wrong on current firmware. After we correct it, would be nice to validate it that way you are testing.
casainho said:I just measured again.stancecoke said:OK, but if you limit the allowed range to 32 ADC steps, the sensitivity of the sensor is very poor... The max value, you can dissolve is 32 * 0,52 = 16,64 Nmcasainho said:
If you put your 80 kg on the horizontal crank, you will get 800N * 0,17m (crank length) = 136 Nm Torque.
My torque sensor shows on LCD3 the value 46 on rest. If I put 10kgs, it shows 59, so a delta of 13 --> 0.77 kgs for each ADC step (8 bits). This means in the full ADC range of 12 bits, it can measure as low as 0.19 kgs but that also probably would need low pass filtering to get that resolution and so a delay on the signal/delay on reaction of torque sensor signal.
With my full weight of 100 kgs on the pedal I got max value of 103, a delta of 57, so max read of 43.9 kgs.
@Buba, can we repair the code on the human power math for next stable version??
I have missed a lot of posts but will answer this one first.
I recommend to improve the human power calculation and measurement for the next stable release, version 0.20.0. But of course, release the stable 0.19.0 first, when the throttle has been confirmed to work.
I have already started some tests and asked the community about initial readings. Wanted to do a sensor and response model on the torque sensor we can use to more accurately measure human power. Was curious about the full range of operation, possible non-linearity, resolution and everything else relevant. Would then switch focus on the algorithm to see how it can be improved.
Have worked with sensors and noisy systems more often than not. Used different filtering algorithms and sometimes added hardware filtering. But hardware filtering is at the PCB design level and not applicable on the TSDZ2. But I am certain it can be improved with software.
The cadence sensor is assumed to be perfect for now. The torque sensor needs to be accurate enough, high enough resolution, measure fast enough and lastly have a good enough algorithm for the pedal strokes. I do not know to one hundred percent which of these parameters are lacking but I know from first principles that it is one or several mentioned parameters.
One important part is definitely the algorithm:
View attachment 1
1. Well, human power value shown on odometer field (I should mention that before)!!casainho said:
2. Seems an issue with walk assist?
Maybe you can put max assist level possible and pedal just a little to make motor running at max power BUT limit max power to the values you desired like 100W, 200W, etc. That way the power will be limited to a fixed value and maybe you can also look at odometer to see your pedal power and discount that at the end or simple ignore very low values of it.
But please wait because we found that math is wrong on current firmware. After we correct it, would be nice to validate it that way you are testing.
[/quote]
Ok, I'll wait and have little misunderstanding.
casainho said:
Was so happy to see that graph. Because I have yet to test the upper range. Would be really interesting to study. But as the sensor was saturated and maxed out I quickly turned down the excitement. It seems to be a really impressive sensor nonetheless. Would never guessed that from such a cheap package.
casainho said:
As you said, it is best to wait with further testing until we have improved the code. But just wanted to mention that your proposal to validate the human power calculation is very good. For anyone wondering, this is a relative test and the absolute values do not matter. What matters is the relative value of human power and motor power during the same conditions.
* Replicate all runs at same start and end points
* Same inclination throughout the testing track
* Same speed, all tests
* Low and preferably no steering input
* Same user, all tests
* Same bike, all tests
* Needs to be tested at certain motor power levels!
* Needs to be tested at different user inputs but same human power: one test using high torque with low cadence, another using medium torque with medium cadence and lastly using low torque with high cadence
* Special development firmware that can maybe use constant PWM motor control at higher speeds during validation
Walk Assist only works at speeds below 8 km/h or around 5 mph. Above this speed it is disabled and if trying to enable Walk Assist over this speed Cruise will be activated, if it is enabled in the Configuration Menu.
thineight said:
Great support! When it is time to do some testing and validation a procedure/guideline will be made! The more data we get the better it usually gets!
dameri said:
Correct!
zappan said:
Thanks Zappan, interesting feedback! eMTB is something we definitely need to take a look at and add to the firmware in the future. For now there are a lot of things to do so can not say when this will be implemented but seems to be a great function!
stancecoke
100 kW
- Joined
- Aug 2, 2017
- Messages
- 1,810
buba said:
This diagram is correct for sensors, that only measure on one crank (like the Thun or the NTCE Bottom Bracket sensors).
Our sensor reads the torque from both cranks, so the graph is just sinusoidal.
In the KT-controller firmware we read a torque value at every PAS interrupt and average it over one crank revolution.
32 (=2^5) PAS Pulses per revolution
Code:
ui16_TORQUE_accumulated-=ui16_TORQUE_accumulated>>5; //Number of PAS Mags = 2^5
ui16_TORQUE_accumulated+=(uint8_t) map (ui8_adc_read_throttle (), ADC_THROTTLE_MIN_VALUE, ADC_THROTTLE_MAX_VALUE, 0, SETPOINT_MAX_VALUE);
ui8_Torque = ui16_TORQUE_accumulated>>5;I know, that casainho is no friend of interrupts
regards
stancecoke
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,045
We are reading at the same rate we need the signal to react to it: 100 ms. I guess this way is faster at least on low cadence.stancecoke said:buba said:
This diagram is correct for sensors, that only measure on one crank (like the Thun or the NTCE Bottom Bracket sensors).
Our sensor reads the torque from both cranks, so the graph is just sinusoidal.
In the KT-controller firmware we read a torque value at every PAS interrupt and average it over one crank revolution.
32 (=2^5) PAS Pulses per revolution
Code:ui16_TORQUE_accumulated-=ui16_TORQUE_accumulated>>5; //Number of PAS Mags = 2^5 ui16_TORQUE_accumulated+=(uint8_t) map (ui8_adc_read_throttle (), ADC_THROTTLE_MIN_VALUE, ADC_THROTTLE_MAX_VALUE, 0, SETPOINT_MAX_VALUE); ui8_Torque = ui16_TORQUE_accumulated>>5;
I know, that casainho is no friend of interrupts
regards
stancecoke
Also TSDZ2 hardware seems to low pass filter very well the torque sensor signal, unlike on KT that can use any different torque sensor out there in the market.
So we just need to correct current constants on the code and the result should be good as almost for sure his output is linear. We are already counting with the sinosoidal signal.
Then we need to validate human power VERSUS motor power.
stancecoke said:buba said:
This diagram is correct for sensors, that only measure on one crank (like the Thun or the NTCE Bottom Bracket sensors).
Our sensor reads the torque from both cranks, so the graph is just sinusoidal.
In the KT-controller firmware we read a torque value at every PAS interrupt and average it over one crank revolution.
32 (=2^5) PAS Pulses per revolution
Code:ui16_TORQUE_accumulated-=ui16_TORQUE_accumulated>>5; //Number of PAS Mags = 2^5 ui16_TORQUE_accumulated+=(uint8_t) map (ui8_adc_read_throttle (), ADC_THROTTLE_MIN_VALUE, ADC_THROTTLE_MAX_VALUE, 0, SETPOINT_MAX_VALUE); ui8_Torque = ui16_TORQUE_accumulated>>5;
I know, that casainho is no friend of interrupts
regards
stancecoke
Fully aware, but wanted a simple graph showing the complexity of a single torque pulse and that the algorithm is a major part of the equation. Nice implementation!
casainho said:
Here is one idea that I think will point us to a slightly better value for now.
Let us say we are very proficient in calculating the average torque applied during a single stroke. We are treating it just as one would treat a full wave rectified sinusoidal voltage over a load. We look at the maximum amplitude and multiply it with 0.637 and get the average voltage applied over the same load. This simplification is good enough for now so we will stick with it.
Now the idea.
The cadence is also changing throughout the stroke. When pressure is applied to the pedals the speed of the bike is proportional to the crank cadence. And it decreases just before the next pedal stroke.
So, let us say that the cadence is our current in the analogy. Well, the full wave rectified sinusoidal current through a load also has an equivalent average current through the same load. This is actually the same formula used for the voltage: the maximum amplitude multiplied with 0.637.
If we take the equivalent average values of both waves we should get a better approximation of the average human power.
To conclude, average human power = 0.637 * torque * 0.637 * cadence ≈ 0.41 * torque * cadence
The analogy is lacking but is somewhat comparable in some aspects of the logic. Totally wrong approach if working with AC power though. But we are trying to approximate a coefficient for the calculation of mechanical power. If we are lucky this will be linear in the entire operating range. There will most certainly be a need for some sort of calibration determined through testing.
casainho said:
Sorry for the late reply!
The entire system is based on controlling the current, and it is therefore controlling the motor torque if in the normal operating mode. So the performance of the current control is dictated by how well the current is measured, and this is a function of the measuring frequency, the resolution and the accuracy of said measurements. This together with the user input is what determines the overall feeling and responsiveness of the system.
I just wanted to share my ambition to further improve the system with some possible benefits. It would especially be noticed during startups and other situations where finer resolution of the current control would be more noticeable.
* Smoother throughout the entire power range
* Every start would be more responsive with almost instant assist
* Smooth acceleration
* More continuous power levels
* Drive train would experience less stress
* Possible less consumption when not having to cycle between different power steps
Walk Assist is not controlled with current as the resolution is too coarse for the fine control that is needed. Instead, PWM control is utilized with almost 9 times the control resolution compared to the current control.
casainho said:
I have noticed that a lot of work has been put down to optimize the execution time in the motor.c. Never stated to make it slower or make some compromises. Only as fast or faster. Together with improvements. I was not talking about a complete system redesign. The changes are limited to one single variable.
One approach would be to still keep the 8 bit value but convert it to ui8_battery_current_x6 or ui8_adc_battery_current. Then the operations and variable sizes of 8 bit would remain. Only difference is that we convert the 10 bit ADC value to 160 mA current steps during the ADC conversion. Not saying that is the best approach but am trying to convey that there are several ways of doing it and still maintaining speed and even simplifying code.
casainho said:
To discard two bits and therefore reduce the resolution with a factor of 4 is one way of filtering the values. This will remove noise that is between the 625 mA steps. But on the other hand you loose the resolution. Could be possible to filter the value in the same way the other measurements are filtered. But without having seen the type of noise and the amplitude I can not say much. Just that I have never used a sensor without some form of filtering. And more often than not it has been software filters.
casainho said:
Am only talking about one variable and not the entire system. And can be made to 8 bit if going with the approach mentioned above.
-----------------------------
I take it as the community sees no real reason to go this path and there are other more important things to prioritize. That is totally fine! But I think it is good to have a discussion.
I ride a lot on the tsdz2 motor (more than 3000 km, using 36 volts and 48 volt motors with 36 and 52 volts batteries). I still use firmware 18.2 (I tried the newer firmware, but returned to 18.2). I use the motor a lot in difficult conditions: mountains, mud, subzero temperatures. I like almost everything in 18.2 except for a few moments. I would like off-road faster engine start (more than 10 amps per second. Maybe 15 or 20? I have iron gear and Japanese bearings everywhere (the Chinese all fail very quickly) and I need more power very quickly!) Another problem, the motor stops for a long time and spins for another 1-2 seconds after I stopped pedaling. Once this led to a chain bite due to dirt on the front gear and the motor managed to wind the chain in 1-2 seconds and pull out the rear derailleur with destruction. It would be great off-road to quickly stop the motor together with the speed of the pedals.
jbalat
10 kW
Here is an article on the new 2020 BoschCX motor
Just out of interest we have been talking about eMTB mode and I have been talking about reducing drag from the motor in case where you have a really low assist or max speed limit and you are trying to peddle faster than the motor.
Not really many take aways for this group but interesting that the max power assist has gone up from 300% to 340%. I guess this is easy for us to program when we setup each level even though there are technical reasons why we may never be able to achieve even 200%. This motor is now also lighter than the TSDZ2 which is pretty cool.
Enjoy
https://ebike-mtb.com/en/new-bosch-performance-line-cx-2020-motor-review/
Just out of interest we have been talking about eMTB mode and I have been talking about reducing drag from the motor in case where you have a really low assist or max speed limit and you are trying to peddle faster than the motor.
Not really many take aways for this group but interesting that the max power assist has gone up from 300% to 340%. I guess this is easy for us to program when we setup each level even though there are technical reasons why we may never be able to achieve even 200%. This motor is now also lighter than the TSDZ2 which is pretty cool.
Enjoy
https://ebike-mtb.com/en/new-bosch-performance-line-cx-2020-motor-review/
stancecoke
100 kW
- Joined
- Aug 2, 2017
- Messages
- 1,810
buba said:
This change is very very small, due to mass inertia, see the values on the y-axis in your plot.
buba said:
With this you will get most scatter. Over what period of time is the maximum measured? Refers the period to one crank revolution?
10 samples per second is much less than 32 samples per revolution at a "normal" cadence and you'll get aliasing effects with this small input rate.
buba said:
You are right, the physics and the math is really simple. We just need to know cadence and torque in it's correct pyhsical units.
regards
stancecoke
Similar threads
