TSDZ8 OSF (open source firmware)

[alioi11]

Currently, there no existing field that could be used for the ADC knee point. For sure this would be more user friendly if 860c firmware would be update but I can't do it. I also want to offer a solution for those that do not want to refleash the 860C

I completely understand if updating the display firmware is too much work. However, looking at the README documentation for the TSDZ8, I noticed that several fields are apparently not used at all for this motor.
For instance:
Pedal torque ADC step adv
Pedal torque ADC offset adjustment
Pedal torque ADC angle adj
Couldn't one of these fields, which according to your documentation have no function for the TSDZ8, be repurposed to enter the direct ADC value for the knee point (e.g., 397)?
In addition, the factor for the range above the knee point (to keep the curve linear there) would also need to be adjustable via one of these vacant fields. Overall, that would be much more intuitive than converting values through unrelated fields.

 

[mstrens]

Currently, there no existing field that could be used for the ADC knee point. For sure this would be more user friendly if 860c firmware would be update but I can't do it. I also want to offer a solution for those that do not want to refleash the 860C

I completely understand if updating the display firmware is too much work. However, looking at the README documentation for the TSDZ8, I noticed that several fields are apparently not used at all for this motor.
For instance:
Pedal torque ADC step adv
Pedal torque ADC offset adjustment
Pedal torque ADC angle adj
Couldn't one of these fields, which according to your documentation have no function for the TSDZ8, be repurposed to enter the direct ADC value for the knee point (e.g., 397)?
In addition, the factor for the range above the knee point (to keep the curve linear there) would also need to be adjustable via one of these vacant fields. Overall, that would be much more intuitive than converting values through unrelated fields.

All proposed fields are already used (e.g. for knee weight, max weight) or can't accept high values (e.g. range are 0...40) and so does not allow to get ADC values.

 

[mstrens]

I put on github a version for 860C in branch test7_linear_torque. The hex file has "V00.02.07" in the name.
I did not tested it (so there could be bugs).
It is supposed to get a better linear curve for torque sensor.
It uses a "knee" point between offset and max and so it uses 2 linear segments instead of 1.
So it requires more parameters and I had to misuse some existing fields on 860C display.

Take care that to use it you have to modify the setup of some parameters on the display in the torque sensor screen:
- coast brake adc must be filled with 50% of the weight applied to get torque ADC max. So for 70 kg, fill 35.
- calibration must be disabled
- torque ADC step must be filled with a fix value to get a realistic human power. This value should be the for all TSDZ8 but I do net know it (bry e.g range 30...70)
- torque ADC step adv is not used
- torque offset adj must be filled with the percentage of the ADC for the second segment: e.g. imagine ADC offset = 170, ADC knee = 390, ADC max = 420. Then it must be (420-390) / (420-170) = 30 / 250 = 12% and so fill 12.
-torque range adj it use to apply an exponential curve for motor assistance (does not change the human power). It must be 20 to keep a linear curve. Values other than 20 (in range 0...40) allow to get relatively more or less assistance for low weight and the opposite for high weight). Se readme section because this parameter existed already
- torque angle adj must be filled with 50% of the weight applied to get the torque ADC value for the "knee" point. So for 50 kg, fill 25.
- torque ADC offset is unchanged (ACD value with no weight + a margin -e.g.10- to avoid autostart)
-torque ADC max is unchanged (ADC value for the highest weight you applied)

Note: internally the torque sensor is normalize for a max weight = 80kg but the max weight you use for calibration can be slightly different. It means that if the max weight you used is not 80 kg, OSF will first interpolate/extrapolate the values you filled for ADC max based on the rate of the second segment. This allows to get an uniform way to calculate the human power based on the normalized torque sensor value and so to use the same value for torque ADC step used for human power calculation.

Edit: in a new version v00.02.08, torque range adj and torque angle adj have been inverted. Please look now at the v00.02.08 readme version

 

[alioi11]

I put on github a version for 860C in branch test7_linear_torque. The hex file has "V00.02.07" in the name.
I did not tested it (so there could be bugs).
It is supposed to get a better linear curve for torque sensor.
It uses a "knee" point between offset and max and so it uses 2 linear segments instead of 1.
So it requires more parameters and I had to misuse some existing fields on 860C display.

