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

[buba]

Very excited to hear that and good to know what sensitivity level you are using! But also what you would prefer. I think it would be possible to improve the formula so eMTB is operating better and can fit your needs with only one assist mode. It should be great in any sensitivity level, that is the goal. Will consider everything you have said and think about it!

Hi Buba - potentially I missed it, but could you please explain the logic behind eMTB mode? It feels a bias toward torque at low rpm and then more toward power at higher rpm?

Anyway it is great. Successfully retired boost assist and also no random lags when starting off.

Hello Mctubster! Yeah, sure!

EDIT: Glad you like it and that you are satisfied with the 0.20.0!

eMTB is only based on pedal torque. So the more you push on the pedals the more current it will send to the motor. More current means more torque -> more assistance -> more power.

eMTB is similar to Torque Assist but there is one important difference. Below are some simplifications:

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

Torque Assist:

MotorCurrent = PedalTorque * AssistLevelMultiplier

Example:

8 AMPS = 5 NM * 1.6

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

eMTB Asssist

MotorCurrent = PedalTorque^X

Where X is a number between 1.3 and 2

Example:

8 AMPS = 5 NM ^ 1.3

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

That small difference makes it much easier to scale the input torque to the motor output torque. It is possible to setup so it gives normal assistance in normal conditions but as soon as you start pushing the pedals harder you will get a much higher percentage of assistance compared to Power Assist and Torque Assist.

If you are using Torque Assist you would have to push the pedals twice as hard for twice the motor torque. Contrary, with eMTB Assist, depending on sensitivity, you only have to push the pedals 20 % harder to get twice the motor power.

eMTB is not finished and will continually get better. Maybe even with pedal cadence added in the formula if that improves the feeling. I know for a fact that the values we have now can get much, much, better. The more feedback I get the faster we can improve it. Just knowing what sensitivity everyone is using can improve the feeling as we can rescale the formula and get to better values.

So if any user wishes to share some data just let me know what eMTB sensitivity you are using and I will use that to improve eMTB.

EDIT: Glad you like it and that you are satisfied with the 0.20.0!

 

[buba]

Users using the imperial system:



Not saying this will be possible to implement due to program space constraints but want to know if there is anything I have missed that should be sorted out. Just so that we know.

Here are a couple of things I have noticed:

- Motor temperature in Fahrenheit
- Pedal Weight in pounds
- Street Mode speed limit in MPH

MPH a definite must.
Weight we still weigh our bodies in in stones and pounds and a lot of food, I won't even bother to explain the complexities of buying coal by the hundred weight :wink: KG is fine

Understandable! :wink:

Temp in either but Fahrenheit is my preferred purely because it is more sensitive ie 32 f to 100f is 68 increments but only 37.7 increments in degrees Celsius

Was considering Fahrenheit and would love to add it to the 0.20.0! But have it be configurable by user. We will see!

If you are going to add an altimeter then in feet please.

Of course! But that will be for the next project! It is going to be wild! :wink:

 

[vadda]

On the A5 I found that the voltage reported by the LCD3 compared to that
measured with the Tester is 0.4V lower.

Furthermore, today I finally tried the bike on a challenging mountain course,
along with other "real electric bikes" and the only big problem encountered was
the temperature that the engine reaches on medium-long climbs.
I had to make more than one stop and wait because the engine had reached 75 degrees
and had rightly cut off the assistance.

In addition to looking for a mechanical solution, is there any parameter you could try to
modify to keep the temperature lower without sacrificing power?

 

[andrea_104kg]

Very excited to hear that and good to know what sensitivity level you are using! But also what you would prefer. I think it would be possible to improve the formula so eMTB is operating better and can fit your needs with only one assist mode. It should be great in any sensitivity level, that is the goal. Will consider everything you have said and think about it!

Hi Buba - potentially I missed it, but could you please explain the logic behind eMTB mode? It feels a bias toward torque at low rpm and then more toward power at higher rpm?

Anyway it is great. Successfully retired boost assist and also no random lags when starting off.

Hello Mctubster! Yeah, sure!

EDIT: Glad you like it and that you are satisfied with the 0.20.0!

eMTB is only based on pedal torque. So the more you push on the pedals the more current it will send to the motor. More current means more torque -> more assistance -> more power.

eMTB is similar to Torque Assist but there is one important difference. Below are some simplifications:

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

Torque Assist:

MotorCurrent = PedalTorque * AssistLevelMultiplier

