TSDZ8 OSF (open source firmware)

[mstrens]

I forgot to say I saw two errors on VLCD5 display: 07 and 02.

In OSF,
Error 02 = error in torque sensor = torque sensor provides values that are out of normal range
Error 07 = battery over current.

On my controller I also get abnormal value for torque sensor. It does not mean that the sensor itself is defect. It is most likely the controller that is not able anymore to drive it properly.
I am afraid that you controller died.
The best way to be sure is to upload one of the original firmware.

 

[dameri]

My controller is not absolutely dead because it sends data to display. I can test it on the table with original software but I think I not much wiser after that.

I have now on my bike TSDZ2B again. I have to use my bike daily.

Thank you for the codes. Error 02 can explain why I didn't get good assist on torque mode.

 

[mstrens]

My controller is not absolutely dead because it sends data to display. I can test it on the table with original software but I think I not much wiser after that.

I have now on my bike TSDZ2B again. I have to use my bike daily.

Thank you for the codes. Error 02 can explain why I didn't get good assist on torque mode.

My controller is also not totally dead. It also communicate with the display. I can flash it and even let it run in debug mode to see which instruction are executed. Still some components are damaged.

I think the best you can do at this stage is indeed
- use the TSDZ2 on the bike
- test the motor with the original software on the table. At least you will know if the controller is still OK or not.

If you controller is still OK, it could be that my controller and the one from ebikestuff died due to misuse or uc_monitor but not due to another bug in OSF firmware.

if your controller is dead too, then misuse of uc_probe can't explain all cases and this is a main issue.

 

[dameri]

My controller is also not totally dead. It also communicate with the display. I can flash it and even let it run in debug mode to see which instruction are executed. Still some components are damaged.

I think the best you can do at this stage is indeed
- use the TSDZ2 on the bike
- test the motor with the original software on the table. At least you will know if the controller is still OK or not.

If you controller is still OK, it could be that my controller and the one from ebikestuff died due to misuse or uc_monitor but not due to another bug in OSF firmware.

if your controller is dead too, then misuse of uc_probe can't explain all cases and this is a main issue.

Yes, I try to test on the motor on the table today or tomorrow of original firmware and ebikestuffs firmware and see what happens. And I'm waiting new parts to coming from china.
I go for a ride on my bicycle.

 

[mstrens]

Here some info about the tests I did this morning with my defect controller.

I installed the original firmware and tried to run the motor. It did not worked. I unmounted the controller and put an oscilloscope on the 2 pins going to the torque sensor. I did not get the expected signal (I got a 5V signal at a few kz instead a short pulse of 20V for 2.5 usec every 20 usec). So there is a problem in the signal driving the torque sensor.

I reinstalled OSF.
I changed uc_probe_monitoring to be sure that it only read data from the controller but do not write to it (safety).
Except the torque sensor value, the other values seemed normal.

When I activated throttle for a second, I heard a noise from the motor. In fact even when I did not activated throttle, I heard also a very light noise from the motor. With throttle, it increases a lot. Still the current did not really increase.

Then I started rotating manually the pedal as I was in cadence assist mode and so torque sensor is normally discarded.

The motor starts running normally but still with the same noise as when I shortly activated the throttle.

So I suspected that the noise came from the torque sensor and I disconnected the 2 wires between controller and motor.
Then there noise stopped.
So, when torque sensor is connected, the noise was audible because the frequence that drive the torque sensor is lower that usual.

Conclusion:
All components of the controller are still OK except those generating signal to drive the torque sensor.
I do not have the schematic of the controller so I can't say exactly what is wrong.
I could understand that a bug stops the rotation of the magnetic flux and so increases a lot the current in the controller what damages the power transistor.
But I can't understand that the torque driver would be damaged by a bug in the firmware.

 

[dameri]

Here some info about the tests I did this morning with my defect controller.

I installed the original firmware and tried to run the motor. It did not worked. I unmounted the controller and put an oscilloscope on the 2 pins going to the torque sensor. I did not get the expected signal (I got a 5V signal at a few kz instead a short pulse of 20V for 2.5 usec every 20 usec). So there is a problem in the signal driving the torque sensor.

