TSDZ2 mid drive with 860C, 850C or SW102 displays only -- Flexible OpenSource firmware (Casainho code only)

vadda said:
buba said:
If anyone gets to the hard max limit very often it is usually because the min limit is too high. Try lowering the min limit and it will help with a better thermal control.

So if you have:
Min: 75 °C
Max: 85 °C

Try:
Min: 45 °C
Max: 85 °C

This will start to limit very, very slightly at 45 degrees and you will not even notice. But it will help to keep the temperature down and will give a smoother thermal throttling. This is not necessary to do, instead it is just a tip for anyone that wants a smoother experience.

Ok, thanks, this is a good hint because only 5° of difference between Max and Min it did not allow the engine to manage the power supplied progressively but it quickly got me to the assistance stop at the half of the hill

I had set 600W of maximum delivery power.

Yes, I try to set the min limit as high as possible just so I always have maximum power available. But it is usually better to set it lower and have some margin to the max limit. It will be much better and it copes better with the thermal delay in the system. We need to allow for some margin to have it manage the temperature as intended and this is very important! (!!!) We could solve this by adjusting for the thermal delay as is done in certain controllers but better to save program space for other more exciting functions! :)

EDIT:

This is really important so I want to throw out one last comment for anyone interested: the margin between the min and max limit should be as large as possible. So set the max limit to a value you feel is almost at the edge of safe operation. Maybe 90 degrees Celsius? And then have the min limit as low as possible. Maybe around 40 degrees Celsius? And I promise anyone that the thermal management will be much smoother and you will never end up standing still and waiting for the motor to cool down.

If the margin is lower it will overheat and shut off assistance. You will have to wait a cool down period before being able to use the bike. And that should never happen as there is a power level the TSDZ2 can maintain without overheating at each and every ambient temperature, altitude, humidity, etc. So if it does overheat the min and max are not optimally configured as the thermal management should find and settle at the perfect power level that does not increase the temperature any more for the given conditions you are riding in.

This should maybe be explained in the wiki...
 
buba said:
Was the ambient temperature above 20 degrees Celsius? I am just trying to figure out what it might be because I want it to be accurate for all users. But if it is a hardware problem then I know that it has been present on all versions on the firmware and there is nothing we can do.

On the display the temperature reported was about 26°-28°
 
buba said:
EDIT:

This is really important so I want to throw out one last comment for anyone interested: the margin between the min and max limit should be as large as possible. So set the max limit to a value you feel is almost at the edge of safe operation. Maybe 90 degrees Celsius? And then have the min limit as low as possible. Maybe around 40 degrees Celsius? And I promise anyone that the thermal management will be much smoother and you will never end up standing still and waiting for the motor to cool down.

If the margin is lower it will overheat and shut off assistance. You will have to wait a cool down period before being able to use the bike. And that should never happen as there is a power level the TSDZ2 can maintain without overheating at each and every ambient temperature, altitude, humidity, etc. So if it does overheat the min and max are not optimally configured as the thermal management should find and settle at the perfect power level that does not increase the temperature any more for the given conditions you are riding in.

This should maybe be explained in the wiki...

Ok, I'll try on the next ride, and absolutlely yes, it would be better be explained in the wiki
 
vadda said:
buba said:
This is really important so I want to throw out one last comment for anyone interested: the margin between the min and max limit should be as large as possible. So set the max limit to a value you feel is almost at the edge of safe operation. Maybe 90 degrees Celsius? And then have the min limit as low as possible. Maybe around 40 degrees Celsius? And I promise anyone that the thermal management will be much smoother and you will never end up standing still and waiting for the motor to cool down.

If the margin is lower it will overheat and shut off assistance. You will have to wait a cool down period before being able to use the bike. And that should never happen as there is a power level the TSDZ2 can maintain without overheating at each and every ambient temperature, altitude, humidity, etc. So if it does overheat the min and max are not optimally configured as the thermal management should find and settle at the perfect power level that does not increase the temperature any more for the given conditions you are riding in.

