TSDZ8 OSF (open source firmware)

mstrens said:
In version 13, I hardcoded a parameter called FOC multiplier on a value = 14.
Click to expand...
Why don't you try a real FOC approach? The processor is fast enough to do so. It makes no sense to adapt a workaround from a slow 8bit processor. What you call FOC all the time, is no FOC in common sense, it's just tuning the advance angle for a simple sinosoidal commutation...
 
stancecoke said:
Why don't you try a real FOC approach? The processor is fast enough to do so. It makes no sense to adapt a workaround from a slow 8bit processor. What you call FOC all the time, is no FOC in common sense, it's just tuning the advance angle for a simple sinosoidal commutation...
Click to expand...
You are right but:
- one main advantage of trying to reuse sinusoidal commutation is that it does not require many changes to TSDZ2 OSF code. It can reuse the same parameters/assist logic and so also the javaconfigurator and interface with VLCD5 or 860C display.
- I tested one real FOC algorithm but the current signal on the oscilloscope was not better. Perhaps because I tested only with no load and not with the the right value for motor inductance (that plays a role in angle calculation)
- the code example I used for real FOC is for sensorless. I do not know if it will work well when starting under heavy load
- I do not feel confortable adding hall sensors to this FOC example.
- the other user that tried to use this FOC example some years ago damaged his controller the first time he tested it on a bike (and then stop developments with this type of controller)
- I would have to implement different PID for the different assist modes and this requires probably a lot of test to fine tune the parameters

Could you provide some help?
 
mstrens said:
@prozyc

I expect that my post here above seems you quite strange because I refer to testing in 3 ways.
This is my fault.
In fact outside of this forum I also had some mail exchanges with ebikestuff.
I thought that prozyc was the pseudo name of Ebikestuff on this forum and this created some confusions.

FYI ebikestuff makes also some tests on a home trainer with version 13. He provided a video that I callled test 1 in post above.

To clarify things I put here below a related mail from ebikestuff:

I did a few tests. The video can be seen here:

While doing the high amps test I've noticed that the battery connector gets hot. Probably a bad solder joint. This might have affected the efficiency a little so I soldered a new connector to make sure everything is working fine. The last test in the video above is with the new battery connector. I don't know if there's any difference.

Anyway. It seems like the efficiency is fine when using higher foc multiplier. As you can see on the video, the higher values like 28 or even 30 result in the highest rpm. The power output on the home trainer seems to be reflecting that. It's hard to tell the difference between those higher values. I would have to record a longer video and try to calculate the average power draw from BMS and compare it against the average power from home trainer. I believe that the differences would be small. But definitely the lower values like 14 are not optimal for the efficiency.
The fluctuations are still there but I've only noticed them after running the test with high load for a while.

I also did a few kms commute. The jerkiness is still there. The assistance doesn't seem to be smooth. It works but the motor gives that "jerky" feeling. I haven't tried different modes. I only used hybrid. It's possible that it's caused by the old config with the torque sensor calibration that I used. If I have some spare time I will try the default config and see if there's any difference.



Please note that getting a current of 22A is not necessary a good thing. In fact it could be that the motor has low efficiency (due to non optimal synchronization of the rotation of the magnetic flux). When synchronization is not good, the motor consumes more for the same effective power.
In version 13, I hardcoded a parameter called FOC multiplier on a value = 14. I expected this would be good but the tests made by ebikestuff on the video with a home trainer seems to indicate that the value should be much higher (he get highier rpm with lower Amp).
Click to expand...
I was just about to write that this probably wasn't my answer, but I understand the mistake, I'm also from Poland like ebikestuff but I'm just an ebike enthusiast, not a company;) yesterday I checked src and saw that the Foc value is set to 14, I tested it a bit by changing the acc and dec (50 and 50) in java cfg and it works, testing it on the bike in the field, in power mode works q8very well without any jerks and engine surges also at lower revs, at low rpm it was also ok, the throttle works ok. and generally my feelings after the ride are very positive, I would even say that acc and dec 50, 22A, 1200W, pwr mode with field weakning and startboost supports too much when starting and I will probably eventually reduce it so as not to overload the engine and transmission too much. I wonder if ebikestuff will have any problems in power mode, I will test other modes myself and let you know, I will also check the energy consumption because I have such an option in the ammeter. The hex file is generated in the latest version of the Mbrus software because there were problems in the older one, maybe this is the reason for the engine fluctuation in ebikestuff.
 