I reinstalled OSF.
I changed uc_probe_monitoring to be sure that it only read data from the controller but do not write to it (safety).
Except the torque sensor value, the other values seemed normal.

When I activated throttle for a second, I heard a noise from the motor. In fact even when I did not activated throttle, I heard also a very light noise from the motor. With throttle, it increases a lot. Still the current did not really increase.

Then I started rotating manually the pedal as I was in cadence assist mode and so torque sensor is normally discarded.

The motor starts running normally but still with the same noise as when I shortly activated the throttle.

So I suspected that the noise came from the torque sensor and I disconnected the 2 wires between controller and motor.
Then there noise stopped.
So, when torque sensor is connected, the noise was audible because the frequence that drive the torque sensor is lower that usual.

Conclusion:
All components of the controller are still OK except those generating signal to drive the torque sensor.
I do not have the schematic of the controller so I can't say exactly what is wrong.
I could understand that a bug stops the rotation of the magnetic flux and so increases a lot the current in the controller what damages the power transistor.
But I can't understand that the torque driver would be damaged by a bug in the firmware.

Interesting research. Is it possible to get schematics from Tongsheng or do they keep it secret.

 

[dameri]

Sorry to hear this.
It is strange that you do not get access to deeper parameters of vlcd5 display. Can you send me the last .ini and Hex files that were used/generated by the javaconfigurator.
Did you tried afterward to upload original firmware to see if controller is broken or not?

When I remembered that I had to update the java configurator, I lost my own settings. Besides I think you have other things to do than to examine my files.
I don't know how to get .ini files out of java configurator.

 

[jped277]

So mstrens, does this mean you think the OSF is safe to run on my tsdz8?

 

[mstrens]

So mstrens, does this mean you think the OSF is safe to run on my tsdz8?

I think it is better to wait.
Currently 2 testers destroyed a controller and perhaps a third one (not yet confirmed).
I my case, at this stage, I do not think that the issue is related to the firmware.
For the other I do not know because I have no enough details.
Anyway the current version of the firmware provides a bad feeling because the assistance increases/decreases at regular (short) intervals. When it will be solved, I will say it on this thread.

 

[katana1234]

@mstrens: Thank you so much for doing this great work!

I already started building a custom display for the tsdz8 last year, but i kind of abandoned the project because the firmware was still limited. But now that you did the hard work of porting osf we could think about a opening the gates to open-source displays as well.
That would bring os the benefit of 100% control from the display to the controller. We could bring all settings/options to the display because it is a touch amoled We could also think about a) adding additional messages that only the open source display can handle b) complete new message protocol for the open-source display.

Anyway, once there is a stable beta i will update my display to be compatible with your osf and publish the code...

Thank you so much!

A few images from last years implementation time, some values might not be accurate because i used them for debugging...

 

[mstrens]

@mstrens: Thank you so much for doing this great work!

I already started building a custom display for the tsdz8 last year, but i kind of abandoned the project because the firmware was still limited. But now that you did the hard work of porting osf we could think about a opening the gates to open-source displays as well.
That would bring os the benefit of 100% control from the display to the controller. We could bring all settings/options to the display because it is a touch amoled We could also think about a) adding additional messages that only the open source display can handle b) complete new message protocol for the open-source display.

Anyway, once there is a stable beta i will update my display to be compatible with your osf and publish the code...

Thank you so much!

A few images from last years implementation time, some values might not be accurate because i used them for debugging...
View attachment 367659View attachment 367658

Good to know your project.
Do you know that mbrusa supports 2 versions of OSF for TSDZ2. One for stock display can only display/change a few parameters. There is also a version to work with a 860C display upgraded with another firmware (also from mbrusa). This last one display much more data and allows to edit all configuration parameters.

I hope to migrate the 2 versions to TSDZ8 and I plan to keep compatibility with mbrusa developments.

 

[Atak_Snajpera]

@mstrens: Thank you so much for doing this great work!

