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

[stancecoke]

This is an ERPS, a mysterious unit

ERPS is not mysterious at all, this are the electrical revolutions per second of the motor, derived in the commutation algorithm. The chainwheel rpm is ERPS/(number of pole pairs * mechanical gear ratio) * 60s/min

regards
stancecoke

 

[r0mko]

This is an ERPS, a mysterious unit

ERPS is not mysterious at all, this are the electrical revolutions per second of the motor, derived in the commutation algorithm. The chainwheel rpm is ERPS/(number of pole pairs * mechanical gear ratio) * 60s/min

regards
stancecoke

Thanks! If we exclude mechanical gear ratio, should the motor RPM be divisible evenly by EPRS? I mean, the pole number should be a whole number, shouldn't it? I'm asking because of Casainho's post on Youtube:

550 ERPS somehow correspond to 4166 RPM. I don't get it. How many ERPS make up a whole turn of the motor shaft?

 

[arka]

I have two displays:
- older 850C (TFTGDV4A60 HHY.100 V5.2 201709142025)
- newer 850C (TFTGDV2.3CL60 HH2.0 V5.2 20190506 0104).
I can easily upload any custom firmware to the new 850C. I use bootloader to upload. I can't upload any of the newer firmware (v0.7.0, v0.6.0) to the old 850C every time the upload process gets 88% and "stop" pops up. I'm adding a video of how it looks like: https://youtu.be/ndjUOD9LYec. What's the problem if the latest display is the same as normal?

 

[stancecoke]

550 ERPS somehow correspond to 4166 RPM. I don't get it.

you are absolutely right, with 8 pole pairs you have to do 8 electrical revolutions for one mechanical revolution. 550ERPS/8*60s/min = 4125 rpm for the motor shaft.

https://en.wikipedia.org/wiki/Synchronous_motor#Synchronous_speed


regards
stancecoke

 

[casainho]

R0mko, thanks for the pull request solving the issue of motor type selection.

About the torque mode, if you make a pull request and with clean code, I will accept it. Since would be nice to have the same assist levels working, maybe on torque mode we could consider a fixed cadence of 50 RPM which is about half of max cadence.

About the current ramp, it is configurable directly on the display, so, no need for any custom firmware. BUT not that there is the pwm cycles delay limit that my be limiting the current ramp max value... You need to account on that or the value you choose for current ramp will not happen. And be careful, developing like this you will easily burn a motor controller, motor, blue gear, etc.

About the ERPS, the motor rotor has 16 magnets, so, 8 poles, so each 1 rotor RPS equals to 8 ERPS.
Note that limit of 525 ERPS is because at least the voltage phases should have 25 points to be draw otherwise, the motor will be less efficient and have less torque - for the same amount of battery power. You need to evaluate also the efficiency and not only the amount of speed and torque, because battery range / efficiency is important!!

 

[casainho]

I have two displays:
- older 850C (TFTGDV4A60 HHY.100 V5.2 201709142025)
- newer 850C (TFTGDV2.3CL60 HH2.0 V5.2 20190506 0104).
I can easily upload any custom firmware to the new 850C. I use bootloader to upload. I can't upload any of the newer firmware (v0.7.0, v0.6.0) to the old 850C every time the upload process gets 88% and "stop" pops up. I'm adding a video of how it looks like: https://youtu.be/ndjUOD9LYec. What's the problem if the latest display is the same as normal?

I would say that then the old hardware version has a limit on the firmware size. The 850C I have/had (about 7 units) and 860C 3 units, all of them have the same microcontroller with the same memory size and so that is the reason why I never hit that limit.

If you need to buy new ones, go to the 860C because is clearly better to be seen on the outside, which is really important!!

 

[r0mko]

R0mko, thanks for the pull request solving the issue of motor type selection.

You're welcome. There's another one for the display FW: https://github.com/OpenSource-EBike-firmware/Color_LCD/pull/89

About the current ramp, it is configurable directly on the display, so, no need for any custom firmware. BUT not that there is the pwm cycles delay limit that my be limiting the current ramp max value... You need to account on that or the value you choose for current ramp will not happen. And be careful, developing like this you will easily burn a motor controller, motor, blue gear, etc.