This should maybe be explained in the wiki...

Ok, I'll try on the next ride, and absolutlely yes, it would be better be explained in the wiki

Will fix in wiki and I hope it will work better! Thanks to you, many more users will maybe benefit from a slightly better thermal management setup.



vadda said:
buba said:
Was the ambient temperature above 20 degrees Celsius? I am just trying to figure out what it might be because I want it to be accurate for all users. But if it is a hardware problem then I know that it has been present on all versions on the firmware and there is nothing we can do.

On the display the temperature reported was about 26°-28°

Okay, thank you! Hmm... So your measurement on the display is off by around 0.8 %. I am not sure what it can be. Maybe related to the TSDZ2 hardware and caused by the riding weather, location, environment, etc. But I can not confirm this as more users need to validate the measurements. I do not think this will help but if you want to you are free to update to the A6 as it will be a little better with the filtering.

I am sorry, Vadda. I will try to find a cause to the discrepancy between our measurements and why you and another user have slightly lower voltage readings. But for now I actually have no solution because it shows these values on my bike:

Battery: 54.5
Display: 54.4
 
We have a difficult issue about different TSDZ2 motor controllers: 32 kbytes VS 16 kbytes flash memory

hego said:
Yes , Casainho .Ever the problem is the same. Sometimes, I dont know why the arguments in the memory are others diferents values as "00".....''?????
Sometimes are values like this... ( At 0x4000) ... CD 00 0A 32 86 01...

Maybe there is a limitation of memory for the differents series of STM8S105x4 iusses or x6 one.

Is very strange...a motor workm. an other is imposble. ?????????????

What us wrong in my process.

Cheers
When and where did you bought this motor?

I was afraid of this but I expected it was unlikely to happen.

Yes, the motor controller microcontroller is marked as STM8S105x4 that should have only 16 kbytes of flash memory. It is well known that some popular microcontrollers like STM32F103 of 64 kbytes flash memory have instead 128 kbytes and the same happens with STM8S105x4 that all of them I tested had instead the 32 kbytes flash memory.

That is why original firmware is only 16 kbytes.

So what should we do now??

I think I know but as I am being saying, it is probably another project to make our OpenSource firmware fit on the 16 kbytes by removing most of the options, etc. Maybe there is someone with energy to do that, I am not.
 
buba said:
I think you are right and agree fully, Bingo5! Especially if you want serious performance!

What you describe is exactly how the firmware does it but I can see why you feel it is as a black box function.

-----------------------------------

If anyone gets to the hard max limit very often it is usually because the min limit is too high. Try lowering the min limit and it will help with a better thermal control.

So if you have:
Min: 75 °C
Max: 85 °C

Try:
Min: 45 °C
Max: 85 °C

This will start to limit very, very slightly at 45 degrees and you will not even notice. But it will help to keep the temperature down and will give a smoother thermal throttling. This is not necessary to do, instead it is just a tip for anyone that wants a smoother experience.

Thank you buba, not only for your fast answer but also for your entgagement for the firmware and the people they want to use this.

I will try your hint. Before i has too much fear that eg 45°C the performance is too much pruned. Thats what i mean with "black box". So can you explain (if you have time for this) in more detail, how the power is limited between 45 and 85 °C?

By the way, actually i use the vlcd5 port from marcoq
 
casainho said:
We have a difficult issue about different TSDZ2 motor controllers: 32 kbytes VS 16 kbytes flash memory

hego said:
Yes , Casainho .Ever the problem is the same. Sometimes, I dont know why the arguments in the memory are others diferents values as "00".....''?????
Sometimes are values like this... ( At 0x4000) ... CD 00 0A 32 86 01...

Maybe there is a limitation of memory for the differents series of STM8S105x4 iusses or x6 one.

Is very strange...a motor workm. an other is imposble. ?????????????

What us wrong in my process.

Cheers
When and where did you bought this motor?