I already started building a custom display for the tsdz8 last year, but i kind of abandoned the project because the firmware was still limited. But now that you did the hard work of porting osf we could think about a opening the gates to open-source displays as well.
That would bring os the benefit of 100% control from the display to the controller. We could bring all settings/options to the display because it is a touch amoled We could also think about a) adding additional messages that only the open source display can handle b) complete new message protocol for the open-source display.

Anyway, once there is a stable beta i will update my display to be compatible with your osf and publish the code...

Thank you so much!

A few images from last years implementation time, some values might not be accurate because i used them for debugging...
View attachment 367659View attachment 367658

What does Input torque value mean? Nm? Personally I would prefer watts. This should not be difficult to calculate if cadence value is already known.

Power (W) = Torque (Nm) * Cadence (RPM) * 0.1047

Also it would look better. On left you would have Human Power and on right Electric Power.

Why on battery icon there are two percent values? (75% and 74%). Could you also add more data like energy consumption (Trip and average consumption [Wh/km]).

 

[katana1234]

@mstrens: no i did not know about that.

@Atak_Snajpera: Thx for the input, but i only posted this to let mstresn know about this project. Details will shop up once uploaded to github.

 

[terragady]

@mstrens: Thank you so much for doing this great work!

I already started building a custom display for the tsdz8 last year, but i kind of abandoned the project because the firmware was still limited. But now that you did the hard work of porting osf we could think about a opening the gates to open-source displays as well.
That would bring os the benefit of 100% control from the display to the controller. We could bring all settings/options to the display because it is a touch amoled We could also think about a) adding additional messages that only the open source display can handle b) complete new message protocol for the open-source display.

Anyway, once there is a stable beta i will update my display to be compatible with your osf and publish the code...

Thank you so much!

A few images from last years implementation time, some values might not be accurate because i used them for debugging...

mstrens firmware is using original protocol for the display so nothing fancy. Also touch displays for bikes are not the most optimal solution I think? Especially if it is the only option to change settings and mods. Just imagine some rain, dirt, mud etc. Also pointing to display without physical feedback for your fingers.

 

[aae34]

Also touch displays for bikes are not the most optimal solution I think? Especially if it is the only option to change settings and mods.

Why not? Capacitive touch allows having actual GUI w/o coming up with convoluted menu-schemes to reach every param/setting while making adjustments easy thanks to virtual keyboard and/or sliders etc.. You do the setup on a sunny day, why would one worry about rain or mud for that?
The display has to cope with water anyway, so imo. nothing changes(as you can just as well still have physical buttons for changing assist or w/e).

 

[dameri]

I tested TSDZ8 on the table. I have 860C display which came with the motor. Walks assist and throttle works with original firmware. Also with VLCD5 display walk assist is working. I do not have throttle to VLCD5. Firmware from ebikestuff is working same way.

I tested also OSF wihth cadence mode and torque mode. Walk assist is working in both modes. OSF runs walk assist better.

So I cannot see any faults on the table.

 

[mstrens]

I tested TSDZ8 on the table. I have 860C display which came with the motor. Walks assist and throttle works with original firmware. Also with VLCD5 display walk assist is working. I do not have throttle to VLCD5. Firmware from ebikestuff is working same way.

I tested also OSF wihth cadence mode and torque mode. Walk assist is working in both modes. OSF runs walk assist better.

So I cannot see any faults on the table.

Thanks for the feedback.
2 other users that tested OSF report that when, mounted on a bike, the assistance was not regular (some fluctuations).
I hope last changes I did could help.
One user said he will check it to morrow with a home trainer (and some monitoring tools).

 

[CentauriDreams]

Thanks for the feedback.
2 other users that tested OSF report that when, mounted on a bike, the assistance was not regular (some fluctuations).
I hope last changes I did could help.
One user said he will check it to morrow with a home trainer (and some monitoring tools).

Hi @dameri and @mstrens On the table or with the bike suspended, it is difficult to impossible to estimate walk assist and also throttle. At least this is the case with original firmware: without load, apparently works ok, but on the road, on load, walk assist acts or weak or somehow with interruptions, like short steps. Very hard to unusable for pushing the bike uphill. Throttle also, starts too fast. If throttle starts slow can be used as walk assist, but it jumps too fast from start. Hope this helps.
Again, huge kudos for the great work.

 