Example:

8 AMPS = 5 NM * 1.6

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

eMTB Asssist

MotorCurrent = PedalTorque^X

Where X is a number between 1.3 and 2

Example:

8 AMPS = 5 NM ^ 1.3

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

That small difference makes it much easier to scale the input torque to the motor output torque. It is possible to setup so it gives normal assistance in normal conditions but as soon as you start pushing the pedals harder you will get a much higher percentage of assistance compared to Power Assist and Torque Assist.

If you are using Torque Assist you would have to push the pedals twice as hard for twice the motor torque. Contrary, with eMTB Assist, depending on sensitivity, you only have to push the pedals 20 % harder to get twice the motor power.

eMTB is not finished and will continually get better. Maybe even with pedal cadence added in the formula if that improves the feeling. I know for a fact that the values we have now can get much, much, better. The more feedback I get the faster we can improve it. Just knowing what sensitivity everyone is using can improve the feeling as we can rescale the formula and get to better values.

So if any user wishes to share some data just let me know what eMTB sensitivity you are using and I will use that to improve eMTB.

EDIT: Glad you like it and that you are satisfied with the 0.20.0!

now i understand why i don't like emtb. Following the logic of the original firmware which for me is really bad. couldn't you try the same logic on the power assist level to see how it reacts?
Power assist^X

 

[andrea_104kg]

Very excited to hear that and good to know what sensitivity level you are using! But also what you would prefer. I think it would be possible to improve the formula so eMTB is operating better and can fit your needs with only one assist mode. It should be great in any sensitivity level, that is the goal. Will consider everything you have said and think about it!

Hi Buba - potentially I missed it, but could you please explain the logic behind eMTB mode? It feels a bias toward torque at low rpm and then more toward power at higher rpm?

Anyway it is great. Successfully retired boost assist and also no random lags when starting off.

Hello Mctubster! Yeah, sure!

EDIT: Glad you like it and that you are satisfied with the 0.20.0!

eMTB is only based on pedal torque. So the more you push on the pedals the more current it will send to the motor. More current means more torque -> more assistance -> more power.

eMTB is similar to Torque Assist but there is one important difference. Below are some simplifications:

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

Torque Assist:

MotorCurrent = PedalTorque * AssistLevelMultiplier

Example:

8 AMPS = 5 NM * 1.6

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

eMTB Asssist

MotorCurrent = PedalTorque^X

Where X is a number between 1.3 and 2

Example:

8 AMPS = 5 NM ^ 1.3

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

That small difference makes it much easier to scale the input torque to the motor output torque. It is possible to setup so it gives normal assistance in normal conditions but as soon as you start pushing the pedals harder you will get a much higher percentage of assistance compared to Power Assist and Torque Assist.

If you are using Torque Assist you would have to push the pedals twice as hard for twice the motor torque. Contrary, with eMTB Assist, depending on sensitivity, you only have to push the pedals 20 % harder to get twice the motor power.

eMTB is not finished and will continually get better. Maybe even with pedal cadence added in the formula if that improves the feeling. I know for a fact that the values we have now can get much, much, better. The more feedback I get the faster we can improve it. Just knowing what sensitivity everyone is using can improve the feeling as we can rescale the formula and get to better values.

So if any user wishes to share some data just let me know what eMTB sensitivity you are using and I will use that to improve eMTB.

EDIT: Glad you like it and that you are satisfied with the 0.20.0!

now i understand why i don't like emtb. Following the logic of the original firmware which for me is really bad. couldn't you try the same logic on the power assist level to see how it reacts?
Power assist^X

 

[buba]

On the A5 I found that the voltage reported by the LCD3 compared to that
measured with the Tester is 0.4V lower.

How did you notice this? Can you confirm that it is only with the A5? Just checked with my battery and it shows the correct value.

Furthermore, today I finally tried the bike on a challenging mountain course,
along with other "real electric bikes" and the only big problem encountered was
the temperature that the engine reaches on medium-long climbs.
I had to make more than one stop and wait because the engine had reached 75 degrees
and had rightly cut off the assistance.

In addition to looking for a mechanical solution, is there any parameter you could try to
modify to keep the temperature lower without sacrificing power?

Casainho has already implemented a more quiet motor control with improved efficiency compared to the original firmware. Another very good developer called Frans-Willem has started improving the code by removing small errors and optimizing it (and much more!).