Matze_Senpaii said:
so is 22amp the maximum of tsdz8 controller ?
Click to expand...
I would not focuss now on the max Amp. It could be that efficiency is not optimal and so it could be that currently the effective power at 22A would be less than with an optimal firmware at 20A. Furthermore, if efficiency is not optimal, the motor/controler will heat more. Also take care that the motor is normaly rated for 750W which requires much less than 22Amp at 48V
 
prozyc said:
I was just about to write that this probably wasn't my answer, but I understand the mistake, I'm also from Poland like ebikestuff but I'm just an ebike enthusiast, not a company;) yesterday I checked src and saw that the Foc value is set to 14, I tested it a bit by changing the acc and dec (50 and 50) in java cfg and it works, testing it on the bike in the field, in power mode works q8very well without any jerks and engine surges also at lower revs, at low rpm it was also ok, the throttle works ok. and generally my feelings after the ride are very positive, I would even say that acc and dec 50, 22A, 1200W, pwr mode with field weakning and startboost supports too much when starting and I will probably eventually reduce it so as not to overload the engine and transmission too much. I wonder if ebikestuff will have any problems in power mode, I will test other modes myself and let you know, I will also check the energy consumption because I have such an option in the ammeter. The hex file is generated in the latest version of the Mbrus software because there were problems in the older one, maybe this is the reason for the engine fluctuation in ebikestuff.
Click to expand...
As you can compile yourself, you could perhaps try increasing the FOC multiplier up to 30 and see if feeling is still good.
 
Hi, to avoid any confusion. It's ebikestuff here. We've been testing OSF with Michel for a while. Thank you, Michel. You put a ton of work into this. Excellent job!

Back to the OSF issues.
We did more testing with a default config and different assistance modes. The assistance is way smoother than it was before. However, there's still that feeling that the torque sensor is too sensitive. The cadence mode is smooth. No issues here. The power and hybrid modes are not that smooth. I tried the torque sensor calibration, but the assistance is still a bit "jerky". I haven't tried motor acc and dec settings. These might work because it looks like the motor reacts too fast to the changes in the torque sensor readings. I will make that additional test and see if it helps
 
I was riding today 66 kms on power mode. Motor was working smoothly. I felt little fluctuations on steep hills few times but not every hills. I used on the steep hills highest assist level and most of the time I was riding with first or second assist level.
Assist.jpgBasic.jpg
 
stancecoke said:
Without the controller hardware it's difficult to help. :(
Click to expand...
Perhaps can you give guide lines and just check the code that drive the motor.

e.g. does it help to replace sensorless by hall sensors? Is this always better (for all erps) or only at start up up to some erps (and then switching to sensorless) or is it never better?
 
Last edited:
dameri said:
I was riding today 66 kms on power mode. Motor was working smoothly. I felt little fluctuations on steep hills few times but not every hills. I used on the steep hills highest assist level and most of the time I was riding with first or second assist level.
View attachment 369088View attachment 369089
Click to expand...
Thanks for the feed back.
Note : in the configurator, you use the default setup for the torque sensor. It supposes that the max ADC torque is 300.
In fact, another user reported that the max ADC torque was higher for the TSDZ8. It was 450 if I remember wel.
Increasing the max value will probably make the motor a little less reactive/sensitive
 
