I tried another solution yesterday, and today after a whole night without a battery everything works fine, so first I uploaded hex 860c again, turned on the screen and set power mode, dec 8 22A 1000W torque I set to 450, I did a test ride and everything worked great. Then I downloaded the entire software from the controller and saved it in hex format. I uploaded the saved hex to the controller again ( I check it and was diffrent from originall) and today after a whole night the bike rode just as well as yesterday (I'm not sure yet if it's luck or a solution)now I turned off the battery for another 10 hours and around 15 o'cloclk I will check again if it works well and I will let you know. To sum up, my assumption is that I copied the entire software after the changes on the display that ensured smooth driving, then uploaded it as hex in the hope that now after a standstill without a battery, the hex that has the correct settings from 860C will start, I don't know if it will work for sure maybe I'm wrong but I want to try.Currently I can't look at your config file because I am busy trying some more changes in the 860C version.
I expect that conflicts between different configurations can't explain all jerking issues because:
- jerking occurs also in the 860c version and this version does not have a configuration in the controller. The config is defined only in the 860C display and transmitted by the display to the controller.
- it seems in 860c version that jerking occurs after a long power off but disapears after a reset on the display (this action reload the config). This is very strange because as said before, the config is also reload from the display at each power on.
In vlcd5 version, there are 2 groups of data stored in the controller.
- the configuration generated by the javaconfigurator. Once uploaded, this configuration has the priority on the configuration you can define while compiling. To let the firmware use the config defined in vscode, you have to fully erase the flash memory (not only uploading the program) and to avoid uploading a javaconfigurator hex file afterwards.
- some parameters that can be changed from the VLCD5 display.
At least, this is how it is supposed to work.
Don't worry about it. In this case, I caused the error, I will let you know in time what the cause was, probably a typo in the code. I would like to know if the jerking manifests itself in the same way as on the 860C. Several users describe smooth engine operation and then jerking again. How to safely wipe all memory? I'm afraid I'll wipe the bootloader too. Or not?Currently I can't look at your config file because I am busy trying some more changes in the 860C version.
I expect that conflicts between different configurations can't explain all jerking issues because:
- jerking occurs also in the 860c version and this version does not have a configuration in the controller. The config is defined only in the 860C display and transmitted by the display to the controller.
- it seems in 860c version that jerking occurs after a long power off but disapears after a reset on the display (this action reload the config). This is very strange because as said before, the config is also reload from the display at each power on.
In vlcd5 version, there are 2 groups of data stored in the controller.
- the configuration generated by the javaconfigurator. Once uploaded, this configuration has the priority on the configuration you can define while compiling. To let the firmware use the config defined in vscode, you have to fully erase the flash memory (not only uploading the program) and to avoid uploading a javaconfigurator hex file afterwards.
- some parameters that can be changed from the VLCD5 display.
At least, this is how it is supposed to work.
I am not sure I understand well what you did.I tried another solution yesterday, and today after a whole night without a battery everything works fine, so first I uploaded hex 860c again, turned on the screen and set power mode, dec 8 22A 1000W torque I set to 450, I did a test ride and everything worked great. Then I downloaded the entire software from the controller and saved it in hex format. I uploaded the saved hex to the controller again ( I check it and was diffrent from originall) and today after a whole night the bike rode just as well as yesterday (I'm not sure yet if it's luck or a solution)now I turned off the battery for another 10 hours and around 15 o'cloclk I will check again if it works well and I will let you know. To sum up, my assumption is that I copied the entire software after the changes on the display that ensured smooth driving, then uploaded it as hex in the hope that now after a standstill without a battery, the hex that has the correct settings from 860C will start, I don't know if it will work for sure maybe I'm wrong but I want to try.
I uploaded the saved hex to the controller again ( I check it and was diffrent from originall)
Let me explain in your way,I am not sure I understand well what you did.
you say :
So I understand that
- some day, you uploaded in the controller a hex file that I provided on github or that you compiled your self. Say it is file XXXX
- you made some changes on 860C display
- you had a motor that runs fine
- you downloaded immediatelly the code in the controller and created an hex file. Say it is file YYYY
Then I have a doub:
1- after some hours, you compared file YYYY with file XXXX and they were different
or
2- after some hours, you compared the code that was present at that time in the controller (say hex code ZZZZZ) with the file YYYY and they were different.
Finally you flashed again the version YYYY and the motor runs fine.
What are the hex files that you compared?
What were the differences?
Can you provide me the 2 files?
Thanks. It is clear but I am very surprised that the 2 files are different (because firmware is not supposed to modify flash memory).Let me explain in your way,
1) I downloaded your hex (ver14) f.e XXXX
step2) I made some neccesery changes in display (display was in default settings)
step3) I rode to test if its ok ( it was very good so I thought to download by Jlink and Jflash all from controller and wrote as hex file) and this hex file f.e YYYY
4) I just wonder is YYYY it the same as XXXX so I compared with chat gpt help and werent the same there were many changes ( I thought that changing settings in menu 860c, changed hex file XXXX )
5) I downloaded YYYY as hex file to controller to check what happen, and it was working good yesterday and working good today after all night wohout battery
I will send you but on the evening
The assumption that hex fille XXXX and YYYY where different is false.Just for informational purposes for all, after another 11 hours without power, everything worked fine without jerking in power mode until I started changing anything in the menu or driving modes, after the changes, a slight jerking appeared. Do not repeat what I did because you can damage the controller.
It is good to notice that there is no jerking for cadence mode.After the first tests everything works very well (until I turn off the set) but I changed to higher ranges, in my opinion it seems to work best around 28-30, (question to Mstrens what is the range in which to test foc, i.e. what are the min and max values???). Unfortunately there is still the old problem that after uploading hex and first switching on everything works fine, but when you switch off and on again or switch off battery even for a moment, after switching on again it works bad and there is strong jerking (except for cadence mode), unfortunately after reset it works worse for me than ver14(in my opininon before reset was better then ver14) Changing the battery level/wheel circumference in the screen menu does not change anything.
This is not Error14 but function E03.View attachment 369611
I made the mistake of flashing the software with power from the battery still switched on, now the torque measuring coils make a high pitched whistle and do not work, I have to unplug the torque measuring system and defeat the error checking to allow the motor to run. I am waiting for a replacement controller, in the meantime I will open the re-enterable potting and see if I can locate the issue.
I also damaged one controller. It had exactly the same issue with the torque sensor. The torque measuring coils makes also a high pitched whistle. I never identified the reason why it has been damaged but it could be that I also flashed while the controller was powered by the battery AND simultenously by the J-link device.
I flashed many time the controller while it was powered by the battery but "normally" I take care that it is not powered simultenously by the j-link device. To do so, I do not connect the wire that provides power supply from J-link to controller. So I use only then only 3 wires.
I made a small trip this morning and while running in torque assist mode
Like you I expect that the torque sensor is not enough filtered. In version 0.1.15 I already increase the filtering but it could be that it is still not enough. Furthermore, I think that the ADC is read only 10 times per sec. It could be that this is not enough to get a good filtered value. The code is mainly based on OSF for TSDZ2 but it could be (to check) that TSDZ2 controller has also some hardware filtering that TSDZ8 does not have.
For info most fields in the TSDZ8 firmware are uint8_t because the code is greatly a copy of TSDZ2 OSF firmware that uses a 8 bits MCU.
I have noticed same thing. However motor is not necessarily jerking at least not so that you can feel it on your feet.I also damaged one controller. It had exactly the same issue with the torque sensor. The torque measuring coils makes also a high pitched whistle. I never identified the reason why it has been damaged but it could be that I also flashed while the controller was powered by the battery AND simultenously by the J-link device.
I flashed many time the controller while it was powered by the battery but "normally" I take care that it is not powered simultenously by the j-link device. To do so, I do not connect the wire that provides power supply from J-link to controller. So I use only then only 3 wires.
I made a small trip this morning and while running in torque assist mode, I noticed on the display that the power delivered by the motor varies quite a lot. Like you I expect that the torque sensor is not enough filtered. In version 0.1.15 I already increase the filtering but it could be that it is still not enough. Furthermore, I think that the ADC is read only 10 times per sec. It could be that this is not enough to get a good filtered value. The code is mainly based on OSF for TSDZ2 but it could be (to check) that TSDZ2 controller has also some hardware filtering that TSDZ8 does not have.
For info most fields in the TSDZ8 firmware are uint8_t because the code is greatly a copy of TSDZ2 OSF firmware that uses a 8 bits MCU.