I was afraid of this but I expected it was unlikely to happen.

Yes, the motor controller microcontroller is marked as STM8S105x4 that should have only 16 kbytes of flash memory. It is well known that some popular microcontrollers like STM32F103 of 64 kbytes flash memory have instead 128 kbytes and the same happens with STM8S105x4 that all of them I tested had instead the 32 kbytes flash memory.

That is why original firmware is only 16 kbytes.

So what should we do now??

I think I know but as I am being saying, it is probably another project to make our OpenSource firmware fit on the 16 kbytes by removing most of the options, etc. Maybe there is someone with energy to do that, I am not.

Hmm... How many times has this occurred? That a user had the 16 kbytes STM8S105x4? And I see you have asked Hego when he bought it... I sure hope it was a long time ago because if they are currently switching to a batch of STM8S105x4 with 16 kbytes then it is a problem as there will be a lot of users not able to upload unless we limit the firmware.
 
buba said:
Hmm... How many times has this occurred? That a user had the 16 kbytes STM8S105x4? And I see you have asked Hego when he bought it... I sure hope it was a long time ago because if they are currently switching to a batch of STM8S105x4 with 16 kbytes then it is a problem as there will be a lot of users not able to upload unless we limit the firmware.
Since I recall, this is the very first time. Lets wait and see if more users report this, if not, it is easier to buy and install a new controller that costs only $30.
 
bingo5 said:
buba said:
I think you are right and agree fully, Bingo5! Especially if you want serious performance!

What you describe is exactly how the firmware does it but I can see why you feel it is as a black box function.

-----------------------------------

If anyone gets to the hard max limit very often it is usually because the min limit is too high. Try lowering the min limit and it will help with a better thermal control.

So if you have:
Min: 75 °C
Max: 85 °C

Try:
Min: 45 °C
Max: 85 °C

This will start to limit very, very slightly at 45 degrees and you will not even notice. But it will help to keep the temperature down and will give a smoother thermal throttling. This is not necessary to do, instead it is just a tip for anyone that wants a smoother experience.

Thank you buba, not only for your fast answer but also for your entgagement for the firmware and the people they want to use this.

I will try your hint. Before i has too much fear that eg 45°C the performance is too much pruned. Thats what i mean with "black box". So can you explain (if you have time for this) in more detail, how the power is limited between 45 and 85 °C?

By the way, actually i use the vlcd5 port from marcoq

Appreciate the kind words, Bingo5! :)

I will try to explain without going into much detail but let me know if something needs more explaining.

1. It all starts with the target current, targetCurrent. This is exactly what it sounds like: a target value of the current through the motor. If you are pushing hard on the pedals you will get a lot of power. This is because the targetCurrent is set high and the system is trying to give you that current.

2. The min limit defines the temperature where the thermal protection will start to limit the current through the motor. In other words, it is a threshold that when passed allows the thermal protection to engage and start limiting the targetCurrent.

3. The max limit defines the limit where the targetCurrent will be completely limited. This means that no matter what the targetCurrent is it will be 100 % limited.

To further explain we will start with an example with easy numbers:

---------------------------------

1. The target current is set to targetCurrent and it is 10 A

2. Min limit is set to minTemperature and it is set to 50 °C

3. Max limit is set to maxTemperature and it is set to 100 °C

The delta current, i.e. the difference between the lowest current and the targetCurrent, is 10 - 0 = 10. The delta temperature, i.e. the difference between the lowest and highest temperature, is 100 - 50 = 50.

This means that for every step above 50 °C, which is our defined min limit, the targetCurrent will be limited by 10 / 50 = 0.2 A.

So:
If the temperature is 51 °C it will limit the targetCurrent by 0.2 A.
If the temperature is 52 °C it will limit the targetCurrent by 0.4 A.
If the temperature is 53 °C it will limit the targetCurrent by 0.6 A.
...
If the temperature is 99 °C it will limit the targetCurrent by 9,8 A.
If the temperature is 100 °C it will limit the targetCurrent by 10 A.

