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

[marcoq]

Thancks marcoq for your contribution ...

Firmware tested with VLCD5 and seem to work fine .

As there is not many people in france that are using TSDZ2, i put the endless-sphere informations on my blog .
https://elementaire01.blogspot.com/2018/12/open-source-firmware-tsdz2-tongsheng.html

Thank you elem for your contribution!

 

[tomtom50]

TSDZ2 too little assist if you have a high cadence

There is no easy way to up the cadence I'm afraid with the standard motor direct from the factory, it is a pain for any body who cycles a lot and has a slightly more higher cadence than you average commuter. Do consider though to simply revise your riding style to a lower more torque based cadence which once you get used to simply using a larger gear and slower cadence is OK

There are a number of routes to up its cadence however.

1/ change the voltage from 36volt to 48 volt but you will need to change the base voltage levels in the motor Epprom as the 36 volt unit will not work with simply upping the voltage. There are a number of video links on these pages as how you do this.
2/ Change the motor firmware to what is now called the OpenSource firmware. Casainho and with the help of others has implemented a better firmware which makes the use of specialist software to allow the cadence to rise and the efficiency of the engine improve. At this stage you will also need to change the LCD to another type LCD3 or the latter colour 850C.
3/ Wait a bit, there are others working on taking that OpenSource firmware and incorporating it into the standard LCD display.

I think the info from Waynamarlow is good, I'll try to re-state with more detail (let me know if I have the concepts wrong)

If your cadence is on the high side and TSDZ2 assist is limited you can:

1. Run a 36V motor with a 48V or 52V battery and 48V or 52V stock firmware (sometimes called overdrive). The 36V motor is wound to develop more rpm per V, and running it a higher voltage raises effective cadence. If you have a 48V or 52V system you can swap motors. If you have a 36V system you can re-flash with 48V or 52V firmware and use a 48V or 52V battery. If you haven't bought yet you can buy an "overdrive" system
https://www.eco-ebike.com/collections/tongsheng-tsdz2/products/tsdz2vlcd5

https://www.eco-ebike.com/blogs/eco-cycles-instructionals/tsdz2programmingfromscratch
has the stock firmware and good instructions for making the connections. Warning: changing the voltage settings may not be enough. I had to completely re-flash the firmware. Eyebyesickle has a good video in this post
https://endless-sphere.com/forums/viewtopic.php?f=28&t=79788&p=1398908#p1398895.

2. Open source firmware can be installed, this let's you configure battery voltage, etc. However higher cadence is not yet well supported unless you are running a 36V motor at higher voltage.
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Usage-and-configuration-of-firmware-version-0.17.x
8: Various
submenu 0
2 for experimental high cadence mode (only available in version 0.14.3 and up). Maybe not good for the motor, use at your own risk. Probably only suitable for 36 V motors.

jbalat recently posted
E:\Data\Other\ZFP-85Q\My System Notes\Notes on my system\Bicycle\ebike\Tongsheng TSDZ2 Torque Sensor\Firmware & ST-Link V2\Open Source Firmware\KT-LCD3\Open Source Firmware Hex file\High cadence
"I just installed version 16 on my friends bike and he wanted a high cadence version like mine.
His motor is 48v, so this version below will work on both motor types
He tested it for a minute or so and was quite happy. All I did was changed increased the motor speed cutoff limit and multiplied the normal FOC by about 1.4 to bring it in line with the 36v settings."
Interesting, but not supported in the standard open source firmware.

As far as I can tell there is no established method to increase cadence that doesn't involve running a 36V motor at a higher voltage. If you do go to the trouble of configuring such a system I'm not sure if the open source experimental mode 2 is better than running 48V or 52V stock firmware on a 36V motor.

 

[Rydon]

Thancks marcoq for your contribution ...

Firmware tested with VLCD5 and seem to work fine .
...

Thank you elem for your contribution!

This is awesome news. It means existing TSDZ2 conversions can be upgraded by just unplugging the Speedo sensor and flashing the controller. The LCD3 and 850C displays are a much better solution but now those short on time, money, or soldering skills can enjoy this amazing firmware upgrade using stock displays. Thanks to everyone that has contributed! Oh, and Happy New Year! 2019 will be the year that thousands begin to benefit from the Flexible Opensource Firmware for TSDZ2.

 

[thineight]

Regarding casainho's Master Project and marcoq "fork" I performed a side by side comparison between their codes (just a file compare, unfortunately my knowledge on chip programming is limited ).
I understood that there are 2 main topic covered by marcoq's work:
1) Walk assist
2) Implemented compatibility with stock displays (plus the ongoing interface tool for programming variables)

