Can I also install a temperature sensor on the TSDZ8? I'm currently still using my TSDZ2, but I already have the TSDZ8 here and wanted to install it soon. I think the TSDZ8 shouldn't overheat under full load anymore, but if possible, I might play it safe and install a sensor there as well.
TSDZ8 OSF (open source firmware)
- Thread starter mstrens
- Start date
I don't have a temperature sensor, its not possible yet, I just threw in a picture with the throttle on(now I delete this picture to avoid misunderstanding). I haven't calibrated the pressure sensor yet, but I've tried both the original tsdz2 settings and the ones ebikestuff wrote about (450 instead of 300). I've also tried changing other values in the torque sensor menu after the jerking appeared, but that didn't help much. To make it work properly, it helps to reset the display to factory settings and re-set the values I sent in the pictures, and then it works smoothly.
Yes, I'm familiar with this great test, which is why I'm less worried about the TSDZ8. But I think ebikestuff only tested the outside temperature; the inside temperature could be a bit higher. At best, it would just be a safety feature that you never need. But if it doesn't work with the TSDZ8 anyway, it doesn't matter.
Thanks for the feedback. I had no internet connection for 2 last days and could not read this message.
I do not understand why we have those issues.
I could well imagine that there is a bug in OSF in such a way that some variables are not properly initialized at power on or that there is timing issue during power on but then the issue should be random and should not be solved in 100% of the cases by the actions you take.
You provide lot of helful info's. I will try to repeat it to be sure that I understand correctly.
Please say me if I am wrong in some ways.
- you tested version 0.1.13 for 860C
- sometimes after power on the motor fluctuates in all modes using torque sensor. So it never fluctuates in cadence mode or if throttle is used (and request more assist than without throttle - nb : in the code when trottle requests less assist than what is calculated bas e.g. on torque, sensor, it is just discarded).
- once the motor starts fluctuates, further power off and on NEVER help to fix it. Note : this is the case AS WELL when power off/on is done with the 860C button AS WELL when this is done shutting the battery down/on (question: has this been tested?).
- to fix the fluctuations, it is never required to reflash the controller
- to fix the fluctuations, you take action only on the 860C display. You go to the menu "Bike" and you select the item "Reset". And then you fill the values shown in your 3 pictures.
- this action fix the fluctuation issue in all cases (up to a standstill with battery turned off).
- when there was no fluctuation before, powering the motor off with the 860c display for a short time (e.g. 30 sec) NEVER creates the fluctuations
Note: I think that you can display on 860c the torque values during biking. I do not mean the screen with the menu to change the parameters but just displaying the current torque ADC value and the one when no load (used as offset). Perhaps could you look at those values when motor runs smooth (no fluctuations) and when it get fluctuations. If really the fluctuations are related to the torque sensor, I expect there should be some differences. Looking at the values could confirm (or not) this hypothesis.
Note: I am not sure but perhaps you could test another change to the torque sensor parameters: I saw that you filled 440 as torque ADC max. I presume that doing this change the value ADC torque step calc to 40. I ask myself if you do not have to enter this value (40) in the item named ADC torque step (so replacing the value 67). I expect that it is this parameter that is really used inside the controller. I am not 100% sure about this.
For testing, I made a new version for 860C (not for vlcd5). It is version 0.1.14 here GitHub - mstrens/OSF_860C
I am not sure it will fix the fluctuation issues because I do not yet know the reason.
Just to try, I
- added some more delay in the init phase
- avoid that code run from ram (and so could become corrupted during running); code will execute slower but I expect it is still OK.
I am not sure it will fix the fluctuation issues because I do not yet know the reason.
Just to try, I
- added some more delay in the init phase
- avoid that code run from ram (and so could become corrupted during running); code will execute slower but I expect it is still OK.
In general, almost everything you wrote is correct. I tested version 0.1.13 with the 860C display, version v20 c5. What doesn't match is that the issues are not always the same and vary in severity. That means the jerking is sometimes stronger, sometimes weaker. For example, yesterday after several hours with the battery disconnected, the system worked quite well (though still worse than after a reset). The jerking problem occurs both when turning off via the display and via the battery. Changes in the torque menu/ increase dec/ acc help only little bit after the issue appears.
I will soon check the changes you suggested in the torque menu, but I think unfortunately the issue lies elsewhere. The displays photos I sent, show the post-reset settings version, which works relatively well, but I tested changing various settings and setting combinations, both in torque and acc/dec.
I’m wondering if perhaps the way data is saved during power on and off differs between TSDZ2 and TSDZ8, and maybe the issue is somewhere in the EEPROM.
I will soon test the v14.hex version. I still have a few ideas I want to try, and I’ll let you know.
I will soon check the changes you suggested in the torque menu, but I think unfortunately the issue lies elsewhere. The displays photos I sent, show the post-reset settings version, which works relatively well, but I tested changing various settings and setting combinations, both in torque and acc/dec.
I’m wondering if perhaps the way data is saved during power on and off differs between TSDZ2 and TSDZ8, and maybe the issue is somewhere in the EEPROM.
I will soon test the v14.hex version. I still have a few ideas I want to try, and I’ll let you know.
Thanks.
In 860c version, there is no eeprom used on controller side. All parameters are stored only in the 860C display.
From a technical point of view, there are 3 types of category.
- Some parameters are used only inside the 860C display
- Some are sent to the controller continously (e.g. selected assist mode) with a frame named PERIODIC
- Some are sent to the controller only at each power on with a specific frame named CONFIGURATION. I think they are sent again but only if you change one of those parameters in the 860c display. Here some of thos parameters : Low voltage cut off, wheel perimeter, current max. So instead of making a full reset of the 860C you could try (as test) to change e.g. low voltage cut off or wheel perimeter.
Just to be sure I ask again the question: making a reset on the 860C (and changing some parameters) let you run ALWAYS (in 100% of the cases) smoothly (at least up to a next power off/on).
Almost always one time after many changes display freeze and after that when I turned on again reset doesnt help and I had to reload v13.hex again and after that was good.
This is really really strange. I can't understand why a reload of hex file can help (in 860c version) because there is no flash update foreseen in the firmware. So flash should never be modified.
If you still have such a case (reset not helping), it would be good if you could take a copy of the flash memory in the controller before reflashing the hex file. To make a copy, you can use the same Jlink program as for flashing. Comparing the copy with the "OSF official" hex file should confirm if the flash memory was really corrupted or not. If not I expect it is just chance that it helped.
I tested the 14.hex version a bit, first impressions it works definitely better than 13, I gave the same settings 20A, 1000W, Pwr Mode Acc 6 Dec 8, torque increase to 450, adc still 67 (to compare to last version), I compared everything on 2 screens 860c one with v20 c5 software here is a video.
and the ride the other display with v13 c5 software (new version) here is a video
I took the battery out for a few minutes after taking it out and turning it on again there was no problem with the engine fluctuating and everything worked ok on both screens. I wonder about this Foc because the mac reaches 18 on both displays, and I think you wrote that it is set to 30. But it also worked well on these 18, if it held these settings now it would be really ok because on power mode it is already pleasant to ride on these settings. I will check in the morning after a whole night without batteries if something has changed and there is a problm with jerking.
Ok next time I will do this, this problem may have appeared because of the many changes in settings that I made on the screen, now I have a second screen to be able to check if there will be any errors on it too (I have both on the same settings)
Every day this week I tried different changes to the OSF configuration. I never managed to achieve a regular operation similar to the original FW, the jerking was always very annoying. With the EKD01 I only have 2 minor display flaws. If I had to describe jerking in another way, I would say that the force on the rear wheel exactly copies the force on the pedal. Since I cannot develop a perfectly even force during 1 turn of the pedals, the force directed to the rear wheel also pulsates accordingly.
Last edited:
About FOC, there are in fact 2 values:
- the FOC angle is in fact a kind of advance that the firmware gives to the magnetic flux (to compensate the fact that when current and rpm increase, there is a phase lag between current and voltage).
- the foc multiplier: this is a parameter defined in the firmware that is a kind of ratio used to calculate the FOC angle. It is this parameter that can be changed (in the firmware , not on the 860C) that I set on 30.
The calculated foc angle can be displayed on 860c (I think).
There is some check in the firmware that limit the foc angle to a max value of 13 but this is an internal value. To convert it in degree you have to multiply by 360° and divide by 256. This makes 18. This conversion is probably done by the 860C display.
Note: in version 0.1.14 (I think) I made a change in the way FOC is calculated. In TSDZ2 firmware there was som kind of smoothing of foc angle to avoid fast changes (probably because calculation envolved a "noisy" measurement of the current). I removed this smoothing now because I already had removed a lot of the "noise" in current measurement (using an average on a whole rotation).
So do not be confused with foc angle and foc multiplier.
Is this also just after a reset on the display (or a change of Low voltage cut off)?
katana1234
100 µW
I've noticed jerking even when using the throttle only!
Can someone confirm this?
When testing please don't go full throttle. Only use about 25% throttle to gradually gain speed. This way you will feel the jerking easily.
At 100% throttle it's hardly noticeable.
After reset(I havent change low cut off just reset display) its much better, almost no jerking as on movie
whether the engine is working stably is easy to notice by the motor foc if under a greater load it is almost all the time "red" then there is no jerking
Last edited:
I checked also but throttle working quite good without jerking(860c v14.hex)
I drove today with 860C display on torque mode v1.14 and I didn't notice any fluctuation. Motor was working smoothly.
If I forget assist level on (e.g. assist level 1) when I shut down display and when next time power on motor jumps (start running) little bit.
If I forget assist level on (e.g. assist level 1) when I shut down display and when next time power on motor jumps (start running) little bit.
Thanks for sharing your experience. I am still trying to find why it happens.
I think it was my mistake. But maybe I would like you to take a look at my config_tsdz8. h file, which I changed during recompilation. The reason was to check the functionality without the configuration file generated by the java configurator. Every time I use this HEX file created via VScode together with any configuration file from the java configurator, then jerking occurs.