Notice that every limiting step is only 0.2 A. If you had set the min and max limits closer with less of a margin the steps would be much bigger and aggressive.

---------------------------------

Here is a generic example:

1. The target current is set to targetCurrent

2. Min limit is set to minTemperature

3. Max limit is set to maxTemperature

The delta current, i.e. the difference between the lowest current and the targetCurrent, is targetCurrent - 0 = targetCurrent. The delta temperature, i.e. the difference between the lowest and highest temperature, is maxTemperature - minTemperature.

This means that for every step above minTemperature, the targetCurrent will be limited by targetCurrent / (maxTemperature - minTemperature).

---------------------------------

Final word:

As with many things you do not need to calculate anything. Just set the limits you feel are safe and should work, try it out and change if something is not working to your satisfaction.
 
Info per buba e casainho,
ho fatto 5 salite con una media di dislivello di 1500 mt con due bici con Tsdz2 una con software Marcoq e una originale proprio per avere dei dati certi da analizzare.
Il dato chiaro è che il motore con software originale quasi non scalda e tiepido, con il software modificato è bollente.
Ho riprogrammato il Tsdz2 modificato con software originale e rifatto lo stesso giro per avere anche questa comparazione, il dato è stato chiarissimo il motore è arrivato in cima quasi tiepido.
Entrambi le bici sono 36v e batteria da 630 Watt.
Penso proprio che sia un problema software.
Mi dimenticavo di dire che tutte le volte siamo saliti sempre in turbo.
Grazie ancora per il vostro meraviglioso lavoro.
 
Info per buba e casainho,
ho fatto 5 salite con una media di dislivello di 1500 mt con due bici con Tsdz2 una con software Marcoq e una originale proprio per avere dei dati certi da analizzare.
Il dato chiaro è che il motore con software originale quasi non scalda e tiepido, con il software modificato è bollente.
Ho riprogrammato il Tsdz2 modificato con software originale e rifatto lo stesso giro per avere anche questa comparazione, il dato è stato chiarissimo il motore è arrivato in cima quasi tiepido.
Entrambi le bici sono 36v e batteria da 630 Watt.
Penso proprio che sia un problema software.
Mi dimenticavo di dire che tutte le volte siamo saliti sempre in turbo.
Grazie ancora per il vostro meraviglioso lavoro.
 
chri27.5 said:
Info for buba and casainho,
I did 5 climbs with an average height difference of 1500 meters with two bikes with Tsdz2 one with Marcoq software and an original one just to have some reliable data to analyze.
The clear fact is that the engine with original software almost does not heat and warm, with the modified software is hot.
I reprogrammed the Tsdz2 modified with original software and redone the same lap to have this comparison, the data was very clear the engine arrived at the top almost warm.
Both bikes are 36v and 630 Watt battery.
I really think it's a software problem.
I forgot to say that we always went up in turbo every time.
Thanks again for your wonderful work.

Thank you for the kind words, Chri27.5!

What firmware version did you use and were the tests executed the same day within a couple of hours apart? Did you notice the motor was considerably hotter to the touch on the open source version?

I have heard once before that the original version was cooler to the touch than the open source but this can be due to a number of reasons. The original version is controlling the motor duty cycle. So when at speed it assists far less than the open source version that assists all the time. Also, it is very difficult to compare the two versions and exactly how much power each one is giving at any given moment...

Casainho, do you think there are some efficiency gains to be had by optimizing the FOC? It seems that people are reporting in a way that seems there are big gains to get in the efficiency department and you have a very clear understanding in that implementation.
 
buba said:
Casainho, do you think there are some efficiency gains to be had by optimizing the FOC? It seems that people are reporting in a way that seems there are big gains to get in the efficiency department and you have a very clear understanding in that implementation.
Please explain.
 