[lokz]

About walk assist. I had the TSDZ8 with first FW version, where walk assist kicked like mule when turned on. It was set on maximum.
Later they fixed that, but now it gives almost no assistance at all.
Walk assist should run with low rotation and medium to maximum power. So it gives as much help as possible when you walk the bike up steep hill.
For me, walk assist is not even important when you walk on straight road. You can push the bike without assist on such road.

 

[dameri]

Thanks for the feedback.
2 other users that tested OSF report that when, mounted on a bike, the assistance was not regular (some fluctuations).
I hope last changes I did could help.
One user said he will check it to morrow with a home trainer (and some monitoring tools).

I noticed that too when I tried motor at bike.

 

[dameri]

About walk assist. I had the TSDZ8 with first FW version, where walk assist kicked like mule when turned on. It was set on maximum.
Later they fixed that, but now it gives almost no assistance at all.
Walk assist should run with low rotation and medium to maximum power. So it gives as much help as possible when you walk the bike up steep hill.
For me, walk assist is not even important when you walk on straight road. You can push the bike without assist on such road.

Walks assist is to me also not very important. But on the table it's only way among throttle to see if motor runs. And it's totally different when motor is on bike and you pedal.

 

[dameri]

Am I doing something wrong with uc_probe software? When I push run button it opens page with no information.

 

[prozyc]

my conclusions from version 11 hex with xh18, at the beginning it was not possible to upload any hex with parameter settings, I downloaded the latest version of java script tsdz2/8 mbrusy and with it everything works on hex11. I tried different settings (22A, 1200W, power mode) on default settings with acceleration 35 and dec 35, still big ripple (it seems to me as if there was too fast loss of power between while pedaling on flat terrain), I experimented with different acc dec and it works quite well (but not perfectly) on acc 50 dec90 (I will check other options, then conclusions after short tests). On my second amperometer on throttle it reaches 20A. Question for Mstrens, in java configurator I have set data display 1 to battery current(3), time to display 00, can I have a continuous view of the battery current (how to enable it) to compare the tsdz8 ammeter with mine??

 

[mstrens]

my conclusions from version 11 hex with xh18, at the beginning it was not possible to upload any hex with parameter settings, I downloaded the latest version of java script tsdz2/8 mbrusy and with it everything works on hex11. I tried different settings (22A, 1200W, power mode) on default settings with acceleration 35 and dec 35, still big ripple (it seems to me as if there was too fast loss of power between while pedaling on flat terrain), I experimented with different acc dec and it works quite well (but not perfectly) on acc 50 dec90 (I will check other options, then conclusions after short tests). On my second amperometer on throttle it reaches 20A. Question for Mstrens, in java configurator I have set data display 1 to battery current(3), time to display 00, can I have a continuous view of the battery current (how to enable it) to compare the tsdz8 ammeter with mine??

Fine that changing acceleration/deceleration reduces ripple. Yesterday I asked mbrusa why he proposed quite different values for different motor and battery voltages. I was waiting his answer. Apart changing those parameters I did not know anymore what I could do in the code of the firmware.


In therory (did not yet test it) once you defined a field for display 1 and set his delay on zero, the value should be displayed when you press on power (vlcd5) to set the light on. Still you have also to define the number of fields to display on light on (should be at least 1).
I do not know if displaying this value will be really helpfull. In fact OSF sent the display data in a field that is supposed to contains a time interval between two speed sensor signal. It is then the VLCD5 that convert the time is speed. OSF has to deal with that and so it converts the value to display in a 'pseudo' time to get the expected value on the display. The issue is that VLCD5 does not directly display the value received from the controller but it applies some filtering on it. So it can take some time before the displayed value stabilizes. To be tested.

 

[mstrens]

Am I doing something wrong with uc_probe software? When I push run button it opens page with no information.

View attachment 367888

before you press "run" button, do you have something on the display when you are on design tab?
On my PC I have more info on screen (in the upper/left parts). I think you get them pressing on the third icon (top) and also using the small vertical arrows (at the right and below the uc/Probe title.