I personally find that 10A/sec current ramp is way too conservative, so I decided to make it more aggressive to allow faster acceleration. For example, dropping a gear even at 10 A/sec leads to quite long loss of assist. In my opinion, the current ramp is good for soft start to reduce stress on gears and chain. In my opinion, as the motor is already spinning at decent speed, we don't need to limit its current change over time. I believe that there's no problem if at 2000 RPM (267 ERPS) we increase current from 5A to 16A just instantly. But this needs to be checked.

Note that limit of 525 ERPS is because at least the voltage phases should have 25 points to be draw otherwise, the motor will be less efficient and have less torque - for the same amount of battery power. You need to evaluate also the efficiency and not only the amount of speed and torque, because battery range / efficiency is important!!

I totally agree that efficiency is a primary goal. But having a possibility to reach high RPM occasionally is also important. One doesn't usually ride at high cadence all the time, so the numbers over 80 RPM are actually achieved only over short periods of time during overtakes or harsh accelerations. I think that feeling of confidence is worth sacrificing of a couple of Wh.

About the torque mode, if you make a pull request and with clean code, I will accept it. Since would be nice to have the same assist levels working, maybe on torque mode we could consider a fixed cadence of 50 RPM which is about half of max cadence.

I think I'll need to test it a bit more. I am also thinking of combining the both approaches. For example, we can introduce a setting for a percentage of torque sensing vs. power sensing. For example, at 0% the motor calculates the target current purely based on torque, and at 100% we use only pedal power. We need to calculate the target current in both ways simultaneously and then mix values according to the proportion. I guess, this can be a nice replacement of startup boost feature which is, to be honest, a bit cumbersome to set up.

Thank you for your answer.

 

[arka]

I have two displays:
- older 850C (TFTGDV4A60 HHY.100 V5.2 201709142025)
- newer 850C (TFTGDV2.3CL60 HH2.0 V5.2 20190506 0104).
I can easily upload any custom firmware to the new 850C. I use bootloader to upload. I can't upload any of the newer firmware (v0.7.0, v0.6.0) to the old 850C every time the upload process gets 88% and "stop" pops up. I'm adding a video of how it looks like: https://youtu.be/ndjUOD9LYec. What's the problem if the latest display is the same as normal?

I would say that then the old hardware version has a limit on the firmware size. The 850C I have/had (about 7 units) and 860C 3 units, all of them have the same microcontroller with the same memory size and so that is the reason why I never hit that limit.

If you need to buy new ones, go to the 860C because is clearly better to be seen on the outside, which is really important!!

Unfortunately, due to the epidemic, getting any 850C in Poland is not possible So it is not possible to upload new firmware versions to older 850C (TFTGDV4A60 HHY.100 V5.2 201709142025)? Then which last version will be possible to install on this old display?

 

[casainho]

I have two displays:
- older 850C (TFTGDV4A60 HHY.100 V5.2 201709142025)
- newer 850C (TFTGDV2.3CL60 HH2.0 V5.2 20190506 0104).
I can easily upload any custom firmware to the new 850C. I use bootloader to upload. I can't upload any of the newer firmware (v0.7.0, v0.6.0) to the old 850C every time the upload process gets 88% and "stop" pops up. I'm adding a video of how it looks like: https://youtu.be/ndjUOD9LYec. What's the problem if the latest display is the same as normal?

I would say that then the old hardware version has a limit on the firmware size. The 850C I have/had (about 7 units) and 860C 3 units, all of them have the same microcontroller with the same memory size and so that is the reason why I never hit that limit.

If you need to buy new ones, go to the 860C because is clearly better to be seen on the outside, which is really important!!

Unfortunately, due to the epidemic, getting any 850C in Poland is not possible So it is not possible to upload new firmware versions to older 850C (TFTGDV4A60 HHY.100 V5.2 201709142025)? Then which last version will be possible to install on this old display?

Try by yourself.

 

[Brlowe]