casainho said:
buba said:
Casainho, do you think there are some efficiency gains to be had by optimizing the FOC? It seems that people are reporting in a way that seems there are big gains to get in the efficiency department and you have a very clear understanding in that implementation.
Please explain.

I am really not experienced on this FOC implementation and have not looked at the code to be able to discuss proficiently with you so please forgive me in advance. I believe that the implementation is great and I know for a fact that it is quieter and has some nice characteristics compared to the original firmware.

Here are some points that we can maybe discuss or maybe in the future even improve. Please correct me where I am wrong and all the things I have missed.

- We are using the E phase voltage that is filtered from a filter that has a bias to zero and a big steady state error:

Code:
// low pass filter the voltage readed value, to avoid possible fast spikes/noise
ui16_adc_battery_voltage_accumulated -= ui16_adc_battery_voltage_accumulated >> READ_BATTERY_VOLTAGE_FILTER_COEFFICIENT;
ui16_adc_battery_voltage_accumulated += ui16_adc_read_battery_voltage_10b();
ui16_adc_battery_voltage_filtered = ui16_adc_battery_voltage_accumulated >> READ_BATTERY_VOLTAGE_FILTER_COEFFICIENT;

So it never uses the true value, instead it looks similar to this (please disregard that it is not the voltage, it is just an example):

Filtering with 2 division(1).png

The blue value is the real value and the red is filtered. Can this affect the calculation in some way?

Here is a suggestions using the same execution time and same amount of filtering:

Alpha filter, division by 2.png

Can this make the calculation more accurate? Same execution time on both filters.

- We are using the I phase current that is filtered from the same type of filter. Can this introduce some inefficiencies?

- We should change the ui32_l_x1048576 depending on motor ERPS due to filter bias or for better tuning?

- Motor rotor offset is the best and optimal value?

- The FOC angle is also filtered with the same type of filter as mentioned above


I know that the execution time is critical in those functions and we need to have it be the fastest possible. But is there something you see we can do to improve it some more? Together with the changes from Frans-Willem on his branch with more resolution and optimizations? I am only asking as I have not looked at these things nor tried to improve anything. Would like to hear what you think and what your comments are (and basically how wrong I am).

EDIT: Please do not take valuable time to answer all the questions! I did not mean for you to answer everything! I just want to know if you believe there are some efficiency gains to be had or is it already as efficient it can be from your testing back when this was implemented.
 
It's quite simple ... when I had the original software the engine gave little power. On the 20% gradient I could not have continuous 300w and it was a great effort. Obviously the temperature is much lower. Personally I want to have fun and an engine is cheap .... about 65 € I don't want automatic limits I only have a digital thermometer to check. And if an engine lasts a year but it made me enjoy it, that's fine, otherwise it's useless ....
 
buba said:
Here are some points that we can maybe discuss or maybe in the future even improve. Please correct me where I am wrong and all the things I have missed.
I can do many things at the same time, specially so different things. Now I am working on 850C display as also testing and learning the SW102. Maybe on another moment we can discuss again all this about FOC.

One note: that filter with the sums/subtractions and shift operations should be very fast and I found them on other projects, I don't know how well they work.

A thing you should do is measure the real time of the filter() you are using on v0.20.0 and they type of filter I used. Maybe you can use a board with a STM8 and measure with an oscilloscope.

This:

Code:
  // low pass filter the positive battery readed value (no regen current), to avoid possible fast spikes/noise
  ui16_adc_battery_current_accumulated -= ui16_adc_battery_current_accumulated >> READ_BATTERY_CURRENT_FILTER_COEFFICIENT;
  ui16_adc_battery_current_accumulated += ui16_adc_battery_current_10b;
  ui8_adc_battery_current_filtered_10b = ui16_adc_battery_current_accumulated >> READ_BATTERY_CURRENT_FILTER_COEFFICIENT;

VS this:

Code:
  if (ui8_alpha < 101)
  {
    uint32_t ui32_filtered_value = (((100 - ui8_alpha) * ui32_new_value) + (ui8_alpha * ui32_old_value)) / 100;
    
    if ((ui32_filtered_value == ui32_old_value) && (ui32_filtered_value < ui32_new_value)) { ++ui32_filtered_value; }
    
    return ui32_filtered_value;
  }
  else
  {
    return 0;
  }
 
2019-08-14-18-18-39-1.jpg


As I wanted the 850C and SW102 display on my handle bar, so I can connect one at each time and so test/use each one, I decided to move the 850C keypad to right side and because of that I implemented an option on firmware to invert the up and down buttons, otherwise would not be possible to use the key pad on right side. I hope to release a new firmware version for 850C on next days.

SW102 works very well but the main screen design is far from ideal and I think geeksville will focus on the design now.

The wiki has now instructions for the 3 displays: 850C, SW102 and KT-LCD3. I think the wiki need to be improved for this new displays, there is a good lack of information. For instance, I would like to build a table with the advantages an disadvantages of each display so it will be easier for new users to decide which they prefer.
 
casainho said:
buba said:
Here are some points that we can maybe discuss or maybe in the future even improve. Please correct me where I am wrong and all the things I have missed.
I can do many things at the same time, specially so different things. Now I am working on 850C display as also testing and learning the SW102. Maybe on another moment we can discuss again all this about FOC.

Yes, that would be great!



casainho said:
One note: that filter with the sums/subtractions and shift operations should be very fast and I found them on other projects, I don't know how well they work.

I understand and also believe they are fast but they are maybe lacking in accuracy. I have an implementation below that you will maybe like.



casainho said:
A thing you should do is measure the real time of the filter() you are using on v0.20.0 and they type of filter I used. Maybe you can use a board with a STM8 and measure with an oscilloscope.

This:

Code:
  // low pass filter the positive battery readed value (no regen current), to avoid possible fast spikes/noise
  ui16_adc_battery_current_accumulated -= ui16_adc_battery_current_accumulated >> READ_BATTERY_CURRENT_FILTER_COEFFICIENT;
  ui16_adc_battery_current_accumulated += ui16_adc_battery_current_10b;
  ui8_adc_battery_current_filtered_10b = ui16_adc_battery_current_accumulated >> READ_BATTERY_CURRENT_FILTER_COEFFICIENT;

VS this:

Code:
  if (ui8_alpha < 101)
  {
    uint32_t ui32_filtered_value = (((100 - ui8_alpha) * ui32_new_value) + (ui8_alpha * ui32_old_value)) / 100;
    
    if ((ui32_filtered_value == ui32_old_value) && (ui32_filtered_value < ui32_new_value)) { ++ui32_filtered_value; }
    
    return ui32_filtered_value;
  }
  else
  {
    return 0;
  }

Sorry, I should have explained more and given the code for the fast Alpha filter. The slower filter I use for the slow loops is the one you have included and it is this one:

Code:
  if (ui8_alpha < 101)
  {
    uint32_t ui32_filtered_value = (((100 - ui8_alpha) * ui32_new_value) + (ui8_alpha * ui32_old_value)) / 100;
    
    if ((ui32_filtered_value == ui32_old_value) && (ui32_filtered_value < ui32_new_value)) { ++ui32_filtered_value; }
    
    return ui32_filtered_value;
  }
  else
  {
    return 0;
  }

I believe that one is slower than the current implementation and I think we both suspect that. But when we need speed here is a fast implementation of the same filter and it is this filter I had in mind:

Code:
  ui16_adc_battery_voltage_filtered = (ui16_adc_read_battery_voltage_10b() + ui16_adc_battery_voltage_accumulated) >> READ_BATTERY_VOLTAGE_FILTER_COEFFICIENT;
  ui16_adc_battery_voltage_accumulated = ui16_adc_battery_voltage_filtered;

It has less steps and only one division with the same filtering. It is more accurate and simpler. Sorry, should have included from the beginning. That filter should be faster as well. But we can maybe do some interesting tests in the future and compare everything so that we know.

