If I understand correctly, it's currently not possible to properly calibrate the TDSZ8 torque sensor?
Are there any suggestions on how we can get an accurate human watt reading?
TSDZ8 OSF (open source firmware)
- Thread starter mstrens
- Start date
Are there any suggestions on how we can get an accurate human watt reading?
Thanks a lot for your reply and clarification! That makes things much clearer. I’ll go ahead and configure my setup using the Java tool as suggested. Appreciate the info about the B02N as well!Hi, there is no need to compile a hex for a specific setup. You have to create you own setup using the Java Configuration Tool. That is what everyone, except for the 860c users, has to do either way.
I am not sure if anyone tested the B02N yet, but it will most likely work because it is the same hardware as the EDK01.
First I would like to make some comments:
1 - an accurate human watt is not important to get the assistance and feeling you want. In torque or cadence assist mode, it does not play any role in the assistance provided by the motor. In power assist mode, power delivered by the motor is human power (calculated by OSF) * assistance (as specified in level 1, 2,...) divided by a 50. E.g. for 860C. if assistance for level X in 860C is set on 100, then motor will provide 300 when human power is 150 (=150*100/50). For VLCD5, the assistances set in javaconfigurator are twice the value set in 860C but the value is divided by 2 when imported in OSF. So the result is the same.
So you could think that human power is essential to get the expected assistance.
In practice this is not really the case because human power it self is calculated as:
( torque - torque_offset) * torque_ADC_step * cadence * a ratio.
So motor assistance = ( torque - torque_offset) * torque_ADC_step * cadence * assistance_level /50.
You can see that you get the same motor assistance as long as (torque_ADC_step * assistance_level) remains the same.
So what is important is the product of the 2 parameters (torque_ADC_step and assistance_level) and not human power on it self.
Human power is just useful for information.
2 - Calculating human power with the formula ( torque - torque_offset) * torque_ADC_step * cadence * a ratio assume that the torque value provided by the sensor is proportional to the weight applied on the pedal. This is not true. For TSDZ2, tests have show that this is approximatively the case up up to 25 kg (at least for some motor). After 25 kg the ratio (measured torque/applied weight) decrease a lot. At this stage, I do not know if it is the same for TSDZ8. Ideally, different users should measure the ADC torque for different weight (from 0 up to 80kg) and for the 2 horizontal pedal positions. Putting the result in graphical form would help to confirm (or not) the validity of the formula (and on wich range.
I make this comment to insist on the fact that human power as calculated by OSF will not be accurate over the whole range of weight even if torque_ADC_step is fine tuned.
In a next post, I will try to explain how to estimate the best value for torque ADC step in the assumption that TSDZ8 torque sensor value are proportional to weigth when weigth is less than e.g. 25 kg. Keep in mind that this will only provide a raw estimation of human, power.
This is explained in the manual of VLCD5 (see manual on the web). It requires a quite complex sequence of keys.
It is not always easy. You could have to try several times before you succed.
To calculate the best torque ADC step for TSDZ8 when version 0.1.20 (or other version that uses the max torque over one pedal rotation to calculate the assist).
To try to be clear, I will use dummy values for different measurements of the ADC torque sensor
- ADC when right pedal is horizontal (and pointing to the front) with no weight : 170
- ADC min over 360° pedal rotation with no weight : 165
- ADC max over 360° pedal rotation with no weight : 190
- ADC with max weight (80 kg) on the right pedal (horizontal) : 450
- ADC when right pedal is horizontal and weight is is e.g. 24 kg (can be another weight in range 20/25 kg) : 300
There are 3 values to fill in 860C or javaconfigurator.
- torque ADC offset = max value of ADC with no weight + some margin (e.g. 10). So 190 +10 = 200
- torque ADC max = ADC value for max weight = 450.
- torque ADC step = 24 * 167 / ((300 - 165 -10) * 160 / (450-190 -10 )) ; Here 167 and 160 are just fixed values; the others have to be replaced by your own measurements/margin. I hope this formula gives reasonable value for human power in most cases. I did not tested it.
To try to be clear, I will use dummy values for different measurements of the ADC torque sensor
- ADC when right pedal is horizontal (and pointing to the front) with no weight : 170
- ADC min over 360° pedal rotation with no weight : 165
- ADC max over 360° pedal rotation with no weight : 190
- ADC with max weight (80 kg) on the right pedal (horizontal) : 450
- ADC when right pedal is horizontal and weight is is e.g. 24 kg (can be another weight in range 20/25 kg) : 300
There are 3 values to fill in 860C or javaconfigurator.
- torque ADC offset = max value of ADC with no weight + some margin (e.g. 10). So 190 +10 = 200
- torque ADC max = ADC value for max weight = 450.
- torque ADC step = 24 * 167 / ((300 - 165 -10) * 160 / (450-190 -10 )) ; Here 167 and 160 are just fixed values; the others have to be replaced by your own measurements/margin. I hope this formula gives reasonable value for human power in most cases. I did not tested it.
Marginal success!! I made the cable, downloaded the firmware from the archive and the version on the ebikestuff site. I successfully backed up the original firmware and flashed the latest OSF. First hiccup with the ERR2 error on my EKD01 display. I flashed Katana123's firmware and same error. I flashed back to the original and works as bad as it has always been. Then I flashed the ebikestuff firmware and no error. I rode around the block and it feels like the throttle works better, but I'd need to reflash to the original to make sure.
I have no idea how to change any settings/parameters, so more to learn. In other words, I have no idea what I'm doing, but still having fun tinkering with it. I've go the ebikestuff firmware loaded now, since it works, and will go for a little ride, then I'll do more research in tinkering when I get back. The most comforting thing so far is that I could flash to the original and not be any worse off lol.
If you want to use OSF please read carrefully the readme section. For vlcd5 (and similar display) you have also to flash another file that has to be generated by javaconfigurator.jar using your preference.
For javaconfigurator, use only the values related to TE (not TE1).
With no weight on the pedal it could be that the value is 194. There are huge variations depending on the motor (some users have a value around 150, others 200).
Please read carrefully the readme section.
E.G. if you use version 0.1.20 you have to look at the values for different positions of the pedal and should use the max value and add about 10 before filing pedal Torque ADC offset.
For ADC max, a value around 450 is "normal" (but again can vary from motor to motor and with pedal position)
I think I'm stuck. I have the Java runtime installed, and the SDCC compiler. Double clicking on the jar file doesn't launch the program, but just opens it like a zipped file. I wasn't sure if I needed to install the ST Visual Programmer as well? Maybe I need to read the TSDZ2B OS thread for more context? I'd appreciate any hints. Thanks.
There is no need to install ST Visual Programmer.
I put on github a version V00_01_25 for 860C.
In this version, assistance is based on the moving average torque over one rotation.
Folder "files_to_flash" still has version V00_01_20 (for 860C) that uses the max of actual, max current rotation and max previous rotation to calculate the assistance to povide.
You can compare the 2 versions (taking care of my remarks in a previous post saying that to get the same assistance some parameters should be adapted due to the use of averages instead of max torque values).
In this version, assistance is based on the moving average torque over one rotation.
Folder "files_to_flash" still has version V00_01_20 (for 860C) that uses the max of actual, max current rotation and max previous rotation to calculate the assistance to povide.
You can compare the 2 versions (taking care of my remarks in a previous post saying that to get the same assistance some parameters should be adapted due to the use of averages instead of max torque values).
I also added now version V00_01_26 (for 860c).
This version uses the logic developped by katana1234 for VLCD5. I made minor changes in order to :
- optimize the code (less cpu cycle)
- apply the ponderation based on "normalized" torque (in order to avoid the impact of different torque range on some motor).
This version seems me good too (perhaps less for motors that would have a large difference between min and max torque value with no weight).
The repository on github contains now 3 versions:
- V00.01.20 that uses my ogic based on max torque per rotation
- V00.01.25 that uses mspider logic based on average per rotation
- V00.01.20 that uses katana logic based on average of 40 last torque (still torque with big difference with previous value having more priority to increase reactivity)
This version uses the logic developped by katana1234 for VLCD5. I made minor changes in order to :
- optimize the code (less cpu cycle)
- apply the ponderation based on "normalized" torque (in order to avoid the impact of different torque range on some motor).
This version seems me good too (perhaps less for motors that would have a large difference between min and max torque value with no weight).
The repository on github contains now 3 versions:
- V00.01.20 that uses my ogic based on max torque per rotation
- V00.01.25 that uses mspider logic based on average per rotation
- V00.01.20 that uses katana logic based on average of 40 last torque (still torque with big difference with previous value having more priority to increase reactivity)
Last edited:
katana1234
10 mW
Thanks for implementig the code.
The output will probably be a bit different from my version because you are applying the averaging code after applying the expo. This can heavily affect the factor.Also 2 notes:
- In my latest version i reduced the array to 35 to get a little big quicker response without noticable side effects
- When i was testing the "factor" thing it was really a try and error process. I've tried dozens of values until i was happy with the result. Now that the range in the modified algorithm changed, there is a good chance that these values have to be "real world" adjusted...
Sadly my derailleur broke yesterday, so i can not even test it
You are right.Thanks for implementig the code.
Also 2 notes:
- In my latest version i reduced the array to 35 to get a little big quicker response without noticable side effects
- When i was testing the "factor" thing it was really a try and error process. I've tried dozens of values until i was happy with the result. Now that the range in the modified algorithm changed, there is a good chance that these values have to be "real world" adjusted...
Sadly my derailleur broke yesterday, so i can not even test it
- When expo is set on the default value (e.g. 20 on 860c or 0 in javaconfigurator) the expo has no effect at all (result of the function is the same as input). I think nobody already make test with other values. I did not get any feedback yet.
- I expect that changing 40 to 35 do not have a big impact. In fact, to reduce cyclic effect, ideally it should varies with the cadence but this is difficult to achieve. When cadence is 60 (per min) , the function will be called 40 times per sec and so 40 is a logic value (at least when there are no big changes of torque between 2 successive values)
- about the "factor" I took your values and divided them by 2 to take care that "normalized" values are about twice lower than ADC values (normalized range is 160 and ADC range is about 300). I was still surprised that factor remains on 1 for nearly 40% of the range. I had expected it should be 2 for a lower difference because I did not expected high differences between 2 successive ADC at an interval of 25msec). Still I kept (nearly your values).
katana1234
10 mW
- Expo: I can give you my feedback on the expo: I really like it! I'm using a value of 5 to get a little less power at low "input" power. It really makes the overall power range more natural. Thanks for implementing this!
I wish OSF was designed to have configurable input to output ratios per level. But this should of course be addressed to the main OSF development...
- Factor: Yeah, i started with a lower and more linear distrubution of the factor values, but that just didn't work well. So i increased the "gap" between the low and hight torque inputs and the factor. And that really helped smoothen things out while still being super responsive.
I may need to start over. When I used the command line, it pauses for a second then spits out a bunch of errors pointing to what looks like lines in the code.
When you installed the files did you respect the folder structure that exist on github?
Are you on windows?
Perhaps, your system has an issue with the space in the name "other settings"
It does not allow the / inserted after other settings
katana1234
10 mW
usually, you simply download the whole GitHub repo, then double click the JavaConfigurator.jar and thats it.
The / is not allowed in a filename because it represents a subdirectory. I really think such issues should be moved to another thread...
The / is not allowed in a filename because it represents a subdirectory. I really think such issues should be moved to another thread...
