TSDZ8 OSF (open source firmware)

[lokz]

With VLCD5 you can use the version from this link :

GitHub - mstrens/OSF at test6_with_pll

Contribute to mstrens/OSF development by creating an account on GitHub.

github.com

I see this is your fork on Github. Well done!
It says it is in Beta. Are we sure it will work correctly?

What is the difference with this forum version?
And, is there a thread about it so I can read what people say?

 

[mstrens]

I see this is your fork on Github. Well done!
It says it is in Beta. Are we sure it will work correctly?

What is the difference with this forum version?
And, is there a thread about it so I can read what people say?

This branch (test with pll) contains the latest changes I made. As far I know, it works well. It is discussed in this thread. When I have time, I will merge this branch into main branch.
The way the motor is controlled for VLCD5 is the same as in the 860C version. You can probably see more comments about the 860C version in this thread because it is easier to configure.
With VLCD5 you have to use the java configurator.

 

[lokz]

This branch (test with pll) contains the latest changes I made. As far I know, it works well. It is discussed in this thread. When I have time, I will merge this branch into main branch.
The way the motor is controlled for VLCD5 is the same as in the 860C version. You can probably see more comments about the 860C version in this thread because it is easier to configure.
With VLCD5 you have to use the java configurator.

Thank you. Tell me, is some default set of options and power levels available somewhere? As a config file or written tutorial?

 

[mstrens]

Thank you. Tell me, is some default set of options and power levels available somewhere? As a config file or written tutorial?

The configurations files provided on github are probably not the best one. I think best is to ask on this forum. Please note that some set up have to be adapted based on your motor, your battery and your preferences. It is e.g. important to set up the right values for the torque sensor. Read carefully the Readme section and the related links.

 

[Samba26]

With OSF for TSDZ8 you can use the motor with a 36V battery. I did it for a bike trip of 1000 km.
Still you will not get the same maximum power as with a 48V battery and the maximum cadence (with assistance) will also be less.

Hi there! I have a similar question. I currently have 36 V batteries and a TSDZ8 motor with an EKD‑01 display. If I run it at 500 W peak power, the current will be about 14 A, which is safe for the battery, and I don’t need more power. Is this power level safe for the motor? Also, can I change all necessary parameters using only a PC, without the 860C display?

 

[mstrens]

Hi there! I have a similar question. I currently have 36 V batteries and a TSDZ8 motor with an EKD‑01 display. If I run it at 500 W peak power, the current will be about 14 A, which is safe for the battery, and I don’t need more power. Is this power level safe for the motor? Also, can I change all necessary parameters using only a PC, without the 860C display?

14A is not an issue for tSDZ8. I think that original firmware goes up to 23A with a 48V battery. You can change all parameters using only a PC (with the provided java configurator)

 

[LeoSuperMoin]

14A is not an issue for tSDZ8. I think that original firmware goes up to 23A with a 48V battery. You can change all parameters using only a PC (with the provided java configurator)

23A on throttle but goes to 24A peaks with pas.
although got more heat with 16A on OSF than stock firmware at 24A

 

[mstrens]

although got more heat with 16A on OSF than stock firmware at 24A

Is this also the case with the version in the branch test6_with_pll. I expect efficiency should be better with this branch.

 

[maccoa50]

Hello everyone
I'm considering buying a tsdz8 to replace my BBS02B (I would like to try the torque sensor). but I have a few questions.
is it possible to have 2 maps restricted and unrestricted?
I use a Garmin Edge Explore 2 and I understood that we could integrate the data from the TSDZ8, is this feasible?

I am really satisfied with the bbs02B with the firmware danielnielsson9 and personal settings. Is the game worth it?

 

[01zorro1]

can anyone confirm if the DFL11 is a compatible display? and if it is, what file should i use? dont wanna accidentaly brick my motor

 

[mp75]

Good morning,
I would like to load the OSF firmware onto a 750W TSDZ8 with the stock 860C display for a road test.

I used this VLC5 firmware as suggested by Ebikestufff GitHub - mstrens/OSF

