-
Hello ES! We could use some help to get us past the finish line on building the new knowledgebase for the forum.
Can you donate? Please see our fundraising page. Thank you!
TSDZ8 OSF (open source firmware)
- Thread starter mstrens
- Start date
I do not understand.
I just made a new compilation and uploaded on github under the name
OSF_TSDZ8_860C_SPIDER_3_V00_02.04_other_compilation.hex
Still I expect that it is the same content.
I do not understand. Here a link to a zip file with all files from OSF folder in my local repository (for test6_with_pll branch.
OSF_V00_02_04.zip
drive.google.com
There was a different file on your github than ...other compilation.
The Google Drive file and the original file are the same.
I don't know.
But it can be seen that your incorrect one and my incorrect one are initially the same, only yours is shorter.
The Google Drive file and the original file are the same.
I don't know.
But it can be seen that your incorrect one and my incorrect one are initially the same, only yours is shorter.
Last edited:
Solved:
I compiled the files from your One Drive.
The resulting file created on my computer is now the same as your ..other compilation file and the same as the original file.
Edited:
The problem is NOT (edited) somewhere in the source files on github.
We currently have knowledge of where the problem is.
I compiled the files from your One Drive.
The resulting file created on my computer is now the same as your ..other compilation file and the same as the original file.
Edited:
The problem is NOT (edited) somewhere in the source files on github.
We currently have knowledge of where the problem is.
Last edited:
Additional question:
To increase the available power of 2.04 I plan to make
parameter adjustments:
in the file ebike_app.c on line 2478
in the file main.h on lines 386 and 387
Will this be enough?
Edited:
Tested, is enough:
in the file ebike_app.c on line 2478
in the file main.h on lines 290, 292, 386 and 387 (387 and 388).
To increase the available power of 2.04 I plan to make
parameter adjustments:
in the file ebike_app.c on line 2478
in the file main.h on lines 386 and 387
Will this be enough?
Edited:
Tested, is enough:
in the file ebike_app.c on line 2478
in the file main.h on lines 290, 292, 386 and 387 (387 and 388).
Last edited:
I would have to check but you can already have a look at file checks_about_currents.txt (in doc folder).
So I probably found 1 possible difference between github (prinf) and Onedisk:
In 1 of the main.h files, line 80 (//#define DYNAMIC_LEAD_ANGLE) is commented out.
Now I think it's fixed there. Or not? Which is correct?
Attachments
Last edited:
Thanks for looking for the differences.
This line can't explain the differences in hex because this #define is not used any more (It was used in an #if in file main.c but now the #if is commented and so the parameter has no impact)
Yes, it does not affect the hex file.
P.S.
I deleted the post with the image comparing your two different files.
They were not comparable, one was for VLCD5, the other for 860C.
Last edited:
I’m currently testing the OSF_TSDZ8_860C_SPIDER_3_V00_02.04.hex firmware using the Hybrid assist mode, and I wanted to share some feedback.
Overall, the performance is great. The assistance is very predictable, and I can easily manage the power while climbing hills. Most importantly, I haven't encountered any overload errors—it just works reliably. The motor feels much better with this version.
I noticed one minor thing regarding the startup behavior:
When I try to take off quickly from a standstill on a low assist level, there is a slight "dead zone" or lag. I have to rotate the cranks a bit (a fraction of a turn) before the motor kicks in. It’s not a full rotation, but it's a noticeable gap in assistance. This is less apparent during a very calm/slow start, but still perceptible.
Aside from this initial lag at startup, the TSDZ8 is working really well now. Thanks for all the hard work on this!
Overall, the performance is great. The assistance is very predictable, and I can easily manage the power while climbing hills. Most importantly, I haven't encountered any overload errors—it just works reliably. The motor feels much better with this version.
I noticed one minor thing regarding the startup behavior:
When I try to take off quickly from a standstill on a low assist level, there is a slight "dead zone" or lag. I have to rotate the cranks a bit (a fraction of a turn) before the motor kicks in. It’s not a full rotation, but it's a noticeable gap in assistance. This is less apparent during a very calm/slow start, but still perceptible.
Aside from this initial lag at startup, the TSDZ8 is working really well now. Thanks for all the hard work on this!
Are you going to share your changes somewhere? Do you need to update the limits in the display firmware? Did you have to fix the overcurrent threshold to not show the error?
Last edited:
On Monday, I installed V00_02.04.hex software and put 90 km on it. I rode in power mode. Once, when pulling away from a traffic light in heavy gear (I didn't shift while stopping), I experienced a lag in the support – just as Marek described. Other than that, no complaints.
I assume this is not something introduced in 02.04, most likely this is how OSF works from the beginning. If you tried previous versions and it was better there please inform what was the version if you remember it.
Anyway I think you should check "Assist w/o pedal" option in "Torque sensor" section on your display. Once enabled it should give you support without waiting on cadence signals meaning right from the beginning based on torque sensor only and you can adjust how sensitive it'll be with help of "Torque ADC threshold", now I have there value 70 (but I have "Assiste w/o pedal" disabled as I don't like the feeling that motor is struggling to start from stand still
)@prinfI assume this is not something introduced in 02.04, most likely this is how OSF works from the beginning. If you tried previous versions and it was better there please inform what was the version if you remember it.
Anyway I think you should check "Assist w/o pedal" option in "Torque sensor" section on your display. Once enabled it should give you support without waiting on cadence signals meaning right from the beginning based on torque sensor only and you can adjust how sensitive it'll be with help of "Torque ADC threshold", now I have there value 70 (but I have "Assiste w/o pedal" disabled as I don't like the feeling that motor is struggling to start from stand still
please, can you write me the text from line 8, or at least the last 4 characters, in the file OSF_TSDZ8_860C_SPIDER_3_V00_02.04.hex ?
It should be :
:10106000FBDC7047287700100C00002044010020B2
(20B2).
In which version of Modustoolbox did you compile?
edit:
I mean the value created on your computer, not mstrens PC.
Last edited:
Just checked some of recently compiled firmware and it shows there
:10106000FBDC7047846C00100C0000204401002061
I compile on Linux and use ModbusToolbox v3.5. It requires additional efforts to create exactly the same environment to build firmware as mstrens has for example. But I don't see a need for that - if it's compiled then all good
Why are you trying to get a match? Different compiler version, different toolbox/libraries version etc can produce differences in builds but I don't think that there can be something that can affect how motor works.Excellent,Just checked some of recently compiled firmware and it shows there
:10106000FBDC7047846C00100C0000204401002061
I compile on Linux and use ModbusToolbox v3.5. It requires additional efforts to create exactly the same environment to build firmware as mstrens has for example. But I don't see a need for that - if it's compiled then all good
this is exactly what I wanted to hear from someone else.
That the created .hex file from the same project may not be the same every time.
I managed to create 3 different hex files.
Including the identical file from mstrens ( line 8: :10106000FBDC7047287700100C00002044010020B2).
Then:
:10106000FBDC7047D07A00100C0000204401002007 - this one is functional.
And finally:
:10106000FBDC7047147F00100C00002044010020BE - this one does not work for me, communication with the display does not take place.
The differences in the files start in line 8, so that's why I mention this line.
I found that the differences are caused by different versions of ModbusToolbox.
The hex version created by higher versions of ModusToolbox does not work for me. Since I was using Windows, I cannot rule out registry errors caused by using different versions.
I respectfully disagree.
While it can be functionally equivalent (do the same thing and use the same logic), it can produce different behavior at runtime, I've seen errors coming from different compiler versions or different optimization strategies that produced different machine code:
- race conditions,
- different interrupt timing,
- bugs due to aggressive optimization,
- volatile handling diffs,
- floating point calculation diffs,
- bugs due to different variable initialization,
etc.
While it can be functionally equivalent (do the same thing and use the same logic), it can produce different behavior at runtime, I've seen errors coming from different compiler versions or different optimization strategies that produced different machine code:
- race conditions,
- different interrupt timing,
- bugs due to aggressive optimization,
- volatile handling diffs,
- floating point calculation diffs,
- bugs due to different variable initialization,
etc.
That's the problem.
The feeling of driving can now be affected by the fact that you're always thinking about what you have installed.
You'll never be sure.
Edit:
@phobos:
What are the recompilation results for you?
PS
I really appreciate all your opinions and information.
Maybe even a private message.
Last edited:
On 02.04 I found one use case that often triggers an overcurrent error (which never happened on 01.35): when the climb is too steep and muddy and I have to get off the bike, I use the throttle as "walk assist" to push forward (which is a lot easier to keep holding than the remote button). It happened a bunch of times there. Oddly, one time the back wheel had so little traction that the display read 70km/h while I was barely making progress, and there it didn't trigger the problem.
LeoSuperMoin
New-ish here
I got the ekd01 and i want to test the osf firmware on my tsdz8. I already got the jlink and backed up the original firmware but i am not quite sure what the right configuration is for the motor with these 5 million differrent settings. I want to see how it is compared to the original firmware for riding but also for the uart communication with the display compared to the stock firmware since i am currently working on reverse engineering the ekd01 screen.
Similar threads