My system has been switched to an 860C with the latest 0.7.0 firmware.
First let me say the new firmware has solved the surge issue coming out of settings.
New issue.
In setting under motor temp I am not able to just set min and max values. It acts like there are preset numbers and the only way to cycle thru them is to hit the power button over and over until you get a value near what you want. If you use the up and down arrows and pick a number when you hit the power button to accept it the value drops to the next preset number.

Is this a feature or an issue?

 

[casainho]

R0mko, thanks for the pull request solving the issue of motor type selection.

You're welcome. There's another one for the display FW: https://github.com/OpenSource-EBike-firmware/Color_LCD/pull/89

Ok, I will include on next version soon, I already implemented the following and I am now testing and cleaning the code:
- display: automatic battery resistance measurement
- display: set wheel speed to 0 at startup
- TSDZ2: coast brake negative torque
- TSDZ2: solve overrun issue
- display: used Wh must be editable
- display: quick set max power
- display: street legal / offroad modes

This is my TODO:
- cruise
- virtual throttle
- disable sensors (because some of them can get faulty)
- increase max cadence limit
-- increase PWM frequency
-- implement field weakening

I personally find that 10A/sec current ramp is way too conservative, so I decided to make it more aggressive to allow faster acceleration. For example, dropping a gear even at 10 A/sec leads to quite long loss of assist. In my opinion, the current ramp is good for soft start to reduce stress on gears and chain. In my opinion, as the motor is already spinning at decent speed, we don't need to limit its current change over time. I believe that there's no problem if at 2000 RPM (267 ERPS) we increase current from 5A to 16A just instantly. But this needs to be checked.

I agree, I also would like to have faster response on some situations.

Note that limit of 525 ERPS is because at least the voltage phases should have 25 points to be draw otherwise, the motor will be less efficient and have less torque - for the same amount of battery power. You need to evaluate also the efficiency and not only the amount of speed and torque, because battery range / efficiency is important!!

I totally agree that efficiency is a primary goal. But having a possibility to reach high RPM occasionally is also important. One doesn't usually ride at high cadence all the time, so the numbers over 80 RPM are actually achieved only over short periods of time during overtakes or harsh accelerations. I think that feeling of confidence is worth sacrificing of a couple of Wh.

I also agree and sometimes I feel the need of a bit more cadence over the 90 RPM. But my plan is:

Increase max cadence limit:
1. increase PWM frequency
2. implement field weakening

Implementing 1. would mean small loss of efficiency, I think it is loss because of more switching per time and that will make probably the mosfets to here more. Anyway, should be way better than reducing the number of points.
Having 1. would be great and for users with 14S or 15S batteries would be really good!! (considering the 48V motor).

2. Would be nice to have, would bring value mostly for users of 13S batteries or others when they more discharged... (considering the 48V motor).

WARNING: we have few memory available on TSDZ2 motor controller firmware as also very low processing speed available so all this will be hard to implement.

About the torque mode, if you make a pull request and with clean code, I will accept it. Since would be nice to have the same assist levels working, maybe on torque mode we could consider a fixed cadence of 50 RPM which is about half of max cadence.

I think I'll need to test it a bit more. I am also thinking of combining the both approaches. For example, we can introduce a setting for a percentage of torque sensing vs. power sensing. For example, at 0% the motor calculates the target current purely based on torque, and at 100% we use only pedal power. We need to calculate the target current in both ways simultaneously and then mix values according to the proportion. I guess, this can be a nice replacement of startup boost feature which is, to be honest, a bit cumbersome to set up.

So you agree that not human power mode and not torque mode are perfect, all of them have disadvantages.

I prefer human power because I always drive more dynamic, I stand up at startup to give my own boost while get the same boost from TSDZ2.
My wife have a city bicycle where she prefer to have the startup boost because she doesn't like to stand up at startups and not even change gears, so, she needs a big boost from TSDZ2 at startup. That is why I would like to keep startup boost as also because I remember other users did mention to use it and did not like when it was removed on V0.20 version.
But I agree it is difficult to setup... and if you see, the startup boost is more or less what you say you would like to implement.... you have a time window for boost where the torque value only is used and after you have another time window where the first assist merges/fade to the human power. What could change on your implementation would be not defining the time window duration but instead the cadence middle point transition, like at which point of cadence value the assist is half based on torque and the other half based on human power.

 