I have limited myself changing the FOC calculation in any meaningful way for the 0.20.0 as this needs to be validated and accurately measured. If I were to focus on the motor control I would dedicate one entire firmware release on that and concentrate on the efficiency and power but also field weakening. But I would assume that Casainho and maybe Frans-Willem are maybe planning on doing this in the future. A combined effort could increase the efficiency a couple of percent and thus result in less heat and more torque.

But in the end, the TSDZ2 will always be sensitive to heating. And going on long climbs is the worst thing you can do due to the combination of rolling friction, aerodynamic drag and the climb itself: you need to convert the energy in your battery to potential energy when climbing. And the faster you go the faster the conversion needs to happen and the more power you are pulling from the battery through the motor. And there is no way escaping that you need the power on those climbs. Which is a product of torque and angular velocity -> Torque means current -> Current means increased motor temperature.

So in short, I think it can be improved in the future. For now:

- Do not use the Experimental Motor modes as I think they are not as efficient
- Use a high nominal voltage battery. Your motor will be able to rotate faster in a lower gear and you could have the same power with less current but faster angular velocity. There is a small gain with higher voltages due to less transmission losses in cables and so on.
- Be as light as possible when climbing as this drastically reduces the power needed
- Maintain a low rolling resistance on the bike and keep drag at a minimum
- Reduce speed slightly as this also makes a big difference

All these suggestions have little effect on their own. But combined you might notice a small difference!

 

[buba]

eMTB is only based on pedal torque. So the more you push on the pedals the more current it will send to the motor. More current means more torque -> more assistance -> more power.

eMTB is similar to Torque Assist but there is one important difference. Below are some simplifications:

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

Torque Assist:

MotorCurrent = PedalTorque * AssistLevelMultiplier

Example:

8 AMPS = 5 NM * 1.6

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

eMTB Asssist

MotorCurrent = PedalTorque^X

Where X is a number between 1.3 and 2

Example:

8 AMPS = 5 NM ^ 1.3

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

That small difference makes it much easier to scale the input torque to the motor output torque. It is possible to setup so it gives normal assistance in normal conditions but as soon as you start pushing the pedals harder you will get a much higher percentage of assistance compared to Power Assist and Torque Assist.

If you are using Torque Assist you would have to push the pedals twice as hard for twice the motor torque. Contrary, with eMTB Assist, depending on sensitivity, you only have to push the pedals 20 % harder to get twice the motor power.

eMTB is not finished and will continually get better. Maybe even with pedal cadence added in the formula if that improves the feeling. I know for a fact that the values we have now can get much, much, better. The more feedback I get the faster we can improve it. Just knowing what sensitivity everyone is using can improve the feeling as we can rescale the formula and get to better values.

now i understand why i don't like emtb. Following the logic of the original firmware which for me is really bad. couldn't you try the same logic on the power assist level to see how it reacts?
Power assist^X

Would you mind elaborating why you do not like it so I can try and make it better? All suggestions are welcome so just let me know what you feel can be improved!

Do you mean that I should try and add cadence in the calculation similar to Power Assist? That might improve it but have gotten positive feedback so do not know if I should start changing things. But is this what you had in mind?

MotorCurrent = ( Torque*Cadence )^X

Where X is a value between 1.3 and 2?

EDIT: Just for clarification, neither Torque Assist nor eMTB follow the original firmware implementation. The original firmware is probably controlling the duty cycle so that is why it assists so heavily in the startup and then tapers off quickly. Torque Assist is only similar to the original firmware in that it does not require calibration, instead it uses whatever the torque value is from the ADC. The same is true for eMTB. But I think the torque calibration Casainho is planning to implement will be applicable on every riding mode so there will most likely be a chance the operating range will increase!

 

[casainho]

I have limited myself changing the FOC calculation in any meaningful way for the 0.20.0 as this needs to be validated and accurately measured.

There is a way you can change FOC without touching his code, that is by adding more calculations on the main loop making the code more slower. Let's say you did duplicate the complexity/processing the previous code of v0.19.0, then, FOC will be processed 2x slower and that would mean a loss of efficiency but I don't known how to measure it. But we know, that FOC algorithm is usually done every 64us and we try to done every 4ms (62.5x slower) because I think is impossible to do it faster on this microcontroller -- but if we do to much operations, then the 4ms will increase...

Are you able to measure the time that motor_controller(); is called? Should be at 4 ms and would be nice to measure it every version.

If FOC is not optimized, motor will heat faster, will have less torque and use more battery power.

 