Take care that to use it you have to modify the setup of some parameters on the display in the torque sensor screen:
- coast brake adc must be filled with 50% of the weight applied to get torque ADC max. So for 70 kg, fill 35.
- calibration must be disabled
- torque ADC step must be filled with a fix value to get a realistic human power. This value should be the for all TSDZ8 but I do net know it (bry e.g range 30...70)
- torque ADC step adv is not used
- torque offset adj must be filled with the percentage of the ADC for the second segment: e.g. imagine ADC offset = 170, ADC knee = 390, ADC max = 420. Then it must be (420-390) / (420-170) = 30 / 250 = 12% and so fill 12.
-torque range adj it use to apply an exponential curve for motor assistance (does not change the human power). It must be 20 to keep a linear curve. Values other than 20 (in range 0...40) allow to get relatively more or less assistance for low weight and the opposite for high weight). Se readme section because this parameter existed already
- torque angle adj must be filled with 50% of the weight applied to get the torque ADC value for the "knee" point. So for 50 kg, fill 25.
- torque ADC offset is unchanged (ACD value with no weight + a margin -e.g.10- to avoid autostart)
-torque ADC max is unchanged (ADC value for the highest weight you applied)

Note: internally the torque sensor is normalize for a max weight = 80kg but the max weight you use for calibration can be slightly different. It means that if the max weight you used is not 80 kg, OSF will first interpolate/extrapolate the values you filled for ADC max based on the rate of the second segment. This allows to get an uniform way to calculate the human power based on the normalized torque sensor value and so to use the same value for torque ADC step used for human power calculation.

Thanks mstrens, I will test this firmware version in the near future and report back how it works with my setup!

 

[mstrens]

Thanks mstrens, I will test this firmware version in the near future and report back how it works with my setup!

Thanks.
In the mean time I will update the readme section. I forgot to say that as I reused coast brake adc value (for knee weight), it is not possible anymore to select the type of lead angle to display. It is hardcoded on 14 (correction based on Id).

 

[mstrens]

I just noticed a bug in the v00.02.07 version. I fixed it in a new version v00.02.08. I also made another change. I inverted the way fields torque range adj and torque angle adj are reused. In new version, torque range adj is used for knee weight and torque angle adj for exponential. This is a little less confusing. The readme section is now adapted. So please take care of the readme section instead of the post of yesterday.

 

[Will2]

... I forgot to say that as I reused coast brake adc value (for knee weight), it is not possible anymore to select the type of lead angle to display. It is hardcoded on 14 (correction based on Id).

This means for me that if I want to do any more testing, I still have to reinstall my current display firmware. I now have a default range of values in this field of 10-14.

 

[mstrens]

This means for me that if I want to do any more testing, I still have to reinstall my current display firmware. I now have a default range of values in this field of 10-14.

Indeed. Sory for this but I did not find a better solution.
If there was better field to use to select the type of lead angle to display, I would use it but I did not find one (that is part of the configuration frame sent by the display to the controler). So I hardcoded the type of lead angle with the value that seems me the more significant.
If you see an alternative (with original OSF display firmware) let me know.

 

[mstrens]

I found another bug. In V00.02.08, the display calculated the human power based on the torque including the exponential and the startup boost. This was OK in most cases but not always : when there was no expo (angle adj = 20) and after startup boost.

I made a new version V00.02.09 to fix this bug.
Now, on the display, in technical data, you should see:
- ADC torque sensor : this is the raw value from the sensor (to be used for calibration)
- ADC torque delta : this is the value after linearization and normalisation (range 0...160 for weight 0...80kg). It does not take care of exponential and startup boost. This is the value used to calculate human power by the display:
Human power = ADC torque delta * pedal_torque_per_10_bit_ADC_step_x100 * pedal_cadence) / 960.
- ADC torque boost : this is the value after correction for exponential and startup boost. It is used to calculate assistance (in all modes except cdadence mode)

 

[mstrens]