[casainho]

My system has been switched to an 860C with the latest 0.7.0 firmware.
First let me say the new firmware has solved the surge issue coming out of settings.

Good to know!! that was a dangerous issue.

New issue.
In setting under motor temp I am not able to just set min and max values. It acts like there are preset numbers and the only way to cycle thru them is to hit the power button over and over until you get a value near what you want. If you use the up and down arrows and pick a number when you hit the power button to accept it the value drops to the next preset number.

I can replicate. It works as expected to me, just like other settings, it increases/decreases 1 unit a time.

 

[Brlowe]

My system has been switched to an 860C with the latest 0.7.0 firmware.
First let me say the new firmware has solved the surge issue coming out of settings.

Good to know!! that was a dangerous issue.

New issue.
In setting under motor temp I am not able to just set min and max values. It acts like there are preset numbers and the only way to cycle thru them is to hit the power button over and over until you get a value near what you want. If you use the up and down arrows and pick a number when you hit the power button to accept it the value drops to the next preset number.

I can replicate. It works as expected to me, just like other settings, it increases/decreases 1 unit a time.

I have my temp set for imperial. The up and down increment it 1 step at a time until I press the power button to set the value and then it jumps to a different value. Did you do it on an 860c? I will video it and send a video to you email or I can try to post it here.

 

[plpetrov]

Ok, I will include on next version soon, I already implemented the following and I am now testing and cleaning the code:
- TSDZ2: coast brake negative torque

Casainho, I did some more tests today.

1. Testing coaster braking while walk assist 1 is active.
I was expecting motor to stop as in normal assist modes. This does not happen. Tested several times with different walk assist levels.
2. On the power burst issue. I noted the values I see on the display for the torque sensor for one full revolution. Rotating by hand with almost zero effort. The max value is 145 when the left pedal is at 15 to 10 degrees before the top position and the lowest value is 135 when the left pedal horizontal, 45 degrees rotation after the top positon. I don’t know if this is coincidence but the power burst is initiated by the max value and is gone as soon as we reach the minimum value. Looking at the human power I see also a burst from 0 or 1 to 10 in the sector where the values of the torque sensor are highest. The value of 10 is for assist level 13.
While doing the same test at different assist levels I see that the human power shown is increased with the increase of the assist level. Is this the intended behavior? My expectations are that it will stay the same.
I don’t know how you are correcting the calculated torque value using the calibration values. Is it possible that for the lower values close to 0 that the correction is not working correctly and the motor to accept the jump from 135 to 145 as condition to accelerate? And in the very high assis levels to go to almost uncontrollable power burst?
Maybe we need some normalisation or smoothing under some condition of the torque sensor values before feeding them in the motor control loop.

 

[7lucky7]

Hi this is a really dumb question. But what happens if you flash the new firmware to the motor and just plug it into the old vlcd5 display???

I only really want the controls you can get on that one but am interested in the better management of the motor and the increase in RPM available with open source

 

[r0mko]

This is my TODO:
- cruise
- virtual throttle

Interesting. Could you please share your thoughts?
I also have several feature requests.

• average consumption for current trip (Wh/km) and overall
• total energy consumption
• recharge cycles counter
• remaining capacity in kilometres (or miles)
• either not reset trip distance on each on/off cycle, but on battery charge, or
• introduce another distance meter: distance since last charge

implement field weakening

Very interesting, I didn't know that this is possible with BLDC motor with permanent magnets. In short words, how is it made?

So you agree that not human power mode and not torque mode are perfect, all of them have disadvantages.

Not quite. Perhaps I would go for like 75-80% torque and 25-20% power to make motor a bit more lively at high RPM, but overall I'm pretty happy with torque-only control mode, I like to have some weight on pedals, but I admit that some riders may want higher assistance at higher cadence. To fulfil everyone's needs, I propose to make such an adjustment.

 