[vadda]

On the A5 I found that the voltage reported by the LCD3 compared to that
measured with the Tester is 0.4V lower.

How did you notice this? Can you confirm that it is only with the A5? Just checked with my battery and it shows the correct value.

Ok, I'll test with another bike with A4 and let you know.

 

[vadda]

I have limited myself changing the FOC calculation in any meaningful way for the 0.20.0 as this needs to be validated and accurately measured.

There is a way you can change FOC without touching his code, that is by adding more calculations on the main loop making the code more slower. Let's say you did duplicate the complexity/processing the previous code of v0.19.0, then, FOC will be processed 2x slower and that would mean a loss of efficiency but I don't known how to measure it. But we know, that FOC algorithm is usually done every 64us and we try to done every 4ms (62.5x slower) because I think is impossible to do it faster on this microcontroller -- but if we do to much operations, then the 4ms will increase...

Are you able to measure the time that motor_controller(); is called? Should be at 4 ms and would be nice to measure it every version.

If FOC is not optimized, motor will heat faster, will have less torque and use more battery power.

Ok, are you saying that 0.19 could generate less heat on long climbs?

 

[casainho]

Ok, are you saying that 0.19 could generate less heat on long climbs?

We need to investigate and is difficult to evaluate.

Also, are you sure your motor is ok? are you sure it is not a bit demagnetized due to over heat??

 

[vadda]

Ok, are you saying that 0.19 could generate less heat on long climbs?

We need to investigate and is difficult to evaluate.

Also, are you sure your motor is ok? are you sure it is not a bit demagnetized due to over heat??

Yes, I'm sure
The motor Is pratically new a d i've just installerd the temperature sensor.
All my previous ride was in city Road.
Now I'm on holiday and have beautiful Mountain.

 

[bingo5]

Yes, I'm sure
The motor Is pratically new a d i've just installerd the temperature sensor.
All my previous ride was in city Road.
Now I'm on holiday and have beautiful Mountain.

I have the same problem (0.18 and 0.19) and i belive andrea_104kg too.

I think the motor is not suitable for long climbs at high assist. I have config that they dont use more as 9 amps (i have 48v motor and battery) and now i have no problem more. Its a bit shame because the motor sell with "750 Watt" and cannot deliver this for a longer time but that aside the motor and especially the firmware are very great

 

[vadda]

On the A5 I found that the voltage reported by the LCD3 compared to that
measured with the Tester is 0.4V lower.

How did you notice this? Can you confirm that it is only with the A5? Just checked with my battery and it shows the correct value.

Ok, I'll test with another bike with A4 and let you know.

On A4 the difference is very little, maybe just 0.1-0.2V max, but is difficult to evaluate because on the display the number changes too quickly.
Can confirm the 0.4V less on A5

 

[vadda]

Yes, I'm sure
The motor Is pratically new a d i've just installerd the temperature sensor.
All my previous ride was in city Road.
Now I'm on holiday and have beautiful Mountain.

I have the same problem (0.18 and 0.19) and i belive andrea_104kg too.

I think the motor is not suitable for long climbs at high assist. I have config that they dont use more as 9 amps (i habe 48v motor and battery) and now i have no problem more. Its a bit shame because the motor sell with "750 Watt" and cannot deliver this for a longer time but that aside the motor and especially the firmware are very great

Ok, I've the same configuraton 48V motor with 48V Battery.
Limiting the motor at 8A will deliver only about 450W, maybe for long climb will be good also if it deliver low speed, but on high ramp it will be absolutely not enough.
In my last ride I met ramps where I needed 700W, even if only for 300m
Anyway, motor like BROSE or BOSCH seem to not suffer from overheat issue.

 

[buba]

I have limited myself changing the FOC calculation in any meaningful way for the 0.20.0 as this needs to be validated and accurately measured.

There is a way you can change FOC without touching his code, that is by adding more calculations on the main loop making the code more slower. Let's say you did duplicate the complexity/processing the previous code of v0.19.0, then, FOC will be processed 2x slower and that would mean a loss of efficiency but I don't known how to measure it. But we know, that FOC algorithm is usually done every 64us and we try to done every 4ms (62.5x slower) because I think is impossible to do it faster on this microcontroller -- but if we do to much operations, then the 4ms will increase...

Are you able to measure the time that motor_controller(); is called? Should be at 4 ms and would be nice to measure it every version.