I am encountering error "02h" after flashing the .hex file generated via the Java configurator with the "calibrated" and "torque sensor adv" options enabled.
If I uncheck those boxes, I get no errors, but I also get no motor assistance.
With "torque sensor adv" enabled, the assistance is weak and cuts out, and there is noise coming from the motor while pedaling (I turned it off immediately).

Can anyone help by suggesting torque sensor values or providing an .ini file?

I just want to test the firmware; if I like it, I’ll buy an 860C with the firmware already installed.

Thanks.

NOTE: edit after 2 hours of upload and test on java configurator.... with this INI (or jpg) I don't have errors, but no assistance pedaling

 

[klimastech]

Someone update firmware in sw102 to v20.1c.5 update 2 ? I have problem after update i cant change some settings (speed, power... etc.)

Password enabled is Yes and cant change to No.

 

[mbrusa]

Here's a post about it in the TSDZ2 thread.
TSDZ2 OSF for all displays, VLCD5-VLCD6-XH18, LCD3, 860C-850C-SW102.
You can find details in the 860C manual.

 

[amdv]

Someone update firmware in sw102 to v20.1c.5 update 2 ? I have problem after update i cant change some settings (speed, power... etc.)

Password enabled is Yes and cant change to No.

I also installed version 20.1c.5 update 2 on the sw102, but after installing it, the motor starts by itself without moving the pedals. I tried changing the parameters, but it wouldn't let me change anything. So I uninstalled and reinstalled the previous version and everything works

 

[mstrens]

The Tongsheng torque sensor provides a value that is nearly proportional to the weight on the pedal when the weight remains lower than a limit. Above this limit, it saturates and the returned values increase much less quickly when weights increase more.
Tests done with a TSDZ2 showed a limit of 15, 25 or 45 kg depending on the motor.
For TSDZ8, I have found only one test. It gives a limit at 50 kg (where ADC value is about 90% of the max range - for 80kg).
Probably that for TSDZ8 too, the limits varies significantly from motor to motor.

In TSDZ8, the assistance (in all modes except cadence mode) is currently proportional to the ADC torque value (in fact ADC torque value is first filtered, offset is substacted and range is adjusted to a conventional value). Due to the saturation of the ADC/weight curve, this means that the assistance is relatively high for low weight on the pedal and low for high weight. This has an impact also on the calculated human power (non linearity).

The way OSF for TSDZ2 tries to compensate this seems me very complex and not ideal. It was also not implemented in TSDZ8.

I could make changes for TSDZ8 in order to take care in a better (I think) way of the "saturation point" and so to better "linearize" the torque sensor (and get better human power calculation).

For stock display (VLCD5 and similar) version, I could change the configurator in order to let the user defines:
- ADC offset (no weight) (e.g160 )(this field already exists)
- ADC max (max weight) (e.g.430) (this field already exists) and weight used to get ADC max (e.g. 80 kg) (new field)
- ADC at saturation (e.g. 390) and weight to get it (e.g. 50kg) (2 new fields)

Then I would remove other fields:
- torque sensor adv box
- calibrated box
- estimated box
- pedal torque ADC step
- pedal torque ADC step advanced
- pedal torque ADC offset adjustment
- pedal torque ADC range adjustment
- pedal torque ADC angle adjustment