[r0mko]

Hi this is a really dumb question. But what happens if you flash the new firmware to the motor and just plug it into the old vlcd5 display???

I only really want the controls you can get on that one but am interested in the better management of the motor and the increase in RPM available with open source

None of both will work. VLCD5 doesn't understand the TSDZ2 OSF protocol, and the motor never gets initialised because it expects a very specific data packet from the display.

 

[7lucky7]

Hi this is a really dumb question. But what happens if you flash the new firmware to the motor and just plug it into the old vlcd5 display???

I only really want the controls you can get on that one but am interested in the better management of the motor and the increase in RPM available with open source

None of both will work. VLCD5 doesn't understand the TSDZ2 OSF protocol, and the motor never gets initialised because it expects a very specific data packet from the display.

Thanks!! Guess I'll be buying an 860C then!

 

[Brlowe]

So you agree that not human power mode and not torque mode are perfect, all of them have disadvantages.

I see this a couple posts up, I did not write this. LOL

 

[vshitikov]

This is my TODO:
-- increase PWM frequency

I think this may help to make whole control very reactive, however your interrupt handler is already 66% loaded (as you have written in the comments)so you don't get much to speedup.

 

[casainho]

Ok, I will include on next version soon, I already implemented the following and I am now testing and cleaning the code:
- TSDZ2: coast brake negative torque

Casainho, I did some more tests today.

1. Testing coaster braking while walk assist 1 is active.
I was expecting motor to stop as in normal assist modes. This does not happen. Tested several times with different walk assist levels.
2. On the power burst issue. I noted the values I see on the display for the torque sensor for one full revolution. Rotating by hand with almost zero effort. The max value is 145 when the left pedal is at 15 to 10 degrees before the top position and the lowest value is 135 when the left pedal horizontal, 45 degrees rotation after the top positon. I don’t know if this is coincidence but the power burst is initiated by the max value and is gone as soon as we reach the minimum value. Looking at the human power I see also a burst from 0 or 1 to 10 in the sector where the values of the torque sensor are highest. The value of 10 is for assist level 13.
While doing the same test at different assist levels I see that the human power shown is increased with the increase of the assist level. Is this the intended behavior? My expectations are that it will stay the same.
I don’t know how you are correcting the calculated torque value using the calibration values. Is it possible that for the lower values close to 0 that the correction is not working correctly and the motor to accept the jump from 135 to 145 as condition to accelerate? And in the very high assis levels to go to almost uncontrollable power burst?
Maybe we need some normalisation or smoothing under some condition of the torque sensor values before feeding them in the motor control loop.

I will make a new release and maybe these issues will keep there (I fixed an issue but maybe has no impact):

- void ui16_limit_max(uint8_t *ui16_p_value, uint8_t ui16_max_value)
+ void ui16_limit_max(uint16_t *ui16_p_value, uint16_t ui16_max_value)
{
  if (*ui16_p_value > ui16_max_value) { *ui16_p_value = ui16_max_value; }
}

I will make this release and then I hope we can solve this issues, including the ones for coast brake version BUT I don't have one, I really need your help.

Can you please configure the pedal to start at right side and then test to see if the same happens?

About smoothing, I did a code to always sample the max value (could be sampling always at the point we calibrate the torque sensor) of each side and then use it but it was a lot slow, you see, at low cadence = very low reaction / signal change. Maybe this could be used at high cadence... or like that idea of a fade from 100% regular signal and 0% smooth signal at 10 cadence and the contrary at cadence 80. All this ideas are nice but they will consume the very limited processing speed that I would prefer to use for having higher cadence up to 110 RPM.

About 1., maybe I need to put torque sensor signal available as a variable that can be seen on the main screen, so, you can run with assist level and check what torque sensor value can happen.

 

[casainho]

This is my TODO:
- cruise
- virtual throttle

Interesting. Could you please share your thoughts?
I also have several feature requests.

• average consumption for current trip (Wh/km) and overall
• total energy consumption
• recharge cycles counter
• remaining capacity in kilometres (or miles)
• either not reset trip distance on each on/off cycle, but on battery charge, or
• introduce another distance meter: distance since last charge