If FOC is not optimized, motor will heat faster, will have less torque and use more battery power.

I want to start of by saying that I would love to see some tests as I think this is very interesting!

We could put the interrupt in a loop and run it for X number of times and see what the execution time is. And then compare it to previous versions just to measure if there are any execution time differences. But we have to be careful so the compiler does not optimize away something in that. Have done this a couple of times in other situations but do not know if this is the best approach here.

Another test would be to switch a pin state and look at the frequency on the oscilloscope. And try comparing it between versions. That would be good because that enables us to run everything as normal without risking any compiler optimizations. I do not have a scope here at the time though.

The easiest would be a function call counter and calculating the average function call for every five seconds or so. The controller would send the function call number to the display. And we will be able to compare how many times the function was called the past X seconds. This would enable us to live test the motor in real conditions between different riding modes.

What do you think, Casainho? Should we make some tests and compare and what approach do you like?

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

These test would be interesting but I do hope nobody expects that it will make a considerable difference for heating as there will always be a certain inefficiency that is impossible to overcome. And the optimizations that can be made have the same effect on heating as removing less than a kg from the bike when climbing. But I do agree we should always try and implement code that is as efficient and clean as possible(!), I am obsessed with that.

 

[buba]

On the A5 I found that the voltage reported by the LCD3 compared to that
measured with the Tester is 0.4V lower.

How did you notice this? Can you confirm that it is only with the A5? Just checked with my battery and it shows the correct value.

Ok, I'll test with another bike with A4 and let you know.

On A4 the difference is very little, maybe just 0.1-0.2V max, but is difficult to evaluate because on the display the number changes too quickly.
Can confirm the 0.4V less on A5

I just checked the differences in code between A4 and A5 and there are no changes to the battery voltage measurement. The only related change between A4 and A5 is that it filters every 100 ms so the user will be able to see the value better on display. But should be the same steady state value.

Are you measuring at the charge port on the battery or battery discharge port? There might be differences depending on BMS. I will double check my battery and report back on this post if I have any differences between the meter and display on my bike!

EDIT: Tested and see a difference of 0.1 - 0.2 V on my bike, which should be the case and is normal. Please let me know if you find anything! And thank you for the fast feedback!

 

[buba]

Yes, I'm sure
The motor Is pratically new a d i've just installerd the temperature sensor.
All my previous ride was in city Road.
Now I'm on holiday and have beautiful Mountain.

I have the same problem (0.18 and 0.19) and i belive andrea_104kg too.

I think the motor is not suitable for long climbs at high assist. I have config that they dont use more as 9 amps (i habe 48v motor and battery) and now i have no problem more. Its a bit shame because the motor sell with "750 Watt" and cannot deliver this for a longer time but that aside the motor and especially the firmware are very great

Ok, I've the same configuraton 48V motor with 48V Battery.
Limiting the motor at 8A will deliver only about 450W, maybe for long climb will be good also if it deliver low speed, but on high ramp it will be absolutely not enough.
In my last ride I met ramps where I needed 700W, even if only for 300m
Anyway, motor like BROSE or BOSCH seem to not suffer from overheat issue.

That sounds really limiting and too bad you are experiencing that now when you are at a beautiful location and riding the bike

Are you at high altitudes? If you are then convection cooling is reduced by a lot! And the TSDZ2 will not dissipate heat as fast compared to riding at lower altitudes. This in combination with hot weather can cause some seriously fast heating.

(I think that the plan is to take a look at the FOC in the next versions and optimize it completely for the best possible efficiency and thereby least amount of heat. And maybe also implement field weakening for those that want more speed and can suffer the efficiency loss. Am noticeable very careful in saying how much of a difference this will make but it will maybe be noticeable in those climbs!)

 

[buba]

Now we are close to 40 ° and riding a bicycle is a real pain.

I noticed that the voltmeter in the 20 version marks 0.5 volts less. Is it a problem with my battery or has anything changed compared to previous versions?

Now I'm on holiday and have beautiful Mountains.

On the A5 I found that the voltage reported by the LCD3 compared to that
measured with the Tester is 0.4V lower.

Andrea_104kg mentioned in several posts back that he is experiencing a heat wave and that it is very hot where he rides his bike. And now Vadda as well is getting to high temperatures and maybe altitude changes that cause less heat dissipation.

What might be causing the discrepancy of accurate voltage measurement is the heat. The ADC is susceptible to offset drift or gain that a temperature change can cause. Not confirming this is the case but might be an explanation.

 