From my personal point of view both the two are interesting and worth to be considered for merging into the Master project, but let's focus on 1 piece at time.

Walk assist
The new main code for the walk assist should be in the ebike_app.c file from marcoq (please correct me if I'm wrong)
https://github.com/qmarco/TSDZ2-Smart-EBike-compatible-with-original-VlCD6-display
Since it was reported that the funcion actually works, is it possible from any of the experts (possibly marcoq who knows the logic behind) to generate a pull request and get it merged into the main project?
After this, i guess the only major bug left to solve is the backwards resistance. :thumb:

Stock display compatibility
Considering the improved flexibility due to the visual interface to program the motor/bike settings (ongoing from marcoq) I think we should consider the option to implement the flag to include also the stock displays and let the user chose what to do.
What do you think?

In case, for easier reference I found that the modified files are the following.

brake.c
config.h
ebike_app.c //should contain also the main code for walk assist
ebike_app.h
eeprom.c
eeprom.h
main.c
main.h
motor.c - in this file @row #726 i guess there is a mistake on marcoq code (see below)
____marcoq : ui8_temp = ui8_svm_table [(uint8_t) (ui8_svm_table_index + 85 /* 120º */)];
____casainho: ui8_temp = ui8_svm_table [(uint8_t) (ui8_svm_table_index + 85 /* 120º */)];
motor.h
pins.h
uart.c

At the moment I have 2 bikes with the TSDZ2 and I purchased one LCD3 display to try the new firmware.
Now I received all the hardware needed (display, programmer, brake sensors) and I will update the controller + display on the first bike as soon as v.0.17 is out (buba's modifications are really cool).
As I'm sure the firmware is great I would like to implement it also on the 2nd bike, for which I did not buy any additional display, therefore marcoq solution plus his java tool for configuration should be perfect for my VLCD5 display.

Please share your thoughts on the possible integration of marcoq walk assist and stock display compatibility in the main project.

Thanks

 

[elem]

gone with my second bike to V0.16 and lcd3 display, must check in real if all work fine .
As the controleur of this bike dont want to be modified i used my spare controleur ( from witch i got the display connector to do the programming cable ) and soldered the lcd3 cable directly in then controleur ( as an other italian do in this forum ) .
I haven t flashed LCD3 with last firmware ( my fault ) but V0.16, and true , it was a pain to change some parameter, must change to v0.17 because it s better to cycle than multiple click :lol:

the one using marcoq code now with a 11S battery and data memory slowly modified .
walk assist tested with 3 lvl, working but too slow, i must check how modifie .
changing whell perimeter work, but as in the stock firmware 5% more speed than real .
assist lvl always too strong for my use, must modify data memory .

test report :

0x004001 : 03 ( default value assist level factor x10 )
0x004003 : 16 amp = 10 ( default value battery max current )
0x004004 : 270W = 27 = 1B ( default value motor max power x10 )
0x004005 : 31.9 = 319-256 = 63 = 3F ( default value battery low voltage cut off x10 00 )
0x004006 : 256 = 01 ( default value battery low voltage cut off x10 01 )
0x00400E : 11= 0B ( battery nombre de cells )
0x004013 : 03 = 03 ( lvl 1 )
0x004014 : 07 = 07 ( lvl 2 ) [ 06 to be tested ]
0x004015 : 15 = 0F ( lvl 3 ) [ 12 to be tested ]
0x004016 : 30 = 1E ( lvl 4 ) [ 25 to be tested ]
0x004020 : 550w/25 = 22 ( max batt power div 25 )

1 > slow pedaling 1.23Ap 84.9Wp
1 > strong pedaling 4.75Ap 208Wp
2 > moderate 9.6Ap 412Wp
2 > strong pedaling 12.66Ap 531Wp
3 > 14.79Ap 618Wp ( at final 44.38V )

loss first barre 43.8V

 

[linklemming]

0x004013 : 03 = 03 ( lvl 1 )
0x004014 : 07 = 07 ( lvl 2 ) [ 06 to be tested ]
0x004015 : 15 = 0F ( lvl 3 ) [ 12 to be tested ]
0x004016 : 30 = 1E ( lvl 4 ) [ 25 to be tested ]
0x004020 : 550w/25 = 22 ( max batt power div 25 )

I am using your proposed assist multipliers (4 levels of 0.3,0.6,1.2,2.4).

I came up with the 0.3 number by doing the same 3 mile flat section on my non-ebike at a known heartrate and noticed the speed/gear. Then over the course of 3 rides, did the same on my tsdz2 bike and 0.3 seemed to be as close as I could get.

I find these levels perfect for me and I played around with this quite a bit.

Im mostly at 0.6 and 1.2 depending on mood/wind. I use 2.4 when I want to keep speed over 23mph or just want to get home.

Im using a 52V battery and 48V motor.

 

[buba]

Here is a video update on the new time measurement functions in the KT-LCD3 display. This is code that will hopefully be merged soon in a version 0.17 beta and then released in the stable version 0.17. The pull request is submitted.

TM = Corresponds to number of seconds and minutes passed since powered on display. Simply called Time Measurement. It is resettable during a trip without turning off the display. Reset is done by CLICK followed by CLICK HOLD on DOWN button until the time is reset.

TTM = Corresponds to number of minutes and hours since last user reset. Simply called Total Time Measurement. It is also resettable by CLICK followed by CLICK HOLD on DOWN button until the time is reset.

Menu 6: This is the new menu for time measurement. Here you can switch between displaying TM or TTM and also reset the respective measurements. In this menu either minutes or hours passed are displayed in the odometer field, depending on user choice of measurement function.

[youtube]yiLTL3g1LW8[/youtube]

 

[Ron Paul's Blimp]

Please share your thoughts on the possible integration of marcoq walk assist and stock display compatibility in the main project.

My thoughts are at https://www.endless-sphere.com/forums/viewtopic.php?f=30&t=93818&start=1450#p1434080

I still intend to try to bring the oem display support into casainho's tree (assuming casainho and marcoq are okay with that), but I haven't had any time to work on it yet (still getting my bike build sorted out).

 

[marcoq]

Please share your thoughts on the possible integration of marcoq walk assist and stock display compatibility in the main project.

My thoughts are at https://www.endless-sphere.com/forums/viewtopic.php?f=30&t=93818&start=1450#p1434080

I still intend to try to bring the oem display support into casainho's tree (assuming casainho and marcoq are okay with that), but I haven't had any time to work on it yet (still getting my bike build sorted out).

I think that if casainho agrees, the two projects could be integrated, so you would get a single project that can satisfy all users of the forum.

 

[thineight]

I think that if casainho agrees, the two projects could be integrated, so you would get a single project that can satisfy all users of the forum.

Well, we understand that casainho is actually focused with the display 850c task now, therefore he his happy when other bugs or improvements are sorted one at the time via pull request (as buba did for the rev. 0.17 betas).

As far as I remember from previous pagese he said that the walk assist was not on its priority now but he would be more than happy if someone with the code (marcoq) could make the pull request for final implementation.
I guess the walk assist can be easily merged into the master project: marcoq, if you could carry the walk assist on you shoulder (pull request) would be great, grazie mille :wink:

Regarding the stock display compatibility, casainho was initially a bit reluctant due to the poor/difficult user customization compared to the LCD3/850c solution. The new setup/programming interface by marcoq plus looks to me the good trade off to make everyone happy: both LCD3/850c advanced display users and minimal/stock display users.
For this to be officially implemented in the master we need of course casainho's final blessing.

 

[zappan]

Thanks again and congratulations to Marcoq, I installed your software TSDZ2_Controller_vM0.16.0 - "Flexible OpenSource 0.16 by Casainho" on a bike with Display XH 18 LCD and works perfectly.

 

[zappan]

I know it's off topic and I apologize, but turning on the network I found this Italian bike equipped with Bosch engine FOC http://www.supersoco.it/specifiche/ , which is the beginning of the revolution?

 

[marcoq]

Regarding casainho's Master Project and marcoq "fork" I performed a side by side comparison between their codes (just a file compare, unfortunately my knowledge on chip programming is limited ).
I understood that there are 2 main topic covered by marcoq's work:
1) Walk assist
2) Implemented compatibility with stock displays (plus the ongoing interface tool for programming variables)

From my personal point of view both the two are interesting and worth to be considered for merging into the Master project, but let's focus on 1 piece at time.

Walk assist
The new main code for the walk assist should be in the ebike_app.c file from marcoq (please correct me if I'm wrong)
https://github.com/qmarco/TSDZ2-Smart-EBike-compatible-with-original-VlCD6-display
Since it was reported that the funcion actually works, is it possible from any of the experts (possibly marcoq who knows the logic behind) to generate a pull request and get it merged into the main project?
After this, i guess the only major bug left to solve is the backwards resistance. :thumb:

Stock display compatibility
Considering the improved flexibility due to the visual interface to program the motor/bike settings (ongoing from marcoq) I think we should consider the option to implement the flag to include also the stock displays and let the user chose what to do.
What do you think?

In case, for easier reference I found that the modified files are the following.

brake.c
config.h
ebike_app.c //should contain also the main code for walk assist
ebike_app.h
eeprom.c
eeprom.h
main.c
main.h
motor.c - in this file @row #726 i guess there is a mistake on marcoq code (see below)
____marcoq : ui8_temp = ui8_svm_table [(uint8_t) (ui8_svm_table_index + 85 /* 120º */)];
____casainho: ui8_temp = ui8_svm_table [(uint8_t) (ui8_svm_table_index + 85 /* 120º */)];
motor.h
pins.h
uart.c

At the moment I have 2 bikes with the TSDZ2 and I purchased one LCD3 display to try the new firmware.
Now I received all the hardware needed (display, programmer, brake sensors) and I will update the controller + display on the first bike as soon as v.0.17 is out (buba's modifications are really cool).
As I'm sure the firmware is great I would like to implement it also on the 2nd bike, for which I did not buy any additional display, therefore marcoq solution plus his java tool for configuration should be perfect for my VLCD5 display.

Please share your thoughts on the possible integration of marcoq walk assist and stock display compatibility in the main project.

Thanks

Thanks thineight for reporting... but the error was introduced by my editor in the comment and not in the code ... so the firmware has not been altered.

 

[marcoq]

Hello casainho.
In the motor.c file at line 290 I noticed that ui8_sin_table has a length of 256 (SVM_TABLE_LEN) ... it should not be long 60 (SIN_TABLE_LEN)?
Thanks, have a good day.

 

[casainho]

Regarding the marcoq fork and request to accept pull request

The bellow message serves as a good example of what I am looking for. I plan to implement more complete walk assist than the one on the original firmware (as I already described before) and marcoq fork, I plan a walk assist that depends heavily on the user interaction on the LCD and not a just turn on/off.

I started this firmware to have advanced features and customization that are usually only present on expensive motor and big brands only.

I understand that using original LCD and marcoq fork is a quick and cheap way to have TSDZ2 running with our flexible OpenSource firmware, but the full potential of our firmware can only be realized when using KT-LCD3 or the Bafang 850C color LCD(when the firmware is finished), because some advanced features depends heavily from that LCDs, they can't simple work using the original LCD.

It is very hard to develop features and keep always thinking in the two very different possibilities: LCD running our OpenSource firmware AND original LCD. Because having the project with all that possibilities would compromise the quality (more risks for bugs, more complex project, more hardware to test, etc) and because my resources are very limited, I prefer to keep the project as it is right now -- it works very well only on LCDs that runs our OpenSource firmware.

My suggestions for you guys are:
1. for the ones looking for a smaller LCD, port the KT-LCD3 firmware to the small KT-LCD5 (similar type of VLCD6) - this LCD has a very similar hardware of KT-LCD3 so porting the firmware should be fast and cheap.
2. for the ones looking for a quick and cheap solution, fork the firmware and start a new project. I will be happy to put a link to that new project and borrow any code that I will need.
I am very happy to see so many developers on this project!! I wish there was as many on the firmware I also started for KT motor controllers: https://endless-sphere.com/forums/viewtopic.php?f=30&t=87870

Regarding casainho's Master Project and marcoq "fork" I performed a side by side comparison between their codes (just a file compare, unfortunately my knowledge on chip programming is limited ).
I understood that there are 2 main topic covered by marcoq's work:
1) Walk assist
2) Implemented compatibility with stock displays (plus the ongoing interface tool for programming variables)

From my personal point of view both the two are interesting and worth to be considered for merging into the Master project, but let's focus on 1 piece at time.

Walk assist
The new main code for the walk assist should be in the ebike_app.c file from marcoq (please correct me if I'm wrong)
https://github.com/qmarco/TSDZ2-Smart-EBike-compatible-with-original-VlCD6-display
Since it was reported that the funcion actually works, is it possible from any of the experts (possibly marcoq who knows the logic behind) to generate a pull request and get it merged into the main project?
After this, i guess the only major bug left to solve is the backwards resistance. :thumb:

Stock display compatibility
Considering the improved flexibility due to the visual interface to program the motor/bike settings (ongoing from marcoq) I think we should consider the option to implement the flag to include also the stock displays and let the user chose what to do.
What do you think?

In case, for easier reference I found that the modified files are the following.

brake.c
config.h
ebike_app.c //should contain also the main code for walk assist
ebike_app.h
eeprom.c
eeprom.h
main.c
main.h
motor.c - in this file @row #726 i guess there is a mistake on marcoq code (see below)
____marcoq : ui8_temp = ui8_svm_table [(uint8_t) (ui8_svm_table_index + 85 /* 120º */)];
____casainho: ui8_temp = ui8_svm_table [(uint8_t) (ui8_svm_table_index + 85 /* 120º */)];
motor.h
pins.h
uart.c

At the moment I have 2 bikes with the TSDZ2 and I purchased one LCD3 display to try the new firmware.
Now I received all the hardware needed (display, programmer, brake sensors) and I will update the controller + display on the first bike as soon as v.0.17 is out (buba's modifications are really cool).
As I'm sure the firmware is great I would like to implement it also on the 2nd bike, for which I did not buy any additional display, therefore marcoq solution plus his java tool for configuration should be perfect for my VLCD5 display.

Please share your thoughts on the possible integration of marcoq walk assist and stock display compatibility in the main project.

Thanks

 

[casainho]

Hello casainho.
In the motor.c file at line 290 I noticed that ui8_sin_table has a length of 256 (SVM_TABLE_LEN) ... it should not be long 60 (SIN_TABLE_LEN)?
Thanks, have a good day.

Yes, probably.

Since you are looking at that code, what would be the BEST improvement is the FOC Field Weaking -- would you like to think on that??

https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/issues/11

I think the idea is that we keep FOC working and get the best efficiency possible:

// 36V motor: L = 76uH
// 48V motor: L = 135uH
// ui32_l_x1048576 = 142; // 1048576 = 2^20 | 48V
// ui32_l_x1048576 = 80; // 1048576 = 2^20 | 36V

BUT when we approach the ERPS speed limit (and/or duty_cycle starts decreasing ???), we should adding a phase advance value so we start to loss efficiency but we get more motor speed, over the nominal max speed of 4000RPM/450ERPS.

I think by now you already have some good experience with this values... maybe we can figure out an algorithm to do this. And we can start by something very simple, like doing some iterations (increasing/decreasing of the angle offset until we get the motor_speed_erps we are looking for).

 

[thineight]

Thanks thineight for reporting... but the error was introduced by my editor in the comment and not in the code ... so the firmware has not been altered.

Not sure I understood correctly: I found the "wrong" line in your motor.c code inside the zipped file and I presume it is the one that will be compiled when needed.. should we change that line back to the original casainho version?
I am trying to carefully put all the pieces together because I will set up one bike with the LCD3 (following the master project) and the second with the VLCD5.

 

[casainho]

v0.17.0-beta5 is available here, please test and give feedback:

https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.17.0-beta5

Changes:

- implemented automatic fast increase/decrease of variables on configuration menus
- settable odometer
- trip distance function
- imperial units throughout the system
- saved menu state for all menus when power down
- flashing time on menu number and variables is now short -- it is easier to see the values
- TM and TTM time measurement

This beta release of firmware for KT-LCD3 works with the same previous TSDZ2 v0.16.0 firmware version:
- TSDZ2-throttle-v0.16.0.hex
- TSDZ2-v0.16.0.hex

 

[thineight]

Regarding the marcoq fork and request to accept pull request

The bellow message serves as a good example of what I am looking for. I plan to implement more complete walk assist than the one on the original firmware (as I already described before) and marcoq fork, I plan a walk assist that depends heavily on the user interaction on the LCD and not a just turn on/off.

I started this firmware to have advanced features and customization that are usually only present on expensive motor and big brands only.

I understand that using original LCD and marcoq fork is a quick and cheap way to have TSDZ2 running with our flexible OpenSource firmware, but the full potential of our firmware can only be realized when using KT-LCD3 or the Bafang 850C color LCD(when the firmware is finished), because some advanced features depends heavily from that LCDs, they can't simple work using the original LCD.

It is very hard to develop features and keep always thinking in the two very different possibilities: LCD running our OpenSource firmware AND original LCD. Because having the project with all that possibilities would compromise the quality (more risks for bugs, more complex project, more hardware to test, etc) and because my resources are very limited, I prefer to keep the project as it is right now -- it works very well only on LCDs that runs our OpenSource firmware.

My suggestions for you guys are:
1. for the ones looking for a smaller LCD, port the KT-LCD3 firmware to the small KT-LCD5 (similar type of VLCD6) - this LCD has a very similar hardware of KT-LCD3 so porting the firmware should be fast and cheap.
2. for the ones looking for a quick and cheap solution, fork the firmware and start a new project. I will be happy to put a link to that new project and borrow any code that I will need.
I am very happy to see so many developers on this project!! I wish there was as many on the firmware I also started for KT motor controllers: https://endless-sphere.com/forums/viewtopic.php?f=30&t=87870

Cristal clear your point casainho, thanks.
Therefore the stock displays will definitely require the fork version. It does make sense in order to keep the code minimal, tidy and to avoid bugs.

Regarding the walk assist, I appreciate the idea to have an advanced version usable with the advanced displays. Just an idea: can the Marcoq "basic" version can be implemented by now while the complex code is under development? A sort of "better something than nothing" I would say :wink:

Thanks

 

[casainho]

Regarding the walk assist, I appreciate the idea to have an advanced version usable with the advanced displays. Just an idea: can the Marcoq "basic" version can be implemented by now while the complex code is under development? A sort of "better something than nothing" I would say :wink:

If someone want to develop and validate that "basic" version of walk assist, I would accept the pull request.

 

[marcoq]

Thanks thineight for reporting... but the error was introduced by my editor in the comment and not in the code ... so the firmware has not been altered.

Not sure I understood correctly: I found the "wrong" line in your motor.c code inside the zipped file and I presume it is the one that will be compiled when needed.. should we change that line back to the original casainho version?
I am trying to carefully put all the pieces together because I will set up one bike with the LCD3 (following the master project) and the second with the VLCD5.

There is no error in the code my editor has altered only the comment line /* 120° /* .... however, I will shortly release the firmware version with the user configuration unterface.
Thanks for your report.

 

[marcoq]

Hello casainho.
In the motor.c file at line 290 I noticed that ui8_sin_table has a length of 256 (SVM_TABLE_LEN) ... it should not be long 60 (SIN_TABLE_LEN)?
Thanks, have a good day.

Yes, probably.

Since you are looking at that code, what would be the BEST improvement is the FOC Field Weaking -- would you like to think on that??

https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/issues/11

I think the idea is that we keep FOC working and get the best efficiency possible:

// 36V motor: L = 76uH
// 48V motor: L = 135uH
// ui32_l_x1048576 = 142; // 1048576 = 2^20 | 48V
// ui32_l_x1048576 = 80; // 1048576 = 2^20 | 36V

BUT when we approach the ERPS speed limit (and/or duty_cycle starts decreasing ???), we should adding a phase advance value so we start to loss efficiency but we get more motor speed, over the nominal max speed of 4000RPM/450ERPS.

I think by now you already have some good experience with this values... maybe we can figure out an algorithm to do this. And we can start by something very simple, like doing some iterations (increasing/decreasing of the angle offset until we get the motor_speed_erps we are looking for).

Unfortunately I am not very expert in brushless motors ... but I can say that in my firmware the walk assist is not fixed but has 5 levels of assistance .... if you want I can eventually help you implement this feature.

 

[casainho]

Unfortunately I am not very expert in brushless motors ... but I can say that in my firmware the walk assist is not fixed but has 5 levels of assistance .... if you want I can eventually help you implement this feature.

Can you explain how it works? Does it control speed?

 

[marcoq]

Unfortunately I am not very expert in brushless motors ... but I can say that in my firmware the walk assist is not fixed but has 5 levels of assistance .... if you want I can eventually help you implement this feature.

Can you explain how it works? Does it control speed?

The walk assist does not control the wheel speed, when the walk assist button is pressed, the speed changes according to the selected assist level (0 ... 4). Of course the wheel speed depends on the gear ratio engaged on the rear derailleur. In the future it could be interesting to manage the walk assist regardless of the position of the derailleur.

 

[casainho]

Unfortunately I am not very expert in brushless motors ... but I can say that in my firmware the walk assist is not fixed but has 5 levels of assistance .... if you want I can eventually help you implement this feature.

Can you explain how it works? Does it control speed?

The walk assist does not control the wheel speed, when the walk assist button is pressed, the speed changes according to the selected assist level (0 ... 4). Of course the wheel speed depends on the gear ratio engaged on the rear derailleur. In the future it could be interesting to manage the walk assist regardless of the position of the derailleur.

So, what is controlled? Or does it work in open loop?