So cruise to be just the same has on V0.20 because it is implemented on the motor firmware I think, it should be now an implementation on the display side only.

Virtual throttle is an idea that may not work in practice but I would like to try, using UP and DOWN buttons to work as a throttle, a bit like how assist level works now, keeping pressing the button to maintain the feature active and quick click/change button to increase or decrease throttle value. Safety is that user must keep button pressed and if communications fail fo 0.8s, the motor controller already turns of the motor.

I think all that new variables would be nice to have. On the 850C we have plenty on flash memory available but SW102 has less.

There is one variable that I would like to have much including available to graph, the average consumption for current trip (Wh/km). This value would include on the calculation the battery current, battery voltage and battery resistance. The more current you ask, the more you use and it is not linear because the losses on the battery depends on P = I * I * R. On my battery I have a loss of 20% if I am pulling 15 amps from the battery - no problem for city rides but a problem for long trips on weekends and I use the same bicycle and same battery, so, I would like much to have this including on the graph.

The available range could consider the previous x minutes, that could be configured by the user (including minutes from previous ride).

implement field weakening

Very interesting, I didn't know that this is possible with BLDC motor with permanent magnets. In short words, how is it made?

It is possible, there are a lot of documentation about FOC and field weakening. But I don't know how to implement, even on this so very limited processing power that is left. But anything like a raw approximation can be more than enough on our case, I did the same for KT motor controller FOC implementation and I think is really great!! I just had the hardware in front of me and I knew the chinese engineers could done FOC with this very simple hardware of 1 current sensor only and 8 bits 16 MHZ microcontroller!!

This is the evaluation I did of FOC and no FOC on the firmware I did implemented for KT motor controllers:

FOC, at high current and speed measurement, phase voltage aligned 90 degrees with magnetic flux (hall sensors signal):

No FOC, at high current and speed measurement, phase voltage NOT aligned/not controlled 90 degrees with magnetic flux (hall sensors signal):

See here a lot of good documentation:
https://opensourceebikefirmware.bitbucket.io/development/Motor_control.html

So you agree that not human power mode and not torque mode are perfect, all of them have disadvantages.

Not quite. Perhaps I would go for like 75-80% torque and 25-20% power to make motor a bit more lively at high RPM, but overall I'm pretty happy with torque-only control mode, I like to have some weight on pedals, but I admit that some riders may want higher assistance at higher cadence. To fulfil everyone's needs, I propose to make such an adjustment.

Could we have both and let user configure that amount of mixing instead of selecting one or the other?

 

[r0mko]

So you agree that not human power mode and not torque mode are perfect, all of them have disadvantages.

Not quite. Perhaps I would go for like 75-80% torque and 25-20% power to make motor a bit more lively at high RPM, but overall I'm pretty happy with torque-only control mode, I like to have some weight on pedals, but I admit that some riders may want higher assistance at higher cadence. To fulfil everyone's needs, I propose to make such an adjustment.

Could we have both and let user configure that amount of mixing instead of selecting one or the other?

That's exactly what I proposed to do a couple of posts earlier:

For example, we can introduce a setting for a percentage of torque sensing vs. power sensing. For example, at 0% the motor calculates the target current purely based on torque, and at 100% we use only pedal power. We need to calculate the target current in both ways simultaneously and then mix values according to the proportion.

 

[skestans]

Out of curiosity: can the firmware be downgraded on the 850C? Or even the original firmware put back?

This is of interest in case a current release has a major bug. I and probably others rely on their bikes to be fully functional at all times to run errands, go to work, etc. Without the possibility of downgrading, a bugged release makes the bikes unusable until a fix is released.

 

[vshitikov]

Out of curiosity: can the firmware be downgraded on the 850C? Or even the original firmware put back?

This is of interest in case a current release has a major bug. I and probably others rely on their bikes to be fully functional at all times to run errands, go to work, etc. Without the possibility of downgrading, a bugged release makes the bikes unusable until a fix is released.

yes there is a bootloader on the display so it can be rolled back.