TSDZ8 OSF (open source firmware)
- Thread starter mstrens
- Start date
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 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 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.
Last edited:
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?
Last edited:
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?
Last edited:
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
Thanks. It is clear but I am very surprised that the 2 files are different (because firmware is not supposed to modify flash memory).
I will look at the differences this evening.
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.
The assumption that hex fille XXXX and YYYY where different is false.
Prozyc sent me the 2 files and I compared them.
At first they look totally different but when you know how the data are structured, they are 100% identical.
Here the explanation:
- the hex file (xxxx) I generated with the compilation in vscode contains (nearly always 8 bytes of program code per line
- the hex file (yyyyy) downloaded with jlink contains always 16 bytes of program code per line.
With xls I converted both files in the same format and they are identical up to the last byte of file xxxx.
File yyyy contains more data (in upper rmemory) but this is because jlink has dowloaded the whole flash memory and that the upper part still stores bytes from previous flashing (where oldier program required more bytes).
Note : I would have been really surprised if the flash memory would have be corrupted. This was not logic with the fact that Prozyc said also in a previous post that he could solve jerking with just a reset on 860C display. I do not see how an action on the 860C display could change (restore) the program stored in flash memory.
Please note that this is not necessary the case for the VCD5 version (because some config parameters are stored in the upper part of the flash memory).
So at this stage, I still have no idea why jerking appears after a long power off. It is perhaps just incidental and related at some circumstances during initialisation process.
Today I drove on power mode. There was jerking occasionally when I started to pedal from standstill after braking to crossing where visibility was bad. Also few times one two second fluctuation was when I climbed steep hill with high assist level. Motor was working most of the time very smoothly.
By the way I like this motor very much compared to TSDZ2. When I I am coming home from quite long trip and feel tired and need good assist TSDZ8 gives it. TSDZ2 maybe get too hot on long run and decreased assist when I needed it most.
And thanks to @mstrens OSF I can I can adjust the assist levels as I like.
By the way I like this motor very much compared to TSDZ2. When I I am coming home from quite long trip and feel tired and need good assist TSDZ8 gives it. TSDZ2 maybe get too hot on long run and decreased assist when I needed it most.
And thanks to @mstrens OSF I can I can adjust the assist levels as I like.
Last edited:
For info, I put on github a version 0.1.15 for TSDZ8 with 860C display.
Not sure if it will be better than previous version.
Changes are :
- I noticed that intervals between PWM was not always as expected. I try to avoid it (no use of systick, of irq to capture hall pattern change, of segger_rtt to debug).
- I measure the current now with a moving average instead of an average over 1 rotation.
- Foc multiplier must be defined with the 860C.
Important note:
The FOC multiplier that plays a great role to calculate the 'foc angle" MUST now be defined with the 860C display. This allw you to easily test different values. There was no field in 860C display firmware and I did not wanted to change this firmware. Hopefully there one field that exists but was not used. So I reused it (but did not renamed it). This field is the group "Torque sensor" and is named "Coast brake ADC" . Be careful changing this value: it can largely decrease motor efficiency.
Previous version v0.1.14 used a fixed value for the multiplicator "30". It seamed quite good but perhaps is it not the optimum value.
I made (very limitted) tests with this version on a bike with a 36V battery. I set Coast brake ADC (=Foc multiplier) on 25. I used quite low values for motor acceleration and deceleration (less than 10). I changed torque setting to reduce sensitivity (e.g. max ADC is about 450 instead of 300, so I reduce ADC step too.). My first impressions were good.
If feedback on this version are good, I will make the same changes in a VLCD5 version.
Not sure if it will be better than previous version.
Changes are :
- I noticed that intervals between PWM was not always as expected. I try to avoid it (no use of systick, of irq to capture hall pattern change, of segger_rtt to debug).
- I measure the current now with a moving average instead of an average over 1 rotation.
- Foc multiplier must be defined with the 860C.
Important note:
The FOC multiplier that plays a great role to calculate the 'foc angle" MUST now be defined with the 860C display. This allw you to easily test different values. There was no field in 860C display firmware and I did not wanted to change this firmware. Hopefully there one field that exists but was not used. So I reused it (but did not renamed it). This field is the group "Torque sensor" and is named "Coast brake ADC" . Be careful changing this value: it can largely decrease motor efficiency.
Previous version v0.1.14 used a fixed value for the multiplicator "30". It seamed quite good but perhaps is it not the optimum value.
I made (very limitted) tests with this version on a bike with a 36V battery. I set Coast brake ADC (=Foc multiplier) on 25. I used quite low values for motor acceleration and deceleration (less than 10). I changed torque setting to reduce sensitivity (e.g. max ADC is about 450 instead of 300, so I reduce ADC step too.). My first impressions were good.
If feedback on this version are good, I will make the same changes in a VLCD5 version.
Last edited:
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.
Last edited:
It is good to notice that there is no jerking for cadence mode.
In cadence mode, the torque sensor is not used at all.
On the other side, at each power on, the firmware takes some time to look at the torque sensor and to measure the ADC value when there is no load on the pedal. It uses then the value as offset for all future measurement.
It would be good to look the value of the torque sensor without load and with a quite wel defined load (e.g. 20Kg on the pedal) and this in 2 situations:
- when there is no jerking (e.g. after an uploading)
- when there is jerking
I would not be surprised that the values are different in the 2 situations (even if I still do not understand why a power off has an impact).
With 860c I think you can see the "actual" ADC value of the torque sensor in the technical menu.
I do not know the min and max value for FOC multiplier. I think the 860C allows to change between 5 and 50 (not 100% sure).
I think optimum value should be in this range. Foc Angle (calculated based on foc multiplier, battery current and duty cycle) is limitted to 13 in the firmware (13 is the internal angle where 360° is represented by 256) which correspond to 18°. It could be (not sure) that on some 860C screen, the internal value (coded on 256) is displayed while on another it is the value in degree. This can be confusing.
It would also be good to have a look at all the values given by 860c display in the menu Torque sensor and see if there are any changes before and jerking
Last edited:
Hi all,...I have been lurking here for a while.. I have been using my mid drive kit quite often, I love the torque sensing but I hate the throttle!!!!...so I have downloaded the source code from github and I have made a couple of small changes ...in my code the throttle now controls the duty cycle directly rather than the current, of course the current is also limited to the max value, above max current the duty cycle reduces until max current is satisfied. I like how this works, it feels more natural than controlling the torque.
Now the bad news! and a warning for everyone else...!
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.
A couple of questions if anyone can help?...
Where do I look at the pin out as there is no pins.h file ?, and is there any reason that most of the variables are only byte values when more resolution is available?...
Regarding the jerking when using the torque sensor, it occurred to me that a really low pass filter on the torque measuring may help, bearing in mind that as pressure is applied to the pedal, the motor assists therefore automatically reducing the torque demand as the motor takes over, followed by pressure from your foot once again causing a torque demand...there might be some natural resonance taking place. until I can use my torque sensor I cannot validate the above but it is just a thought, maybe a different acceleration/deceleration value for the torque control might work, thereby allowing better throttle response and smoother torque control...
Anyway, A massive thanks to mstrens for this project, and every one else who contributes, I know how difficult it is and how much time it can absorb! thank you very much.
Cheers
Dorro
Now the bad news! and a warning for everyone else...!
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.
A couple of questions if anyone can help?...
Where do I look at the pin out as there is no pins.h file ?, and is there any reason that most of the variables are only byte values when more resolution is available?...
Regarding the jerking when using the torque sensor, it occurred to me that a really low pass filter on the torque measuring may help, bearing in mind that as pressure is applied to the pedal, the motor assists therefore automatically reducing the torque demand as the motor takes over, followed by pressure from your foot once again causing a torque demand...there might be some natural resonance taking place. until I can use my torque sensor I cannot validate the above but it is just a thought, maybe a different acceleration/deceleration value for the torque control might work, thereby allowing better throttle response and smoother torque control...
Anyway, A massive thanks to mstrens for this project, and every one else who contributes, I know how difficult it is and how much time it can absorb! thank you very much.
Cheers
Dorro
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.
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.
I have a TSDZ2, not TSDZ8. Torque measuring coils? Are you talking about the 2 copper colored round flat coils, one stationary, that rotates against each other?
AFAIK in the TSDZ2, the coils transmit power and signal between the rotating torque sensor (hall sensor + circuitry) and controller. The coils do not do the torque measurement.
edit: Interesting the coils makes a high pitched whistle! How did you determine it was coming from the coils and not elsewhere? Do you have an oscilloscope? Look at the coil waveform frequency and see if it match the whistle frequency.
Last edited:
I have noticed same thing. However motor is not necessarily jerking at least not so that you can feel it on your feet.
Today on my ride there was not jerking at all. Motor was behaving very nice.
Torque sensor uses indeed the 2 copper colored coils.
It is a kind of transformer to transmit power from the stationary part to the rotating part.
I looked with an oscilloscope at the signal. Normally, there is a pulse of 20V about 2usec every 20usec.
On the axis, there is an hall sensor. It consumes more or less cuurrent depending on the torque being applied.
The controller measures the current that drive the transformer.
The defect controller does not generate the 20V pulse anymore but a more or less 5V signal at a lower frequency that is audible.
If you disconnect the 2 wires between the controller and the coil, there is no noise anymore.
So it is clear that the electronic that drive the coil is defect (at least in my case).
I replaced the controller and I got again good torque measurements.
....looking at the circuit, Q7 is a pfet that drives the coil (to power the hall sensor for torque measurement), I'm guessing the cpu normally cycles this coil at some frequency, rebooting the cpu with battery power applied could leave this signal on causing high current through Q7 and permanently damaging normally resulting in a short circuit..i will replace this transistor and see what happens....wish me luck!....
I have removed Q7 it is indeed short circuit so I am hoping this is the problem, a replacement is on order.
cheers,
Dorro
I have removed Q7 it is indeed short circuit so I am hoping this is the problem, a replacement is on order.
cheers,
Dorro
Attachments
Last edited:
Alternador
10 µW
- Joined
- Jul 29, 2022
- Messages
- 6
Hello
I would like to try OSF on my TSDZ8. The problem is that a 48V battery fits very right on my bike. I guess the motor is 48V and wouldn't work well with 36V
In any case, I'm not sure if the OSF for VLCD5 works well, without jerks
Thank you for this OSF project and its continuation to mstrens and companyHello
I would like to try OSF on my TSDZ8. The problem is that a 48V battery fits very right on my bike. I guess the motor is 48V and wouldn't work well with 36V.
In any case, I'm not sure if the OSF for VLCD5 works well, without jerks.
Thank you for this OSF project and its continuation to mstrens and company. . . .
I would like to try OSF on my TSDZ8. The problem is that a 48V battery fits very right on my bike. I guess the motor is 48V and wouldn't work well with 36V
In any case, I'm not sure if the OSF for VLCD5 works well, without jerks
Thank you for this OSF project and its continuation to mstrens and companyHello
I would like to try OSF on my TSDZ8. The problem is that a 48V battery fits very right on my bike. I guess the motor is 48V and wouldn't work well with 36V.
In any case, I'm not sure if the OSF for VLCD5 works well, without jerks.
Thank you for this OSF project and its continuation to mstrens and company. . . .