I also suggest :
- to let the user decides if OSF must automatically calibrate the ADC offset at each power on or not. To do so, I would consider that if ADC offset value in javaconfigurator is less than 50, it represents a security margin being internally added to the automatic offset (to avoid that motor starts in some cases). When the value would be above 50, OSF will discard the automatic calibration value and use the configurator value (considering that the user already included a margin). This second option can be useful for motor having an ADC offset that significantly changes depending on the pedal position (but can gives Err 02 if the value is set to low compared to the the automatic calibration value).
- to let the user select if the curve ADC versus weight must remain linear or if it must be more or less difformed in concave or convex way (in order to get relatively more or less assistance at low weight. This requires just one more parameter (already present).

Similar options could be done also for 860C version but in order to avoid having to reflash the display, I would then "misuse" some existing display field and so some field labeling would be incorrect but this could be explained in the Readme doc.

I wait for your comments before making changes.
Thanks for advises.

 

[dameri]

The Tongsheng torque sensor provides a value that is nearly proportional to the weight on the pedal when the weight remains lower than a limit. Above this limit, it saturates and the returned values increase much less quickly when weights increase more.
Tests done with a TSDZ2 showed a limit of 15, 25 or 45 kg depending on the motor.
For TSDZ8, I have found only one test. It gives a limit at 50 kg (where ADC value is about 90% of the max range - for 80kg).
Probably that for TSDZ8 too, the limits varies significantly from motor to motor.

In TSDZ8, the assistance (in all modes except cadence mode) is currently proportional to the ADC torque value (in fact ADC torque value is first filtered, offset is substacted and range is adjusted to a conventional value). Due to the saturation of the ADC/weight curve, this means that the assistance is relatively high for low weight on the pedal and low for high weight. This has an impact also on the calculated human power (non linearity).

The way OSF for TSDZ2 tries to compensate this seems me very complex and not ideal. It was also not implemented in TSDZ8.

I could make changes for TSDZ8 in order to take care in a better (I think) way of the "saturation point" and so to better "linearize" the torque sensor (and get better human power calculation).

For stock display (VLCD5 and similar) version, I could change the configurator in order to let the user defines:
- ADC offset (no weight) (e.g160 )(this field already exists)
- ADC max (max weight) (e.g.430) (this field already exists) and weight used to get ADC max (e.g. 80 kg) (new field)
- ADC at saturation (e.g. 390) and weight to get it (e.g. 50kg) (2 new fields)

Then I would remove other fields:
- torque sensor adv box
- calibrated box
- estimated box
- pedal torque ADC step
- pedal torque ADC step advanced
- pedal torque ADC offset adjustment
- pedal torque ADC range adjustment
- pedal torque ADC angle adjustment

I also suggest :
- to let the user decides if OSF must automatically calibrate the ADC offset at each power on or not. To do so, I would consider that if ADC offset value in javaconfigurator is less than 50, it represents a security margin being internally added to the automatic offset (to avoid that motor starts in some cases). When the value would be above 50, OSF will discard the automatic calibration value and use the configurator value (considering that the user already included a margin). This second option can be useful for motor having an ADC offset that significantly changes depending on the pedal position (but can gives Err 02 if the value is set to low compared to the the automatic calibration value).
- to let the user select if the curve ADC versus weight must remain linear or if it must be more or less difformed in concave or convex way (in order to get relatively more or less assistance at low weight. This requires just one more parameter (already present).

Similar options could be done also for 860C version but in order to avoid having to reflash the display, I would then "misuse" some existing display field and so some field labeling would be incorrect but this could be explained in the Readme doc.

I wait for your comments before making changes.
Thanks for advises.

Is it possible to renew 860C display fields and rename them correct.

 

[alioi11]

The Tongsheng torque sensor provides a value that is nearly proportional to the weight on the pedal when the weight remains lower than a limit. Above this limit, it saturates and the returned values increase much less quickly when weights increase more.
Tests done with a TSDZ2 showed a limit of 15, 25 or 45 kg depending on the motor.
For TSDZ8, I have found only one test. It gives a limit at 50 kg (where ADC value is about 90% of the max range - for 80kg).
Probably that for TSDZ8 too, the limits varies significantly from motor to motor.

In TSDZ8, the assistance (in all modes except cadence mode) is currently proportional to the ADC torque value (in fact ADC torque value is first filtered, offset is substacted and range is adjusted to a conventional value). Due to the saturation of the ADC/weight curve, this means that the assistance is relatively high for low weight on the pedal and low for high weight. This has an impact also on the calculated human power (non linearity).

The way OSF for TSDZ2 tries to compensate this seems me very complex and not ideal. It was also not implemented in TSDZ8.

I could make changes for TSDZ8 in order to take care in a better (I think) way of the "saturation point" and so to better "linearize" the torque sensor (and get better human power calculation).

For stock display (VLCD5 and similar) version, I could change the configurator in order to let the user defines:
- ADC offset (no weight) (e.g160 )(this field already exists)
- ADC max (max weight) (e.g.430) (this field already exists) and weight used to get ADC max (e.g. 80 kg) (new field)
- ADC at saturation (e.g. 390) and weight to get it (e.g. 50kg) (2 new fields)

Then I would remove other fields:
- torque sensor adv box
- calibrated box
- estimated box
- pedal torque ADC step
- pedal torque ADC step advanced
- pedal torque ADC offset adjustment
- pedal torque ADC range adjustment
- pedal torque ADC angle adjustment

I also suggest :
- to let the user decides if OSF must automatically calibrate the ADC offset at each power on or not. To do so, I would consider that if ADC offset value in javaconfigurator is less than 50, it represents a security margin being internally added to the automatic offset (to avoid that motor starts in some cases). When the value would be above 50, OSF will discard the automatic calibration value and use the configurator value (considering that the user already included a margin). This second option can be useful for motor having an ADC offset that significantly changes depending on the pedal position (but can gives Err 02 if the value is set to low compared to the the automatic calibration value).
- to let the user select if the curve ADC versus weight must remain linear or if it must be more or less difformed in concave or convex way (in order to get relatively more or less assistance at low weight. This requires just one more parameter (already present).

Similar options could be done also for 860C version but in order to avoid having to reflash the display, I would then "misuse" some existing display field and so some field labeling would be incorrect but this could be explained in the Readme doc.

I wait for your comments before making changes.
Thanks for advises.

Hi mstrens, that sounds like a great approach! If I understand correctly, this is exactly the approach I have been wishing for: making the variable parameters directly adjustable.
If these points could be flexibly set in the configurator or directly on the display (like with the 860C) – especially:
ADC offset (without weight)
ADC saturation point (including the corresponding weight, e.g., 50 kg)
Maximum ADC value (including the maximum weight, e.g., 80 kg)
And the factor for the range above the inflection point (knee), so that the curve continues in a clean, linear fashion from there
– that would be extremely helpful. This would perfectly compensate for the varying manufacturing tolerances of the individual motors without having to modify the code for each one. The option to then adjust the curve accordingly would round the whole thing off perfectly.

 

[mstrens]

Hi mstrens, that sounds like a great approach! If I understand correctly, this is exactly the approach I have been wishing for: making the variable parameters directly adjustable.
If these points could be flexibly set in the configurator or directly on the display (like with the 860C) – especially:
ADC offset (without weight)
ADC saturation point (including the corresponding weight, e.g., 50 kg)
Maximum ADC value (including the maximum weight, e.g., 80 kg)
And the factor for the range above the inflection point (knee), so that the curve continues in a clean, linear fashion from there
– that would be extremely helpful. This would perfectly compensate for the varying manufacturing tolerances of the individual motors without having to modify the code for each one. The option to then adjust the curve accordingly would round the whole thing off perfectly.

Indeed, this is the same as your approach. Above the knee, it is possible to calculate using a linear curve or a parabolic curve (tangent at knee point and horizontal at max point). Probably that the linear curve is better because we are not sure that the sensor is totally saturated at the max weight used by the user.
The drawback of this proposal is that the user would always have to fill 5 values based on a calibration process. Still this seems me totally OK because we could recommend default values for those that do not want to calibrate their motor.

 

[alioi11]

Indeed, this is the same as your approach. Above the knee, it is possible to calculate using a linear curve or a parabolic curve (tangent at knee point and horizontal at max point). Probably that the linear curve is better because we are not sure that the sensor is totally saturated at the max weight used by the user.
The drawback of this proposal is that the user would always have to fill 5 values based on a calibration process. Still this seems me totally OK because we could recommend default values for those that do not want to calibrate their motor.

That makes me really glad to hear! I'm already looking forward to the firmware and testing it out.

 

[mstrens]

That makes me really glad to hear! I'm already looking forward to the firmware and testing it out.

I presume that you are using the 860C version. Currently I am first working on the VLCD5 version. Can you test the VLCD5 version?

 

[alioi11]

I presume that you are using the 860C version. Currently I am first working on the VLCD5 version. Can you test the VLCD5 version?

Yes, I would be happy to test it, but I only own and use 860C displays, so I can only test that version.

 

[mstrens]

Yes, I would be happy to test it, but I only own and use 860C displays, so I can only test that version.

I also have only the 860C display. I will try to implement it for this display first.

Still, at this stage, I want to avoid having to make changes to the 860C display firmware.
I expect it is possible only if :
- the field "Coast brake ADC" is reused to enter the weight (in kg) / 2 related to ADC max (so e.g. filling 40 when max weight is 80 kg) (value between 5 and 50)
- the field "Torque angle adj" is reused to enter the weight (in kg) / 2 related to knee point (e.g. filling 25 when knee weight is 50kg) (value between 0 and 40)
- the field "Torque offset adv" is reused to enter the % the knee ADC is below the max. (e.g. when ADC offset=170, ADC max =420 and ADC knee=390, the value to fill would be (420-390)/(420-170) = 30/250= 0.12 = 12; so value to fill would be 12) (value between 0 and 34)
- "Torque ADC offset" and "Torque ADC max" as used as currently.

Note: the field "Torque angle adj" would be use (it is already the case for TSDZ8) for exponential correction on assitance but not for human power calculation.
The human power calculation is done in the display firmware itself based as "Torque ADC step" (set on display) multiplied by the cadence and the ADC torque delta provided by the controler. This ADC torque delta would be the ADC torque raw value corrected by the offset, the linearization code and normalized in such a way that the value 160 match a weight of 80 kg.
So, the box "Calibration" should be set on disable and the "Torque ADC step" should be filled with a specific value (fix value calculated in order to get the right human power when ADC torque delta = 160 match a weight of 80kg).

Do you have any comment?

 

[Will2]

Please also think about an alternative text editing on the 860C display. It's not that big of a problem. I'm already using the changed text in one case. Also with a changed range of values for input. Of course also with changed limits for the motor.

 

[alioi11]

I also have only the 860C display. I will try to implement it for this display first.

Still, at this stage, I want to avoid having to make changes to the 860C display firmware.
I expect it is possible only if :
- the field "Coast brake ADC" is reused to enter the weight (in kg) / 2 related to ADC max (so e.g. filling 40 when max weight is 80 kg) (value between 5 and 50)
- the field "Torque angle adj" is reused to enter the weight (in kg) / 2 related to knee point (e.g. filling 25 when knee weight is 50kg) (value between 0 and 40)
- the field "Torque offset adv" is reused to enter the % the knee ADC is below the max. (e.g. when ADC offset=170, ADC max =420 and ADC knee=390, the value to fill would be (420-390)/(420-170) = 30/250= 0.12 = 12; so value to fill would be 12) (value between 0 and 34)
- "Torque ADC offset" and "Torque ADC max" as used as currently.

Note: the field "Torque angle adj" would be use (it is already the case for TSDZ8) for exponential correction on assitance but not for human power calculation.
The human power calculation is done in the display firmware itself based as "Torque ADC step" (set on display) multiplied by the cadence and the ADC torque delta provided by the controler. This ADC torque delta would be the ADC torque raw value corrected by the offset, the linearization code and normalized in such a way that the value 160 match a weight of 80 kg.
So, the box "Calibration" should be set on disable and the "Torque ADC step" should be filled with a specific value (fix value calculated in order to get the right human power when ADC torque delta = 160 match a weight of 80kg).

Do you have any comment?

That all sounds very good and is a clever solution for the 860C display!
However, I think it would be better to be able to directly enter the actual ADC value of the knee point (for example, 397). This avoids any artificial conversion or division, and the firmware works directly with the exact raw values delivered by the sensor.
By the way: Even though reusing existing fields is a neat workaround, having a dedicated display firmware with the correct and proper menu names in the long run would be absolutely fantastic and much easier to work with!

 

[mstrens]

That all sounds very good and is a clever solution for the 860C display!
However, I think it would be better to be able to directly enter the actual ADC value of the knee point (for example, 397). This avoids any artificial conversion or division, and the firmware works directly with the exact raw values delivered by the sensor.
By the way: Even though reusing existing fields is a neat workaround, having a dedicated display firmware with the correct and proper menu names in the long run would be absolutely fantastic and much easier to work with!

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