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

[buba]

Buba

Im still having a problem getting my head around cadence mode, surely there is more than a cadence input from the way it is behaving.

I'm running on a Nexus 8 speed hub gear and 48v motor, 52 volt battery Max 18 amps and 800 watts set. To get any decent response I need the cadence assist set at 90 and more. Go up a gentle slope near my home at 10mph in 3rd gear it starts off with decent assist and soon settles to about 11 watts assist and then I change gear to 6 or 8 and suddenly I've nearly got 300 watts assist and to maintain 10mph I am ghost pedalling. Going back down the slope everything seems normal in any gear with hardly any assist. Then as I turn into the rutted lane up to my place pedalling very slowly in gear 8 the assist is suddenly 500 watts or more (which I don't want ). Is there also a wheel speed and torque input into this mode?

Hmm... So when you configure an assist level multiplier in Cadence Assist it will actually set the target rotational speed of the motor. If the motor rotates slower it will increase power until the rotational speed increases. If the motor rotates faster it will lower the power. So if you change gears this will upset the ratio and you need to change assist level accordingly. The system does not know that the ratio has changed.

Just thought that this implementation works fine on direct drive motors as the ratio is fixed (hub motor) but is maybe not as optimal where the ratio changes with gear shifts. How does the Bafang compare when shifting gears? Have never tried cadence only assist on a mid drive before. How do you configure the Bafang and how does it react when removing the wheel speed sensor? Does it work the same with and without the wheel speed sensor?

We are only looking at cadence in Cadence Assist but I understand why you were surprised by the difference in assistance!

The bafang motor is somewhat different in how it feels to ride. the Assist levels are set to fix the maximum power and set cadence speed to run at, so as you move up the assistance levels you are increasing the cadence in set amounts.

Its nice for cruising but you do tend to use the assist levels with the gears more, change up gears and sometimes you have to drop the assist level to lower the cadence to suite.
If you remove the speed sensor it makes no difference at all to how the motor reacts, I know this for sure at i had to ride over 200KM with no speed sensor the other week after my tyre melted the speed cable sensor wire right through!

changing gear is somewhat vicious! and a gear sensor really helps to calm this down, or using the gentle ebrake method to activate the ebrake when changing gear without pulling the lever enough to actually brake.

all in the bafang rides in a very constant fashion, providing a set amount of power continuously as long as you pedal, but if you want to change cadence you have to increase the assist level or you will be pushing against the motor.

These are my settings in the bafang config tool on my towing bike running a BBS 02 (350W motor running up to 20A so 720W peak but does not feel as powerful at the TSDZ2 at 500W)

you can see how I have changed the cadence speed to increase with the power.

Wow! This just goes to show how something as simple as assist enabled by cadence can get complicated and is not as trivial as one would assume. I really do appreciate your detailed post explaining how it works and what you think of it.

The very first implementation of Cadence Assist I did was a simple power level selector. You simply selected the assist level and it constantly maintained the power configured in that assist level. So if you had assist level 4 set to 200 W of power it constantly assisted you that much. No matter what speed you were at.

But during startups I thought that users needed more assistance. Something we solve by applying slightly more torque in the torque based modes. But this is obviously not possible with Cadence Assist. Later on, when up to speed, the assistance was too strong. The feeling was very constant. So, less assistance at speed is preferable.

So what is the natural implementation of this? The motor duty cycle target. With that implementation it will naturally assist more at startups, when you need more assistance, and assist less when at speed. But again, the problem is that if we shift gears it offsets everything. Something we are experiencing now.

 

[buba]

I have a little problem.
In the Odometer Field (Main Screen Setup 7/1) the motor temperature is not displayed. In the Temperature field (Main Screen Setup 10/1) the temperature is displayed. However, I would like to use this field for the 10/2 Battery state of charge in percent. Do others have the same problem or have I set something wrong?
Thank you

Actually yes , Not tried this before but on 0.20.0 Alpha 2 I have the same issue. cannot select option 7 to show temperature in Odometer field.

I will take a look at it and solve it for the next Alpha!

EDIT: solved and will be included in the next Alpha!

 

[buba]

I think the motor should be runnable without a display after setting these parameters up once.

Technically that would be possible but would also compromise the implementation of future new features as also possible need corrections/maintenance of current features (for the reasons I did explain).

Current project is to run TSDZ2 with feature rich LCDs like 850C and SW102 Bluetooth. On SW102 Bluetooth for instance, the developers seek to send data to Strava.

Having the TSDZ2 running without LCD is another project -- need to have other developers for developing and maintain that project.

hm, i still don't get it. The code is already there, why is there a need for another project or somebody to maintain this special scenario?

If i get it right, the eeprom is filled with some default variables if the first byte is not "our key". And these variables are loaded at every bootup. As soon as the display is sending its data, all these variables are overwritten. The function eeprom_write_if_values_changed is still commented out. I think this is just a design flaw. Why do we have to write the actual assist-level to the eeprom?

Thats why i opened the Ticket #30 at github back than... Imho there is still a need to split the variable in two separate ones. One for persistent data that can be written to the eeprom and the second one for "runtime data" like the current assit level, or light-status or stuff like that...

Or did i miss something else here?

Casainho, regarding the post from shaddi,

Would you mind if I rewrite the motor controller with just runtime variables? As the motor controller should default to some pre-configured values and only change those values when receiving parameters from the display. It would make no difference for the development of the other displays but would instead make things neater, take up less space and maybe even safer overall.

We actually do not need to save anything in the motor controller EEPROM. We are not saving anything in the 0.19.0 or any other version before that. And I am certainly not saving anything in the 0.20.0. So we do not need the struct of "configuration_variables".

 

[buba]

I have a big problem. When i load controller file i see a long 'address 0xxxxx isi out of range' . I can programming but when start the lcd3 not work all field are light. Why? I traied to fill with zero but nothing change.

Have you set the STM8S105x6 on ST Visual Programmer? What version are you trying to load?

If anyone ever gets the "Address our of range..." it will not work as ST Visual Programmer is warning that it could not load the entire hex file on the device. Make sure that you have picked the right device: STM8S105x6.

Sorry for the late reply, you have maybe already sorted it out by now!

Thank you! In fact I was wrong and used x4 for flash roms!
now everything works perfectly! I did a little test ride:
Power assist works as before only it is even more progressive and sensitive, very beautiful!
Torque assist is for real cyclists, not for me! It seemed to me more tiring but it seems to me much better than the original engine. I think it's the most real emulation of a normal bicycle!
Cadence mode does not interest me, not because of the lack of respect for your work, but because I have 3 other bikes with hub engines and I don't want another one.

Great that it worked!

Thank you for noticing that the resolution and control is much finer! That was very rewarding to implement and I really think there is a big difference on that front.

Also to work very little on the road I use a little trick: I put street mode at 350w, I use 9 levels (max 5x), when I use level 9 I have the advantage of a very light pedal (5x) but with power limited to 350w. It is sufficient for medium climbs with zero fatigue and great battery saving.

There is a slight resistance backwards to the ignition which then disappears after a few rides.

Will test!

It's better than the hub and even better than the Specialized Turbo Levo.
I thought it was impossible to improve the excellent version 19 but you did it!
Emtb: I don't like it, I think that tsdz2 is already emtb because of its intrinsic characteristics.
However an exceptional job .... thanks!

Very kind feedback from you! Glad you feel it is an improvement and I hope you get some nice rides with the 0.20.0!

 

[casainho]

Casainho, regarding the post from shaddi,

Would you mind if I rewrite the motor controller with just runtime variables? As the motor controller should default to some pre-configured values and only change those values when receiving parameters from the display. It would make no difference for the development of the other displays but would instead make things neater, take up less space and maybe even safer overall.

We actually do not need to save anything in the motor controller EEPROM. We are not saving anything in the 0.19.0 or any other version before that. And I am certainly not saving anything in the 0.20.0. So we do not need the struct of "configuration_variables".

I think would be even safer to force user enter on the configurations menu once on LCD and then only send the configurations to the motor controller after this condition.
Motor controller would only run the motor after receiving for at least one first time the configurations, everytime after power up or after user enter and leave the configurations menu.

Having run-time variables without any preconfigured value is the most optimized for not using the programming memory.

Maybe you can say how much memory in being used right now on the motor controller from the available 32 kbytes.

 

[Demion]

hm, i still don't get it. The code is already there, why is there a need for another project or somebody to maintain this special scenario?

If i get it right, the eeprom is filled with some default variables if the first byte is not "our key". And these variables are loaded at every bootup. As soon as the display is sending its data, all these variables are overwritten. The function eeprom_write_if_values_changed is still commented out. I think this is just a design flaw. Why do we have to write the actual assist-level to the eeprom?

Thats why i opened the Ticket #30 at github back than... Imho there is still a need to split the variable in two separate ones. One for persistent data that can be written to the eeprom and the second one for "runtime data" like the current assit level, or light-status or stuff like that...

Or did i miss something else here?

Casainho, regarding the post from shaddi,

Would you mind if I rewrite the motor controller with just runtime variables? As the motor controller should default to some pre-configured values and only change those values when receiving parameters from the display. It would make no difference for the development of the other displays but would instead make things neater, take up less space and maybe even safer overall.

We actually do not need to save anything in the motor controller EEPROM. We are not saving anything in the 0.19.0 or any other version before that. And I am certainly not saving anything in the 0.20.0. So we do not need the struct of "configuration_variables".

Is initializing all m_configuration_variables from default defines on start is bad approach? Would it take much programming memory?
This way it will work without display if need, display will overwrite everything on uart_receive_package if used and will not mess with EEPROM.

Update : on second thought it will be no much use for regular user, who is using KT-LCD3 / 850C. More suited for marcoq configuratoror or my similar approach fork.
If shaddi wants to connect display to configure once from time to time and then run without display, then all settings should be saved EEPROM anyway.

Update2: what would be difference between runtime data and persistent data? Only runtime data I see is assist level and lights state (maybe also riding mode for new alpha) all other data should be saved in EEPROM and to run without display you should also save last assist level anyway.

 

[casainho]

Is initializing all m_configuration_variables from default defines on start is bad approach? Would it take much programming memory?
This way it will work without display if need, display will overwrite everything on uart_receive_package if used and will not mess with EEPROM.

Update : on second thought it will be no much use for regular user, who is using KT-LCD3 / 850C. More suited for marcoq configuratoror or my similar approach fork.
If shaddi wants to connect display to configure once from time to time and then run without display, then all settings should be saved EEPROM anyway.

Again, this project is to run TSDZ2 with feature rich LCDs like 850C and SW102 Bluetooth. As there are features yet to be implemented that will bring value to users, this will need memory and everything that does not bring value to users of this project, should be removed.

 

[Demion]

Again, this project is to run TSDZ2 with feature rich LCDs like 850C and SW102 Bluetooth. As there are features yet to be implemented that will bring value to users, this will need memory and everything that does not bring value to users of this project, should be removed.

Agreed. That what I meant by update.
After giving it second thought I also see no much sense saving data to EEPROM or even partial "persistent" data, cause anyway almost all configs need to be saved to run it without display, for example.
And I dont see other real use for saving data on controller.
I guess it is only suitable for forks when all configs are hard coded (changeable manually or using configurator) at compile time.

Just was thinking out loud. Thanks, casainho, for your, buba and other developers work.

 

[buba]

Would you mind if I rewrite the motor controller with just runtime variables? As the motor controller should default to some pre-configured values and only change those values when receiving parameters from the display. It would make no difference for the development of the other displays but would instead make things neater, take up less space and maybe even safer overall.

We actually do not need to save anything in the motor controller EEPROM. We are not saving anything in the 0.19.0 or any other version before that. And I am certainly not saving anything in the 0.20.0. So we do not need the struct of "configuration_variables".

I think would be even safer to force user enter on the configurations menu once on LCD and then only send the configurations to the motor controller after this condition.
Motor controller would only run the motor after receiving for at least one first time the configurations, everytime after power up or after user enter and leave the configurations menu.

As it is now the motor controller will do nothing at all unless the display is sending exactly the right command and is continuing to do so. Meaning that we actively need to enable the motor to assist us. I think this is extremely safe. Compare it to Walk Assist and how it only works if we actively tell it to run.

Combine this with solid communication and I think we are good with safety.

Having run-time variables without any preconfigured value is the most optimized for not using the programming memory.

Having runtime variables initialized to a value, not using the EEPROM in any way, minimizing structs and discarding all other instructions needed for the implementation we have today will be the best for programming memory.

Again, we actually do not need the EEPROM on the motor controller unless we are planning to constantly connect and disconnect displays to the motor controller.

I gave a suggestion that we could use a display to configure the controller and then remove it. Then we would need the EEPROM. But in that case it is better to just have a configuration program. Much faster and neater.

Just want to check with you so there is no confusion, would you mind if I made it so everything is based on runtime variables?

Maybe you can say how much memory in being used right now on the motor controller from the available 32 kbytes.

Yes, we are at 77 % used up and therefore 23 % left.

 

[buba]

Just was thinking out loud. Thanks, casainho, for your, buba and other developers work.

Is initializing all m_configuration_variables from default defines on start is bad approach? Would it take much programming memory?
This way it will work without display if need, display will overwrite everything on uart_receive_package if used and will not mess with EEPROM.

Update : on second thought it will be no much use for regular user, who is using KT-LCD3 / 850C. More suited for marcoq configuratoror or my similar approach fork.
If shaddi wants to connect display to configure once from time to time and then run without display, then all settings should be saved EEPROM anyway.

Update2: what would be difference between runtime data and persistent data? Only runtime data I see is assist level and lights state (maybe also riding mode for new alpha) all other data should be saved in EEPROM and to run without display you should also save last assist level anyway.

Seeing as we are not using the EEPROM for anything other than taking up space it would be best to just make runtime variables. Just as you suggested and that is what I wish to do. If someone wishes to use the TSDZ2 without a display it will be possible to use a configuration program or just change the defines. In all other cases there will be something communicating with the motor controller and overwriting the defines.

EDIT: Just to add to the overall discussion:

Even if there is no display we can still change some states and values. By having e-brakes installed we can replicate button presses. Three very quick engagements on the brake sensor toggles the lights or changes riding mode. Rotating the pedals backwards above a certain speed for a certain time will enable/disable Street Mode.

This is not something I am working on or trying to convince anyone is useful but am only sharing this to emphasize that there is no reason whatsoever to use the EEPROM and everything should be runtime.

 

[Demion]

Having runtime variables initialized to a value, not using the EEPROM in any way, minimizing structs and discarding all other instructions needed for the implementation we have today will be the best for programming memory.

Again, we actually do not need the EEPROM on the motor controller unless we are planning to constantly connect and disconnect displays to the motor controller.

I gave a suggestion that we could use a display to configure the controller and then remove it. Then we would need the EEPROM. But in that case it is better to just have a configuration program. Much faster and neater.

Just want to check with you so there is no confusion, would you mind if I made it so everything is based on runtime variables?

Seeing as we are not using the EEPROM for anything other than taking up space it would be best to just make runtime variables. Just as you suggested and that is what I wish to do. If someone wishes to use the TSDZ2 without a display it will be possible to use a configuration program or just change the defines. In all other cases there will be something communicating with the motor controller and overwriting the defines.

Sounds perfect to me.
I was not even paying attention EEPROM is not being actually used right now.
That exact way, you described (using only runtime variables), it should not take too much programming memory, I believe, and should be satisfactory for everyone.
Only thing will not be possible is using display to configure once and then use without display.
But that feature is not worth spending memory (will require config saved in EEPROM), cause project is meant to run with 850C / SW102, as casainho mentioned.
Still will be possible to configure manually or using configurator software (at compile time), as you said.
Also I think you were referring to new alpha ui8_riding_mode set by default to OFF_MODE which will assure safety, motor not running without display command.
Thanks for hard work again.

 

[buba]

Sounds perfect to me.
I was not even thinking about EEPROM is not being actually used right now.
That exact way, you described (using runtime variables), it should not take too much programming memory I believe and should be satisfactory for everyone.
Only thing will not be possible is using display to configure once and then use without display.
But that feature is not worth spending memory (will require config saved in EEPROM), cause project is meant to run with 850C / SW102, as casainho mentioned.
Still will be possible to configure manually or using configurator software (at compile time), as you said.
Also I think you were referring to new alpha ui8_riding_mode set by default to OFF_MODE which will assure safety, motor not running without display command.
Thanks for hard work again.

Nothing to add except that I think we can solve everything but we just need to agree what the best next step is. You are completely correct! It is also set to OFF_MODE after every loop unless the communication package from the display changes it to one of the riding modes. So if the display freezes it will automatically just turn off the motor assistance.

Cool that you are looking through the code and please let me know if there is anything you would change or if you have any suggestions!

 

[casainho]

Having run-time variables without any preconfigured value is the most optimized for not using the programming memory.

Having runtime variables initialized to a value, not using the EEPROM in any way, minimizing structs and discarding all other instructions needed for the implementation we have today will be the best for programming memory.

I am pretty sure that every initialization value (other than 0) takes programing memory so we need to avoid it if possible.

Maybe you can say how much memory in being used right now on the motor controller from the available 32 kbytes.

Yes, we are at 77 % used up and therefore 23 % left.

So I think we are in red zone because I think we should let 10% free for maintenance, then only 13% is left. I want to implement at least more 4 features:
- torque sensor full calibration
- configuration to disable PAS, torque sensor, brake sensor or wheel speed sensor, so in case of a failing while riding far from home we can still use the ebike
- field weakening to increase motor max RPM of current 4000
- password protection as used on KT-LCD3 and 850C LCDs original firmware but here the password paired with the motor controller

I think the 13% will not be enough for that 4 features and I am sure we will have other features in the list, like improving motor errors to give user more feedback of system state, etc.

So, we are on red zone already, we need to save every byte possible on the motor controller firmware.

 

[shaddi]

Would you mind if I rewrite the motor controller with just runtime variables? As the motor controller should default to some pre-configured values and only change those values when receiving parameters from the display. It would make no difference for the development of the other displays but would instead make things neater, take up less space and maybe even safer overall.

every other system is doing it like this. So if its up to me, yes, please

I think would be even safer to force user enter on the configurations menu once on LCD and then only send the configurations to the motor controller after this condition.
Motor controller would only run the motor after receiving for at least one first time the configurations, everytime after power up or after user enter and leave the configurations menu.

sorry, but i only partly agree with that. You always mention safety-reasons or when some of the components break in the field. What if your display, the cable or the connector between them breaks in the field? You than have no assistance at all...

I don't want to use the system without a display but i want that the components do their defined job without any unneccesary dependency.

As it is now the motor controller will do nothing at all unless the display is sending exactly the right command and is continuing to do so. Meaning that we actively need to enable the motor to assist us. I think this is extremely safe. Compare it to Walk Assist and how it only works if we actively tell it to run.

Combine this with solid communication and I think we are good with safety.

I don't see any safety-gain in a design where we force-pushing the whole configuration over and over again. Yes, for the first-time use the user should parameterize the system for his needs but after that, the parameters should be stored in the device that it uses. Max motor-current is nothing interesting for a display but for the controller its essential.

Having run-time variables without any preconfigured value is the most optimized for not using the programming memory.

Yes, you are right with this. But if we are so low on space, i think there are some other functions that should be optimized. I think the whole serial-communication should be rewritten. There is no need that the controller is hammered with incoming data with information it already knows.

Imho the serial-communication to the controller should be only active if something changes. If the user changes assist-level or after editing the configuration parameters. While normal operation, the only communication should be from the controller to the display, pushing realtime informations like wheel-speed, motor-current and so on.

 

[casainho]

sorry, but i only partly agree with that. You always mention safety-reasons or when some of the components break in the field. What if your display, the cable or the connector between them breaks in the field? You than have no assistance at all...

I am being talking about the things that already did happen to me and not things that may be very unlike to happen. Still, if the cable breaks and there is no power to motor controller, nothing will helps.

Having run-time variables without any preconfigured value is the most optimized for not using the programming memory.

Yes, you are right with this. But if we are so low on space, i think there are some other functions that should be optimized. I think the whole serial-communication should be rewritten. There is no need that the controller is hammered with incoming data with information it already knows.

The whole serial is simplistic and following original firmware. I understand your suggestion but I am also pretty sure being a more complex will use more programing memory. And yes, I think it should be done because configurations will increase for the features I did listed, and, the memory needed will increase even on the current serial code.

I think other developers should fork and do that other project if they want to use no LCD or other things, and I am pretty sure they will end up having maybe less one feature because of that.

 

[perryscope]

One thing I just noticed, I put the throttle on the marcoq firmware, after using the throttle, I could no longer use the pedals to activate the motor.

Anyone have a link to the stock firmware? As I could try flashing that, to reset everything.

If it helps here is a link to my own Stock firmware files pulled from my own 36V TSDZ2

https://drive.google.com/open?id=1GKX5xDY556mt4usDwPv0EQV9VYnE-WJ_

I have uploaded these firmware files to two separate 36V units to sanity test them back as stock and they work for me. If your motor is a 48V version maybe not a good idea to use these

Other stock downloads I have found are linked to from here..

https://www.eco-ebike.com/blogs/eco-cycles-instructionals/tsdz2programmingfromscratch

 

[btslo]

Is there any progress on the SW102 front? (I understand some other user made significant progress with that display)

 

[casainho]

Is there any progress on the SW102 front? (I understand some other user made significant progress with that display)

Please follow the github SW102 repository and then you will receive the notes from the developers. They are very active and I think in 2 or 3 days there may be an alpha version but that should be tested only by the ones that do not depend on a good working ebike.

 

[cnrd]

I know this is a long shot, but anyone here who can measure the continuity between the different pins on a KT-LCD3?

As except for the P+ pin, all the other pins on mine have a 0.24 Ohm resistance between them.

 

[casainho]

I know this is a long shot, but anyone here who can measure the continuity between the different pins on a KT-LCD3?

As except for the P+ pin, all the other pins on mine have a 0.24 Ohm resistance between them.

Or you are measuring incorrectly or there is a short-circuit on them.

 

[chri27.5]

Buongiorno,
sto leggendo ogni singolo commento di tutti, e trovo molte idee diverse, ognuno vorrebbe una cosa personalizzata, credo che il lavoro fatto fin ora sia superlativo, Buba casainho sono fantastici, però cosa ci si può aspettare di più di quello che è stato fatto?
Se pensiamo a una eMTB nativa dal livello software nulla si può fare e tutto confezionato, l'unica cosa è l'up sullo smartphone che gestisce le assistenze,
allora per accontentare tutti mi è venuta in mente di usare una scheda bluetooth Raspberry e interfacciata con Tsdz2 e smartphone, secondo voi sarebbe possibile?
Sarebbe secondo me l'unico modo per accontentare tutti.
Grazie

 

[cnrd]

I know this is a long shot, but anyone here who can measure the continuity between the different pins on a KT-LCD3?

As except for the P+ pin, all the other pins on mine have a 0.24 Ohm resistance between them.

Or you are measuring incorrectly or there is a short-circuit on them.

That's what I'm trying to figure out, I may have destroyed the display when I soldered the connectors. Anyways I ordered a second display, as I checked and double checked all the wiring, and everything checks out.

 

[perryscope]

I know this is a long shot, but anyone here who can measure the continuity between the different pins on a KT-LCD3?

As except for the P+ pin, all the other pins on mine have a 0.24 Ohm resistance between them.

Just tested mine hope this helps..

GND and TX 4.22M
GND and RX 4.22M
GND and P+ Open circuit
GND and PL 32K

I agree with casainho it does look like you have some dead shorts there between pins.

 

[nbdriver]

Thanks buba for the answer about flashing .ihx, indeed it is working like a .hex file.
I tested the bike this morning to work, and everything went great, felt smoother and more reactive (Advanced cadence enabled and calibrated, thanks to your video :thumb.

Just something confusing is that we have to configure a power limit (new) in Basic setup, and a max current (as before). These two settings are doing the same thing for me because if i want to limit motor power to 576w i set current to 12Amp (12amp x 48v) and so on. I agree that it is more convenient for the end user to have a power limit in watts, and not having to calculate it by himself

But it can also be confusing because if i have a current limit at 10Amps (48V battery) and a power limit set at 550Watts i suppose that i will not be able to reach that limit because current limit would have priority, am i right ?

And also, i don't understand the difference between Power mode and torque mode, as it is always a multiplier of human input. What is the advantage of using one instead of the other ?

last question, in the wiki, section Power Assist we find :
"The assist level multipliers sets the motor power as a factor of the power the rider is generating at the crankshaft. For instance, if a multiplier is set to 2.0 the motor will assist with 100 watts if the human power generated at the crank shaft is 100 watts."

Is it not with a multiplier of 1.0 that the motor should give 100W if the rider gives 100W ? it seems more logic to me to multiply the human power by a factor to find the motor power, i always understood the multiplier this way.

Thank you for this wonderful work, and i will update my impressions and findings. Also i'm still available to translate wiki to french, this would make the firmware accessible for more people.

 

[casainho]

Just something confusing is that we have to configure a power limit (new) in Basic setup, and a max current (as before). These two settings are doing the same thing for me because if i want to limit motor power to 576w i set current to 12Amp (12amp x 48v) and so on. I agree that it is more convenient for the end user to have a power limit in watts, and not having to calculate it by himself

That 2 configurations have different purposes.

Max current may be a value depending on the limit of your battery package or motor controller (you may want to limit this if you don't have the temperature sensor installed or other reasons).

Max power should be configured quickly not leaving the main screen and may be useful when you want limit the max power usage, like managing battery range on a long trip or want a fixed max power level from the motor like on a specific trip or part of it.

This must be explained on wiki or will bring confusion as you say.