And also discuss the FOC overall and if you think there is something more to improve. I know that field weakening is something you want to implement. But as you mentioned this can be saved for another moment.
 
buba said:
casainho said:
I can do many things at the same time, specially so different things. Now I am working on 850C display as also testing and learning the SW102. Maybe on another moment we can discuss again all this about FOC.

Yes, that would be great!
casainho said:
That was an error, I wanted to say I CAN'T do many things at the same time.
 
casainho said:
buba said:
casainho said:
I can do many things at the same time, specially so different things. Now I am working on 850C display as also testing and learning the SW102. Maybe on another moment we can discuss again all this about FOC.

Yes, that would be great!
casainho said:
That was an error, I wanted to say I CAN'T do many things at the same time.

It is okay, I understood you and I meant:

Yes, that would be great [to discuss in another moment in the future]!
 
Hello buba, thanks for your continuous development on the last week's. :thumb:
Sorry not being an active tester lately but with three small kids the spare time is nearly zero and I've to carefully select my cartridges to shoot :lol: :lol:
Anyway I waited the alpha6 which I installed tonight: as expected all the setup had to be performed with the wiki beside, and everything went well.
After a garage test, not representative for real feelings, I realized that I hear a metal clicking sound from the motor when I press the brakes (I've the cut-off installed). I am sure that with the 0.19 that issue wasn't there.

To reproduce it you have to start pedaling to engage the motor, and while it turns you brake --> the motor stops turning and at the same time you hear the "click".
The higher the motor power in place, the noiser the click.

Unless you find an obvious reason for that, I think I would revert to 0.19 to make sure the issue goes away as it was untill tonight.

Thanks a lot!
 
Hello, I am looking at getting one of these in the near future.

How accurate is the torque sensor, or rather, how accurate is the human power reading generated from it?
As far as the 16kB/32kB issue is concerned, is it possible to replace the stm8 onboard? From what I've seen around the web, the controller seems to be flooded in some form of epoxy?
Are all units the same (i.e. the 36, 48 and 52 volt versions) as far as the hardware is concerned?
 
buba said:
Okay, thank you! Hmm... So your measurement on the display is off by around 0.8 %. I am not sure what it can be. Maybe related to the TSDZ2 hardware and caused by the riding weather, location, environment, etc. But I can not confirm this as more users need to validate the measurements. I do not think this will help but if you want to you are free to update to the A6 as it will be a little better with the filtering.

I am sorry, Vadda. I will try to find a cause to the discrepancy between our measurements and why you and another user have slightly lower voltage readings. But for now I actually have no solution because it shows these values on my bike:

Battery: 54.5
Display: 54.4

Ok, installed A6, all work great.
DIfference of 0.4V in voltage remains , but i think probably it's an hardware issue because on bikeof my friend (now with A6) the difference remains 0.2V.
I dont know if it's useful to provide the possibility of "tune" the reading with a sort of offset defined.

Another things, just for report, now with "weight on pedal" reading:
my bike read from 0 to 62Kg
the bike of my friend read only from 0 to 31Kg
 
If I remember the resolution is more or less 200-300 grams. The controller is the same for all version. The motor is different. 48v version is equal to 52v version.
 
vadda said:
Ok, installed A6, all work great.
DIfference of 0.4V in voltage remains , but i think probably it's an hardware issue because on bikeof my friend (now with A6) the difference remains 0.2V.
I dont know if it's useful to provide the possibility of "tune" the reading with a sort of offset defined.

Another things, just for report, now with "weight on pedal" reading:
my bike read from 0 to 62Kg
the bike of my friend read only from 0 to 31Kg

I just checked mine running A5, display shows 39.2-39.4, multimeter shows 39.3.

Interestingly if the lighting circuit is on the voltage jumps around 39.2-39.4, if the lights are off it is more stable 39.2 most of the time.
Some noise being injected? Anyway perhaps there is more smoothing in A6, will try this afternoon.
 
Back
Top