mstrens said:
does it help to replace sensorless by hall sensors?
Click to expand...
For robustness, yes. For maximum smooth run, no.
Sensorless only works, if the observer parameters are tuned well. The VESC has detection routines for optimizing the observer automatically, but they fail sometimes and you have to optimize manually. I don't know, how this works with the tools you are using for the motor code.
If you use the hallsensors to estimate the rotor position, this is independent from the inductivity, resistance, flux of the motor, so you have less potential error sources.
But of course there are different strategies for to extrapolate the recent roto angle from the hallsensor signals. In EBiCS I have implemented a simple linear extrapolation and a PLL.
I would start with the linear extrapolation, like it is implemented in the TSDZ2 code already, but with a very low resolution, due to the 8bit logic and the lookup table for the space vector modulation.
I'm using full 32bit angle resolution and math instead of the look up table for the SVM...
 
Thanks for the reply.
Sensorless example (provided by Infineon) uses a PLL to estimate speed and angle. I do not know how it works. Source code of this PLL is not available. It is delivered as a precompiled lib (and use a CORDIC component of the MCU).
In a config file, I can can define the resistance and the inductance of the motor. Then those parameters are used to calculate many other #defines used for different KP, KI and limits of the different PID's (speed, torque, flux) but not for the PLL (I think).

I do not know if the positions provided by the hall sensors are more accurate than those from the hall sensors. I noticed that the hall transitions are not equaly spaced (the time intervals between the different pattern changes are different even when the motor runs at constant and rather high speed). In principe I could take care of those difference (in the same way I do it currently for TSDZ8) but it would be for my motor and perhaps it is not good for other TSDZ8.
 
mstrens said:
Thanks for the feed back.
Note : in the configurator, you use the default setup for the torque sensor. It supposes that the max ADC torque is 300.
In fact, another user reported that the max ADC torque was higher for the TSDZ8. It was 450 if I remember wel.
Increasing the max value will probably make the motor a little less reactive/sensitive
Click to expand...
When I use the power mode while driving, do I have to adjust also the settings for the torque mode in java.configurator as well? I'm not familiar for java.configurator because I have used many years 860C display and make configs straight in display.
 
dameri said:
When I use the power mode while driving, do I have to adjust also the settings for the torque mode in java.configurator as well? I'm not familiar for java.configurator because I have used many years 860C display and make configs straight in display.
Click to expand...
I think that all assist modes except CADENCE and WALK ASSIST use the values provided by the torque sensor.
 