[bingo5]

These test would be interesting but I do hope nobody expects that it will make a considerable difference for heating as there will always be a certain inefficiency that is impossible to overcome. And the optimizations that can be made have the same effect on heating as removing less than a kg from the bike when climbing. But I do agree we should always try and implement code that is as efficient and clean as possible(!), I am obsessed with that.

Yes, i think the only really helpful way is a modification on the hardware (eg in the way they has andrea_104kg it done).
But maybe we can config the firmware so, that they limit the power to a specific power on a specific temperature? (eg to 6A if reach 65 °C or so). I know that "min. temperature" config, but its a not really working "black box" for me, because i dont know how it works in detail and i often run nevertheless in the hard limit.

And maybe the recommed hard limit (85°C) from casainho is a little bit lower then necessary, but i dont like to try more and risk a defect

 

[buba]

These test would be interesting but I do hope nobody expects that it will make a considerable difference for heating as there will always be a certain inefficiency that is impossible to overcome. And the optimizations that can be made have the same effect on heating as removing less than a kg from the bike when climbing. But I do agree we should always try and implement code that is as efficient and clean as possible(!), I am obsessed with that.

Yes, i think the only really helpful way is a modification on the hardware (eg in the way they has andrea_104kg it done).
But maybe we can config the firmware so, that they limit the power to a specific power on a specific temperature? (eg to 6A if reach 65 °C or so). I know that "min. temperature" config, but its a not really working "black box" for me, because i dont know how it works in detail and i often run nevertheless in the hard limit.

And maybe the recommed hard limit (85°C) casainho is a little bit lower then necessary but i dont like to try more and risk a defect

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.

 

[vadda]

Now we are close to 40 ° and riding a bicycle is a real pain.

I noticed that the voltmeter in the 20 version marks 0.5 volts less. Is it a problem with my battery or has anything changed compared to previous versions?

Now I'm on holiday and have beautiful Mountains.

On the A5 I found that the voltage reported by the LCD3 compared to that
measured with the Tester is 0.4V lower.

Andrea_104kg mentioned in several posts back that he is experiencing a heat wave and that it is very hot where he rides his bike. And now Vadda as well is getting to high temperatures and maybe altitude changes that cause less heat dissipation.

What might be causing the discrepancy of accurate voltage measurement is the heat. The ADC is susceptible to offset drift or gain that a temperature change can cause. Not confirming this is the case but might be an explanation.

I've not a BMS on my battery pack and the measurament was done with motor cold.
I'm on a little town at 450-500mt and the ride will arrive at 1000-1300mt over sea level.

Anyway I want to say tanks to you and @casainho for your big effort on this development.
The possibility of measure the temperature of motor and to correlate with the power delivered was a very
big improvement over stock kit.
And about overheating, in my first ride here in mountain I had the possibility to compare, on the same path, the behavior of my bike with 0.19 vs another bike with the original firmware and the difference was embarrassing, mine with the 0.19 was lukewarm and the one with the original FW was burning.

 

[vadda]

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.

 

[casainho]

The possibility of measure the temperature of motor and to correlate with the power delivered was a very
big improvement over stock kit.
And about overheating, in my first ride here in mountain I had the possibility to compare, on the same path, the behavior of my bike with 0.19 vs another bike with the original firmware and the difference was embarrassing, mine with the 0.19 was lukewarm and the one with the original FW was burning.

Very good to have this data. Thank you.

 

[buba]

What might be causing the discrepancy of accurate voltage measurement is the heat. The ADC is susceptible to offset drift or gain that a temperature change can cause. Not confirming this is the case but might be an explanation.

I've not a BMS on my battery pack and the measurament was done with motor cold.
I'm on a little town at 450-500mt and the ride will arrive at 1000-1300mt over sea level.

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.

That is a big climb! Almost 300 watt-hour needed just for the elevation change!

Anyway I want to say tanks to you and @casainho for your big effort on this development.
The possibility of measure the temperature of motor and to correlate with the power delivered was a very
big improvement over stock kit.
And about overheating, in my first ride here in mountain I had the possibility to compare, on the same path, the behavior of my bike with 0.19 vs another bike with the original firmware and the difference was embarrassing, mine with the 0.19 was lukewarm and the one with the original FW was burning.

Thank you, vadda! Appreciate it a lot and am glad to hear!

Credit to Casainho for developing the FOC and foundation to this development!