I think further on the best way to linearize the torque sensor curve. I have now folowing proposal (for 860C).
- user has to calibrate the torque sensor and takes folowing actions:
- go to the menu "Technical" on display and look at the values for "ADC torque sensor".
- without having a weight on the pedal, note the min and value (I call them here offset_min and offset_max
- having one pedal (e.g. right pedal) horizontal, apply different weights vertically (ideally in a range from 0 up to 80kg) and for each weight he notes the "ADC torque sensor" value
- if offset_min and offset_max are quite different (e.g; more than 10), repeat previous step for the othe pedal (e.g. left)
- makes a graphic with weight (horizontal axis) and torque (vertical axis).
- based on the graphic, determine 2 straight lines that best would fit the points (one for low values and one for high values). The low value line should start from the torque ADC values with no weight.
- note the ADC value for no weight
- note ADC value for 80 kg (if you did not make a measurement for 80Kg make an extrapolation/interpolation)
- note (weight, ADC value) of the intersection point of the 2 lines
- in 860C display "torque sensor" menu , fill some fields:
- Calibration disable (important!!)
- Torque adc offset = ADC value for no weight
- Torque adc max = ADC value for 80 kg
- weight on pedal = weight for intersection point
- torque adc on weight = ADC value for intersection point
- "ADC torque step calc" should now have changed (recalculated); copy this value in "Torque adc step". This will be used for human power calculation and assistance.
- change now the value in "Torque adc offset" with the average of offset_min and offset_max (so offset_min + offset_max) / 2
- fill "Torque offset adj" with ( (offset_max - offset_min) / 2) + 10 : (This will be used at each power on to check that the torque adc offset did not change significantly; 10 is a security margin to avoid false alarm for small drift). This is a security feature to avoid that motor when you do not apply a pressure on the pedal
- fill "Torque angle adj" with 20 to get linear assistance. Use a different value (0..40) if you want exponential response (more or less sensitivity for low pressure.

Note: in this version, there is no need anymore to "misuse" "Coast brake adc" and so it still can be used to select the type of lead angle to display.
I could also provide an xls to let the user easily draw the graphic and see the curve.

This solution seems me better than my previous proposal (version v00.02.09) and fit better with mbrusa firmware.


Please make comments/suggestions

 

[alioi11]

I think further on the best way to linearize the torque sensor curve. I have now folowing proposal (for 860C).
- user has to calibrate the torque sensor and takes folowing actions:
- go to the menu "Technical" on display and look at the values for "ADC torque sensor".
- without having a weight on the pedal, note the min and value (I call them here offset_min and offset_max
- having one pedal (e.g. right pedal) horizontal, apply different weights vertically (ideally in a range from 0 up to 80kg) and for each weight he notes the "ADC torque sensor" value
- if offset_min and offset_max are quite different (e.g; more than 10), repeat previous step for the othe pedal (e.g. left)
- makes a graphic with weight (horizontal axis) and torque (vertical axis).
- based on the graphic, determine 2 straight lines that best would fit the points (one for low values and one for high values). The low value line should start from the torque ADC values with no weight.
- note the ADC value for no weight
- note ADC value for 80 kg (if you did not make a measurement for 80Kg make an extrapolation/interpolation)
- note (weight, ADC value) of the intersection point of the 2 lines
- in 860C display "torque sensor" menu , fill some fields:
- Calibration disable (important!!)
- Torque adc offset = ADC value for no weight
- Torque adc max = ADC value for 80 kg
- weight on pedal = weight for intersection point
- torque adc on weight = ADC value for intersection point
- "ADC torque step calc" should now have changed (recalculated); copy this value in "Torque adc step". This will be used for human power calculation and assistance.
- change now the value in "Torque adc offset" with the average of offset_min and offset_max (so offset_min + offset_max) / 2
- fill "Torque offset adj" with ( (offset_max - offset_min) / 2) + 10 : (This will be used at each power on to check that the torque adc offset did not change significantly; 10 is a security margin to avoid false alarm for small drift). This is a security feature to avoid that motor when you do not apply a pressure on the pedal
- fill "Torque angle adj" with 20 to get linear assistance. Use a different value (0..40) if you want exponential response (more or less sensitivity for low pressure.

Note: in this version, there is no need anymore to "misuse" "Coast brake adc" and so it still can be used to select the type of lead angle to display.
I could also provide an xls to let the user easily draw the graphic and see the curve.

This solution seems me better than my previous proposal (version v00.02.09) and fit better with mbrusa firmware.


Please make comments/suggestions

This sounds great! Much more structured, and the Excel file would be a huge help. Really looking forward to this version!

 

[mstrens]

I prepared a sheet to calculate the parameters to fill torque sensor parameters on a 860C.
This sheet is based on my latest proposal in post #1460.
There is not (yet) code and hex version on github that matches this metod. I am still working on it.
The sheet is available on google at this link.

TSDZ8 - Calibration with 860C

docs.google.com

It is read only. To fill your data and see the result, make first a copy in google.

 

[mstrens]

I think further more and now I ask myself if there is really an interest to implement the linearization concept of torque sensor for TSDZ8 with 2 straigth line segments.
The measurements made by aloioi11 show that torque sensor was linear up to 50Kg.
If you are really interested by the value human power displayed, then it is indeed important but only when you push more than 50kg on the pedal. I expect it is only very exceptional with an electric bike. I could further add that modeling the torque curve with 2 straight lines segment is also only an approximation. I do not think that the human power calculated is very reliable because e.g. ADC torque value with no weight varies with pedal position, that ADC values are subjected to some drift...

I further think the user will not often notice a change in the way the assistance is provided because with a weight of 50 kg on the pedal and a level of assistance of 100 (in torque assist mode) (the max being 254) the current target is already 23A (= the max supported by TSDZ8). So , pressing more that 50kg does not increase further more the assistance (if level is set on 100). If level is set on more than 100, you reach the max current even at a weight lower than 50 (e.g. with 25 kg if level is set on 200).
So it is only for level assistance less than 100 and weight above 50 that the concept could change the assistance. This situation seems me exceptional.

Comments are welcome.

 

[01zorro1]

Hey everyone, hope someone can point me in the right direction. I'm stuck trying to get OSF working on a TSDZ8 with the stock VLCD5 display.

After flashing the TSDZ8 OSF build, the VLCD5 freezes on Error 01 at startup. If I turn it on while holding the light button, it shows 99, a brief Error 02, and then 16.8. Pressing the pedal raises the reading to 17-18 (so the torque sensor works fine hardware-wise), but it immediately drops back to Error 01, after couple of tweans on the java configurator, this even with the light on it doesnt seem to read anything tho.

I've already tried raising the ADC offset up to 250, turned off auto display data with lights on and tried rasing the offset even more, nothing seems to work.

Restoring the original stock .bin dump via J-Flash brings the motor back to 100% working condition without any errors. Is there a known issue with VLCD5 UART communication or startup checks on the TSDZ8 branch? Thanks!

 

[mstrens]

Hey everyone, hope someone can point me in the right direction. I'm stuck trying to get OSF working on a TSDZ8 with the stock VLCD5 display.

After flashing the TSDZ8 OSF build, the VLCD5 freezes on Error 01 at startup. If I turn it on while holding the light button, it shows 99, a brief Error 02, and then 16.8. Pressing the pedal raises the reading to 17-18 (so the torque sensor works fine hardware-wise), but it immediately drops back to Error 01, after couple of tweans on the java configurator, this even with the light on it doesnt seem to read anything tho.

I've already tried raising the ADC offset up to 250, turned off auto display data with lights on and tried rasing the offset even more, nothing seems to work.

Restoring the original stock .bin dump via J-Flash brings the motor back to 100% working condition without any errors. Is there a known issue with VLCD5 UART communication or startup checks on the TSDZ8 branch? Thanks!

E01 says that there is an overvoltage or an undervoltage. This is probably related to to a wrong setup of the battery parameters

 

[BlueSwordM]

So, what's the most efficient firmware for the TSDZ8? I believe it's the latest original firmware, correct?

Are there ways to apply current ramp up with the original firmware? Pushing full current during acceleration seems rather counterproductive to maximizing range, because it's somewhat better to push higher battery current at higher speeds to keep efficiency up.