I tested various foc settings (14,22,30) acc dec and modes on the bike. In Cadence mode everything works quite smoothly but in tsdz8, rather few people want to ride on Pas;My conclusions for now (I rode about 20km on various settings so it's rather not much) changing only Foc 14/22/30, from acc dec 35/35 pwr mode, there is noticeable although much smaller jerking that was on older versions at all foc levels, and it's hard for me to say which foc was the best.
However, when I increased acc to 45-55 (although this setting is less important and could even be 35) and significantly increasing dec first to 70 and now to 80, the bike works the best for now on a higher Foc (30) in my subjective opinion. With dec80 22A 1100W, starrboost, field weakning in pwr mode it runs quite smoothly with almost imperceptible jerking also on climbs. I will test more and let you know, if you want MStrens I can check other Foc values. I will let you know soon how the energy consumption is on individual Foc, on 14 it was similar to the test version 3.0.
 

Attachments

  • 20250424_105309.jpg
    20250424_105309.jpg
    4 MB · Views: 23
  • 20250424_105304.jpg
    20250424_105304.jpg
    3.4 MB · Views: 14
  • 20250424_105255.jpg
    20250424_105255.jpg
    4.3 MB · Views: 17
prozyc said:
I tested various foc settings (14,22,30) acc dec and modes on the bike. In Cadence mode everything works quite smoothly but in tsdz8, rather few people want to ride on Pas;My conclusions for now (I rode about 20km on various settings so it's rather not much) changing only Foc 14/22/30, from acc dec 35/35 pwr mode, there is noticeable although much smaller jerking that was on older versions at all foc levels, and it's hard for me to say which foc was the best.
However, when I increased acc to 45-55 (although this setting is less important and could even be 35) and significantly increasing dec first to 70 and now to 80, the bike works the best for now on a higher Foc (30) in my subjective opinion. With dec80 22A 1100W, starrboost, field weakning in pwr mode it runs quite smoothly with almost imperceptible jerking also on climbs. I will test more and let you know, if you want MStrens I can check other Foc values. I will let you know soon how the energy consumption is on individual Foc, on 14 it was similar to the test version 3.0.
Click to expand...
Thanks for the feed back.
When you say "I will let you know soon how the energy consumption is on individual Foc", I presume you mean that you will look at the efficiency (ratio between energy provided by the motor and energy provided by the battery). I presume you have to do it with the home trainer. Best would be to proceed like mbrusa did.
Here what he explained me:
With the home trainer I changed method, I obtained the optimal value by calculating the efficiency, Trainer power / Battery power.
This is the procedure I used:

  • 860C has 9 levels, I use the levels as a step accelerator.
  • The home trainer also has different load levels, I use 6 of them.
  • I start the motor with the UP button, up to the test level, I set the load level on the home trainer.
    At this point I turn on the lights to change the function of the UP and DOWN buttons, I use them to manually correct the foc angle, at level 5 no correction, higher levels positive correction up to +4, lower levels negative correction up to -4.
    If the motor runs well I try to increase. Increasing the angle can have two consequences, increase in power and rpm and I can continue to increase, or power and rpm become unstable and I have to go back.
    If instead the rotation of the motor is unstable already with the calculated foc (correction = 0), I try to decrease it until I obtain a regular rotation.
    In this condition I calculate the efficiency, Trainer Power / Battery Power. Then I try to decrease the angle (-1 and -2) and check if the efficiency has changed.
    I take note of the correction that gives a better efficiency.
  • In these 54 combinations, I also take note of all the operating data.
    Battery power and current with an external instrument.
    Home trainer power with its app.
    Duty cycle PWM, ERPS and FOC angle, read on the 860C display.
    In addition to the correction of the foc angle already described.
    I do not know the precision of the instruments used, but I consider the comparison valid.
  • With this data I looked for a formula to obtain a foc angle that corresponds to those obtained manually in all 54 combinations, hence 50% battery current and 50% motor current, with consequent adjustment of FOC_ANGLE_MULTIPLIER.
  • The tests were done with a 36V motor and a 36V battery, always fully charged. I don't have such a powerful stabilized power supply, so to test in the same conditions with medium-high power, I can only do two tests a day (I have two batteries), then I have to recharge them and continue another day.

To make the task easier for you, I could make a uc-probe where you can directly change the foc angle, the max current and the duty cycle target. It would display an average rpm, current and duty cycle. This could be used with different loads selected on the home trainer.
 
mstrens said:
Thanks for the feed back.
When you say "I will let you know soon how the energy consumption is on individual Foc", I presume you mean that you will look at the efficiency (ratio between energy provided by the motor and energy provided by the battery). I presume you have to do it with the home trainer. Best would be to proceed like mbrusa did.
Here what he explained me:
With the home trainer I changed method, I obtained the optimal value by calculating the efficiency, Trainer power / Battery power.
This is the procedure I used:

  • 860C has 9 levels, I use the levels as a step accelerator.
  • The home trainer also has different load levels, I use 6 of them.
  • I start the motor with the UP button, up to the test level, I set the load level on the home trainer.
    At this point I turn on the lights to change the function of the UP and DOWN buttons, I use them to manually correct the foc angle, at level 5 no correction, higher levels positive correction up to +4, lower levels negative correction up to -4.
    If the motor runs well I try to increase. Increasing the angle can have two consequences, increase in power and rpm and I can continue to increase, or power and rpm become unstable and I have to go back.
    If instead the rotation of the motor is unstable already with the calculated foc (correction = 0), I try to decrease it until I obtain a regular rotation.
    In this condition I calculate the efficiency, Trainer Power / Battery Power. Then I try to decrease the angle (-1 and -2) and check if the efficiency has changed.
    I take note of the correction that gives a better efficiency.
  • In these 54 combinations, I also take note of all the operating data.
    Battery power and current with an external instrument.
    Home trainer power with its app.
    Duty cycle PWM, ERPS and FOC angle, read on the 860C display.
    In addition to the correction of the foc angle already described.
    I do not know the precision of the instruments used, but I consider the comparison valid.
  • With this data I looked for a formula to obtain a foc angle that corresponds to those obtained manually in all 54 combinations, hence 50% battery current and 50% motor current, with consequent adjustment of FOC_ANGLE_MULTIPLIER.
  • The tests were done with a 36V motor and a 36V battery, always fully charged. I don't have such a powerful stabilized power supply, so to test in the same conditions with medium-high power, I can only do two tests a day (I have two batteries), then I have to recharge them and continue another day.

To make the task easier for you, I could make a uc-probe where you can directly change the foc angle, the max current and the duty cycle target. It would display an average rpm, current and duty cycle. This could be used with different loads selected on the home trainer.
Click to expand...
Unfortunately I am not able to test this way because I do not have a home trainer, I thought to compare it based on the consumption of Ah from an ammeter/bms from the same route that I ride every day (about 12km) in the same conditions, support level and battery, only changing Foc. Maybe someone else will be able to measure it in the way you provided, I will compare as I wrote and I will look for the optimal Foc/Acc/Dec/Torque settings in my opinion.
 
I rode 47 kms today and first 30 km OSF_TSDZ8_V00_01_13.hex was working very fine. Motor was at power mode. On steep hills, I did not notice any difference in assistance between the third and fourth level. Perhaps 800 W came from the third level setting. It started rain and roads get wet and I continued riding before I stopped to visit at the shop. After that last 10 km there was quite a lot fluctuatation on the motor. Sometimes assist clearly deteriorated for a couple of seconds and then returned to its original level. Shorter decreases in assistance were also observed. I don’t know if moisture got inside of the motor or what happen. Motor didn’t feel hot at all from outside when I tested it by hand.

assist.jpgbasic.jpg
 
I was just going to write about this because something similar happened to me, everything was working great but I turned the battery off for a few hours and after turning it back on completely different assist also appeared fluctuations and it works unevenly. Yesterday on the same settings in
everything worked great.
 
Very strange.
At this stage, I have no idea of what is happening.
It could be quite difficult to find if it appears randomly.
If you now restart the motor without having reflash the controller , does it work wel again?
If not, does it work well after having reflash only the configuration?
If not, does it work well after having reflash only the firmware?
 
I noticed also another day after cutting power off and power on again after half an hour there was little fluctuations but it was short trip what I travelled after that.
I always reflash first firmware and then configuration.
Tomorrow I will try same configuration as today but I will change it to torque mode. And maybe increase max power.
 
Hi, i want to flash the firmware to help improving it.
But in case it behaves unreliably, i can simply flash the original firmware right?
 
You must log in or register to reply here.

Similar threads

M
    • Like
Developing open source firmware for TSDZ8
Replies
5
Views
2,438
dameri
D
S
Actual max power of th48ve TSDZ2B with OSF/
Replies
6
Views
1,489
dgc
dgc
A
Nucular 24F with Display
Replies
1
Views
562
Amperry417
A
inkobl
Valdenaire french postman bicycle TSDZ2B, TSDZ8 or BBS02B ?
Replies
24
Views
6,483
marvin78
M
V
    • Like
User profiles (BBS02B, BBSHD) for BBS-FW (Daniel Nilsson's Open Source Firmware)
Replies
15
Views
7,402
cry0g3n2020
cry0g3n2020
Back
Top