Indeed: you can reflash the original one (if you first save it) or you can flash one of the versions that you can find on facebook or ebikstuff web site.
TSDZ8 OSF (open source firmware)
- Thread starter mstrens
- Start date
This is not the first time something like this has happened to me, it was similar sometimes on older versions of hex but I thought it was just something wrong with my tsdz8. To answer your questions, after restarting (also after taking out the battery and restarting) when the revs start to fluctuate once, it does not return to smooth assist. The day before yesterday when I tested with Foc14 (although I think this parameter has no influence) the error did not appear, yesterday I uploaded the same settings with Foc30 and yesterday the bike worked great (I also turned it on and off) but this morning after switching it on there are fluctuations and jerking. It helps to re-upload software with my hex, I do not have to change main.hex I am also wondering whether not to try to read the controller software after the error and compare it in the gpt chat with that before the error appeared, what do you think
Mstrens??
Last edited:
It is not clear for me what you mean with "I do not have to change main.hex".
The firmware uses 3 memory aeras:
-1 the program it self
-2 the hex file generated by the configurator
-3 some parameters that can be modified on the display and can be saved.
If the only way to solve the issue is to reflash 1 or 2, it should indeed be a good help to read the flash memory in the controller before and after the error and look at the differences. Please note that to do so, you should read the whole flash memory (so the 64k) and not only part of it. For info, the program is in the lower part and the rest in the upper part of the memory.
katana1234
100 µW
@mstrens i was looking into the code a bit just to get a small understanding of how it works and what to expect. One thing i noticed is the lack of an additional uart tx message.
My tsdz8 (in combination with a EKD01) is not only sending the 0x43 message to the controller, but also a 0x46 message containing the pedal torque in an unknown unit and the power in watts x 20.
Here's the part of my code handling the values:
I came across this when i reverse engineered the display when i made my own.
Other than that the message looked pretty much empty, i remember all other bytes being 0. The message itself had a length of 15 bytes including the checksum.
Maybe i can help out here to implement the missing message for the EDK01 display.
I will flash OSF soon and start working on the code...
My tsdz8 (in combination with a EKD01) is not only sending the 0x43 message to the controller, but also a 0x46 message containing the pedal torque in an unknown unit and the power in watts x 20.
Here's the part of my code handling the values:
I came across this when i reverse engineered the display when i made my own.
Other than that the message looked pretty much empty, i remember all other bytes being 0. The message itself had a length of 15 bytes including the checksum.
Maybe i can help out here to implement the missing message for the EDK01 display.
I will flash OSF soon and start working on the code...
Last edited:
Thanks for the info.
I suggest that you communicate this info also to mbrusa who developped the original code for TSDZ2 (and that I reused).
So, it would also be possible to get more data on EKD01 for TSDZ2
Some time ago I prepared a version of OSF for TSDZ8 with a 860C display (using version 0.20.1c-5.1 from mbrusa).
This version did not worked and I was waiting a working version for VLCD5 before solving the bugs.
I just worked again on this OSF 860C version and I tried to include what I made for the VLCD5 V0.1.13 version.
This version seems to work (I made only basic tests on a table).
This TSDZ8 860c version is available here : GitHub - mstrens/OSF_860C.
You can find more info on TSDZ2 version mbrusa site (to know how to use the display and the config parameters) at: TSDZ2-Smart-EBike-860C/README.md at master · emmebrusa/TSDZ2-Smart-EBike-860C
Please note that it requires a 860C version upgraded with the mbrusa firmware for this display (version 0.20.1c-5.1).
This version did not worked and I was waiting a working version for VLCD5 before solving the bugs.
I just worked again on this OSF 860C version and I tried to include what I made for the VLCD5 V0.1.13 version.
This version seems to work (I made only basic tests on a table).
This TSDZ8 860c version is available here : GitHub - mstrens/OSF_860C.
You can find more info on TSDZ2 version mbrusa site (to know how to use the display and the config parameters) at: TSDZ2-Smart-EBike-860C/README.md at master · emmebrusa/TSDZ2-Smart-EBike-860C
Please note that it requires a 860C version upgraded with the mbrusa firmware for this display (version 0.20.1c-5.1).
I mean that I just need to reload hex file generated by the configurator. I will try to compare the code after uploading the software when there is no error and after the error appears and let you know if I find anything.
Thank you.
ebikestuff.eu
100 mW
@katana1234
I have a document for the TSDZ controller/display protocol. The EN version is translated using DeepL.
Regarding the OSF testing, the assistance is way smoother after calibrating the torque sensor to the 160-450 range and changing the motor deceleration to 80. However, I didn't have time to test it thoroughly. I only did two short rides.
I don't know if @mstrens mentioned that, but when I checked the torque sensor readings on my unit, the values for no-load and max load were 160 and 450. The TSDZ2 has a default range of 150-300. The OSF uses that range by default. This might also cause the motor assistance to be too sensitive.
It would be good if someone could check this on their unit. To do that, you have to set the displayed data 1 to "adc torque sensor 10b". Set "Number of data displayed at lights on" to 1. And set "Time to displayed data 1 (0.1s)" to 255 in the "Advanced settings" tab. Please also check that "Auto display data with lights on" is enabled in the "Basic settings" tab.
When the config is flashed, power up the display. Turn on the lights (click the power button on VLCD5 or hold the + button on 860C, EKD01). Read the value. In my case, it was 16. Position the right crank arm horizontally to the ground and step on the right pedal with your whole body mass to see the max value. In my case, it was 45.
@mstrens
Regarding the 860C version. That's great news! Thank you. It should make the testing process way easier. You can change settings right from the display without flashing the config files.
I have a document for the TSDZ controller/display protocol. The EN version is translated using DeepL.
Regarding the OSF testing, the assistance is way smoother after calibrating the torque sensor to the 160-450 range and changing the motor deceleration to 80. However, I didn't have time to test it thoroughly. I only did two short rides.
I don't know if @mstrens mentioned that, but when I checked the torque sensor readings on my unit, the values for no-load and max load were 160 and 450. The TSDZ2 has a default range of 150-300. The OSF uses that range by default. This might also cause the motor assistance to be too sensitive.
It would be good if someone could check this on their unit. To do that, you have to set the displayed data 1 to "adc torque sensor 10b". Set "Number of data displayed at lights on" to 1. And set "Time to displayed data 1 (0.1s)" to 255 in the "Advanced settings" tab. Please also check that "Auto display data with lights on" is enabled in the "Basic settings" tab.
When the config is flashed, power up the display. Turn on the lights (click the power button on VLCD5 or hold the + button on 860C, EKD01). Read the value. In my case, it was 16. Position the right crank arm horizontally to the ground and step on the right pedal with your whole body mass to see the max value. In my case, it was 45.
@mstrens
Regarding the 860C version. That's great news! Thank you. It should make the testing process way easier. You can change settings right from the display without flashing the config files.
Attachments
katana1234
100 µW
I've been testing all settings up and down but no matter what i do it is absolutely jerky in power mode.
When using the throttle it is running perfeclty smooth!
Is there anything i can test for you guys?
When using the throttle it is running perfeclty smooth!
Is there anything i can test for you guys?
Perhaps you can try to change some settings in the javaconfigurator (for VLCD5 version). It seems that max torque value for TSDZ8 is around 450 instead of 300. It seems also that increasing the value of deceleration up to 80 or 90 also help.
Some other users could perhaps share here their settings.
katana1234
100 µW
@mstrens I am not sure what exactly you did to port osf to the tsdz8. So i don't know about the differences to the tsdz2. And i have absolutely no knowledge in the whole project so far. Right now i am diving into the code to understand how it works.
I did not find any multisampling or averaging over time of the torque sensor in the code. Can you confirm this?
My current hypothesis is, that the torque sensors of the tsdz8 and tsdz2 electromechanical behave differently. I assume that the "old" sensor took a few hundred ms to read its real value whereas the "new" sensor is way faster and nearly immediately reads the real value.
I just checked the "adc torque sensor 10b" data on my tsdz8 and it is kinda instantly changing when appying force.
The funny thing is that running the original firmware and reading out the torque value from the 0x46 messages it easily takes 3-5 seconds to go back to zero after hitting the pedals really hard. So i assume, tonghsheng added some sensor multisampling here...
I will setup my dev env now...
Edit: I proofed myself wrong. I added a 1s averaging to the torque sensor but it is still jerky. But it helped a little bit...
I did not find any multisampling or averaging over time of the torque sensor in the code. Can you confirm this?
My current hypothesis is, that the torque sensors of the tsdz8 and tsdz2 electromechanical behave differently. I assume that the "old" sensor took a few hundred ms to read its real value whereas the "new" sensor is way faster and nearly immediately reads the real value.
I just checked the "adc torque sensor 10b" data on my tsdz8 and it is kinda instantly changing when appying force.
The funny thing is that running the original firmware and reading out the torque value from the 0x46 messages it easily takes 3-5 seconds to go back to zero after hitting the pedals really hard. So i assume, tonghsheng added some sensor multisampling here...
I will setup my dev env now...
Edit: I proofed myself wrong. I added a 1s averaging to the torque sensor but it is still jerky. But it helped a little bit...
Last edited:
I made 72 km trip today. Last 40 km I rode 2.53 gear ratio (38 teeth chain ring and 15 teeth cog) and speed was 25 – 30 km/h. firmware worked very very well. Motor was working very smoothly. No jerking at all.
I made little changes to yesterdays configs. Set amps from 16 to 20, and increased max power to 1000 watts and rode on torque mode. I didn’t notice big difference on motor behavior. Assist values are too high on turbo level. Assist do not get any better from sport level.
I made little changes to yesterdays configs. Set amps from 16 to 20, and increased max power to 1000 watts and rode on torque mode. I didn’t notice big difference on motor behavior. Assist values are too high on turbo level. Assist do not get any better from sport level.
Last edited:
Great news
I will try this tomorrow.I forgot to upload the hex file to upload into the folder "file_to_upload".
So the folder contained an old version (that did not worked).
I just uploaded in github the right hex version.
Please note that:
- in this version I set the foc multiplier on 30 (instead of 14) hoping it will improve efficiency. To test if motor is not more unstable.
- the 860C version never modify the flash memory of the MCU. So, if the issue that some users noticed with the VLCD5 version after a power down is really the result of a corrupted memory, it should not happen with this 860C version. If it still happens, then the reason is to search somewhere else.
So the folder contained an old version (that did not worked).
I just uploaded in github the right hex version.
Please note that:
- in this version I set the foc multiplier on 30 (instead of 14) hoping it will improve efficiency. To test if motor is not more unstable.
- the 860C version never modify the flash memory of the MCU. So, if the issue that some users noticed with the VLCD5 version after a power down is really the result of a corrupted memory, it should not happen with this 860C version. If it still happens, then the reason is to search somewhere else.
There is no difference between TSDZ8 and TSDZ2 in the OSF firmware.@mstrens I am not sure what exactly you did to port osf to the tsdz8. So i don't know about the differences to the tsdz2. And i have absolutely no knowledge in the whole project so far. Right now i am diving into the code to understand how it works.
I did not find any multisampling or averaging over time of the torque sensor in the code. Can you confirm this?
My current hypothesis is, that the torque sensors of the tsdz8 and tsdz2 electromechanical behave differently. I assume that the "old" sensor took a few hundred ms to read its real value whereas the "new" sensor is way faster and nearly immediately reads the real value.
I just checked the "adc torque sensor 10b" data on my tsdz8 and it is kinda instantly changing when appying force.
The funny thing is that running the original firmware and reading out the torque value from the 0x46 messages it easily takes 3-5 seconds to go back to zero after hitting the pedals really hard. So i assume, tonghsheng added some sensor multisampling here...
I will setup my dev env now...
Edit: I proofed myself wrong. I added a 1s averaging to the torque sensor but it is still jerky. But it helped a little bit...
The torque is measured at the same frequency (19khz).
There is some filtering (but it is quite small) :
ui16_adc_pedal_torque_delta = (ui16_adc_pedal_torque_delta + ui16_adc_pedal_torque_delta_temp) >> 1;
One difference is that TSDZ8 uses a pulse of 2.5 usec instead of 2usec to drive the sensor.
The value read by ADC (in 10bits) is around 450 (TSDZ8) instead of 300 (TSDZ2) for a full load.
This makes the torque much more sensitive (2X) if the config is not adapted.
I do not know which filtering is used in the original firmware but it could be that the value in message 46 is filtered more than the value used internally to regulate the motor. This is just an hypothesis.
In TSDZ8 (and TSDZ2), the torque (and other parameters like cadence) are used to calculate a "controlled target current" for the motor.
The current (in fact voltage) applied to the motor is not directly the "controlled target current" but there is a ramp up/ramp down in between. This ramp act also like a filtering.
It could be that the acceleration factor (that defines the ramp up) should be reduced because TSDZ8 is more powerful than TSDZ2
After the first tests of 860c on the original settings in power mode there is jerking but changing dec in the motor settings to 8-9, acc I also increased it to 7, I increased the torque sensor range to 450 from 300 and it works very well, I uploaded hex 860c yesterday, all night without a battery and nothing happens with the settings after turn on today. I also tested if it will work with sw102 version v20 5.hex but there is error e06.
Last edited:
I rode with 860C display first with settings of TSDZ2 which was in display. TSDZ8 motor worked well. Then I checked torque sensor calibration. ADC value on pedal without push was 157 and standing on pedal 223 (From TSDZ2 which was on bike before TSDZ8). Then I checked TSDZ8 values and those were 176 and 423. I set them and start riding and assist was very poor. I set back old values of TSDZ2 and assist was good again.
Hello everyone. Last weekend I tried OSF on my bike. This is my first experience with OSF. I use the EKD01 display. I can confirm the findings that others have gained, especially the unevenness of the assistance. I will continue to try, but for now I put back the FW from FB, which I am quite satisfied with.
rivers
1 W
Hello Will2,
Could I ask where are the files on FB?
TSDZ2B TSDZ2C TSDZ8 TSDZ16 Mid Drive | This is the latest beta version of TSDZ8 | Facebook on thos group in files you can find all official hex. files
After few days of tests the osf version with 860c also has similar problems as the previous ones, they do not always happen and to varying degrees but the situation on my bike is that after a longer standstill with the battery turned off despite the previous good work of the set even in power mode, after turning it on again the engine fluctuates to a greater or lesser extent in all modes related to the torque sensor, only cadence and throttle work ok. I tried to change various settings to find out what is causing it but I did not succeed, changing the settings after the error appears helps a little but not much and the engine does not work as smoothly as before turning it off, and today I had such a situation that no changes in the menu helped. However, resetting the 860c to the factory settings and re-setting the original settings (which I am posting in the attachment) helps and then it works well in all modes (including power mode) until the next turn off.
Attachments
Last edited:
I noticed you have temp sensor. Does TSDZ8 go to to the limit (85 degrees).
Have you calibrated torque sensor?
I have also noticed fluctuations in different situations. Sometimes I come quite steep uphill and have of course quite lot of assist and have to stop pedaling for some reason and immediately start pedal again then there is jerking. One time on similar situation strange noise come out of motor and assist was gone and there was motor blocked error on 860C display. I rebooted display and assist was back. Also when I use lot of power from motor on steep hill and pedal standing there is jerking. Maybe cadence changes little bit when standing and that's why motor fluctuate. I've been riding on torque mode.
