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

buba said:
1. Having runtime variables initialized to a value together with:
2. Not using the EEPROM in any way
3. Minimizing structs and discarding all other instructions needed for the implementation we have today will be the best for programming memory.

There are more instructions for what we have today than a simple:

static uint8_t ui8_motor_type = 48_VOLT_MOTOR;

I am comparing everything as a whole and not just the initialization.
1. I think you agree that for current project, that is to run TSDZ2 with feature rich LCDs like 850C and SW102 Bluetooth, runtime variables initialized are not need.

2. Also you should agree (because it is math and not something subjective) that runtime variables initialized use programming memory.

3. Because there is the risk of not having the needed programming memory for next new features, and considering 1. and 2., runtime variables initialized should not be used.
 
perryscope said:
thineight said:
perryscope said:
I have the same chainring and did a simple hack to lock the crank... ;)
screwdrivere.JPG

Mr Perryscope

Thanks Perryscope, I see you do not have the chain mounted in your picture. Is that not required? In that case I would put a zip-tie somehow between the chainweel teeth and the crank.
How is the process of calibration, are the cranks rotating forward or backwards?

Thanks

I understood it that the chain and drive did not need to be connected, but I may be wrong about that? ( buba can you confirm if this is ok?)
I just thought it was easier than trying to prop the bike up as i don't have a stand on this or the trike

The trike does not actually need a stand ;) and in this case lifting a wheel would be an issue as well it has a limited slip differential! I kid you not! so still drives forward with a wheel lifted, fun to ride on two wheels but not good for testing!

The calibration process drives forward slowly..
[youtube]9Owk0f0c7ys[/youtube]

Good that we have a video showing the calibration process and what it looks like at the chainwheel when engaged. That short video is gold!

I can confirm that you do not need the chain when calibrating. What is important is that the pedal arms rotate together with the chainwheel :) Perfect!
 
I have just finished my first ride with 0.20.0 alfa2 and have following points :

48V high cadence mode - (menu 0:3: value 2 ) is not working for me, the engine stops above 500 ERPS as it would do with normal 48V mode. I did memory cleanup by writing zeros (even it is not needed in alfa2 where the EPROM issues is already solved) so that should not be the case.

the motor & human power values are updated with much higher frequency in compare with previous release. It is almost impossible to catch the current values. ( or may be I am just too old :) Also it feels little strange that just by doing a single pedal turn at same pace/power I get quite huge range of power values e.g. from 180W to 250W. Perhaps some averaging could be done..

Motor acceleration adjustment - (menu 10:0) - May I consider it as a alternative setting for the "ramp-up current" ?

Buba let me say big thank you ! I really appreciate all the improvements even the small one like commit config value with short press of button.. :bigthumb:
 
casainho said:
1. I think you agree that for current project, that is to run TSDZ2 with feature rich LCDs like 850C and SW102 Bluetooth, runtime variables initialized are not need.

I agree that the project should focus on those displays.

Do you think we should use EEPROM in the motor controller? Should we have functions and instructions for reading to and from EEPROM? Should we initialize the runtime variables from EEPROM? Because that is what we are doing today. We are already initializing variables and having instructions to do that. Why not just initialize directly and remove many instructions and save space?

But also, this is not done for space optimizations as the difference this makes is negligible. It should be done because there is no reason to use the EEPROM in the first place and there is no reason to have the code be more complicated with unnecessary steps.

This is what happens today:

1. Initialize the EEPROM
2. Look for the key, if there is no key we write the default values in every address that corresponds to every variable, (a lot of instructions)
3. Take the struct of configuration variables and load it with the values from the EEPROM, so read each and every address and load those values to each and every configuration variable, (a lot of instructions! Takes up space but that is not the point I am trying to make)
3. The configuration variables can then be used as they are initialized to the default values or values saved in the EEPROM. But other values are never saved in the EEPROM so we are always loading the default values.


This is what should happen:
1. Initialize the variable to some default value (or even skip the initialization to save space with variables that are not actually necessary to initialize when not using a display)


casainho said:
2. Also you should agree (because it is math and not something subjective) that runtime variables initialized use programming memory.

I have never said otherwise. See my answer for question number 1. We are doing more unnecessary steps that do take up more place than if we were to simply initialize the variable. This is not subjective.



casainho said:
3. Because there is the risk of not having the needed programming memory for next new features, and considering 1. and 2., runtime variables initialized should not be used.

I really think this is some kind of misunderstanding because:
- This difference in space is minuscule
- It should remove unnecessary steps and actually make more space available
 
elfnino said:
I have just finished my first ride with 0.20.0 alfa2 and have following points :

48V high cadence mode - (menu 0:3: value 2 ) is not working for me, the engine stops above 500 ERPS as it would do with normal 48V mode. I did memory cleanup by writing zeros (even it is not needed in alfa2 where the EPROM issues is already solved) so that should not be the case.

Sad to hear that! May I ask what your cadence is when you feel there is a problem and it is not assisting? Sorry to answer you with a question but just want to make sure!



elfnino said:
the motor & human power values are updated with much higher frequency in compare with previous release. It is almost impossible to catch the current values. ( or may be I am just too old :) Also it feels little strange that just by doing a single pedal turn at same pace/power I get quite huge range of power values e.g. from 180W to 250W. Perhaps some averaging could be done..

The fast values you see are raw unfiltered values. That is more for me and only temporary. Will add a filter in the coming versions so it should be more friendly for the eyes. But for now we have raw values so as to validate that everything works as one would expect. In short, will be fixed and I hope you will like it!



elfnino said:
Motor acceleration adjustment - (menu 10:0) - May I consider it as a alternative setting for the "ramp-up current" ?

Absolutely correct. This is by far more controllable and gives the user the possibility to finely tune the acceleration. Making it much smoother and less strain on the drive train with the same acceleration as before. This is also better suited for the current controller we have so we can control the torque better in the lower ranges.



elfnino said:
Buba let me say big thank you ! I really appreciate all the improvements even the small one like commit config value with short press of button.. :bigthumb:

That is so kind of you! Thank you Elfnino, I hope you have many great rides with the 0.20.0!
 
buba said:
casainho said:
1. I think you agree that for current project, that is to run TSDZ2 with feature rich LCDs like 850C and SW102 Bluetooth, runtime variables initialized are not need.

I agree that the project should focus on those displays.

Do you think we should use EEPROM in the motor controller? Should we have functions and instructions for reading to and from EEPROM? Should we initialize the runtime variables from EEPROM? Because that is what we are doing today. We are already initializing variables and having instructions to do that. Why not just initialize directly and remove many instructions and save space?

But also, this is not done for space optimizations as the difference this makes is negligible. It should be done because there is no reason to use the EEPROM in the first place and there is no reason to have the code be more complicated with unnecessary steps.

This is what happens today:

1. Initialize the EEPROM
2. Look for the key, if there is no key we write the default values in every address that corresponds to every variable, (a lot of instructions)
3. Take the struct of configuration variables and load it with the values from the EEPROM, so read each and every address and load those values to each and every configuration variable, (a lot of instructions! Takes up space but that is not the point I am trying to make)
3. The configuration variables can then be used as they are initialized to the default values or values saved in the EEPROM. But other values are never saved in the EEPROM so we are always loading default the values.


This is what should happen:
1. Initialize the variable to some default value (or even skip the initialization to save space with variables that are not actually necessary to initialize when not using a display)


casainho said:
2. Also you should agree (because it is math and not something subjective) that runtime variables initialized use programming memory.

I have never said otherwise. See my answer for question number 1. We are doing more unnecessary steps that do take up more place than if we were to simply initialize the variable. This is not subjective.



casainho said:
3. Because there is the risk of not having the needed programming memory for next new features, and considering 1. and 2., runtime variables initialized should not be used.

I really think this is some kind of misunderstanding because:
- This difference in space is minuscule
- It should remove unnecessary steps and actually make more space available
When I implemented that part of EEPROM on the motor controller I was expecting it would be needed, now I think the contrary.

Since the project is to run TSDZ2 with feature rich displays like 850C and SW102 Bluetooth, what I think should happen:

1. Motor controller starts up and the variables have unknown values, only the variable invalid_varables is 1.

2. System waits until invalid_variables is 0.

3. Once first configurations package arrives from the display, the variables are set to correct values and invalid_variables is set to 1, then, system will be ready and motor will be ready to work.

I am developing the torque sensor full calibration (again) and I plan to use 84 bytes for configurations only for this feature. I think we should save this amount plus the already existing amount from programing memory of motor controller.
 
Today he took a longer ride with some off-road vehicles. The following considerations concern power mode. I noticed that the feeling is of having slightly less power, but perhaps it is due to the greater progressiveness of the pedal. In previous versions it was more on-off now it is more sensitive to pedal pressure. Watts vary continuously much faster than before.
It is just a matter of habit, however it is much more natural. Much more similar to the behavior of my turbo levo.
I noticed that the engine starts to appear due to the cadence and not the pressure. This can in some cases be unpleasant. Downhill just move the pedals and you can hear the engine start empty, something that didn't happen before. It is unpleasant because it seems that the free wheel is broken and the engine runs without gears.
Even with the bike lifted off the ground, just turn the pedals without any pressure to start the engine exactly after a quarter of a turn, just like in a hub motor with 12-magneto pas.
For the rest the only real bug is the backward resistance at the start but just a turn of the pedals and it disappears. I haven't tried the other ways, I'm not interested.
 
casainho said:
h
Since the project is to run TSDZ2 with feature rich displays like 850C and SW102 Bluetooth, what I think should happen:

1. Motor controller starts up and the variables have unknown values, only the variable invalid_varables is 1.

2. System waits until invalid_variables is 0.

3. Once first configurations package arrives from the display, the variables are set to correct values and invalid_variables is set to 1, then, system will be ready and motor will be ready to work.
i don't understand why you are insisting in cutting a valuable feature off the code. How many space can be saved if we cut away all the eeprom functions? At the current state they make no sense, right. But this can be corrected with litte effort and we gain one more safety feature for "breaking parts in the field".

Thinking further, if the serial protocol could be smarter, we could also use a laptop or a phone to set up the motor, push everything into the eprom and than we could use simpler displays for the daily usage. Thinking of the SW102, there is a lot of work for compressing all those configuration stuff in there...

Sorry, i don't want to sound like i'm angry :) I really love this project and i'm very appreciated for all the work that has gone into the code.
 
andrea_104kg said:
Today he took a longer ride with some off-road vehicles. The following considerations concern power mode. I noticed that the feeling is of having slightly less power, but perhaps it is due to the greater progressiveness of the pedal. In previous versions it was more on-off now it is more sensitive to pedal pressure. Watts vary continuously much faster than before.
It is just a matter of habit, however it is much more natural. Much more similar to the behavior of my turbo levo.

The power readings fluctuate as there is no filter yet. This will be added when we have validated that everything works as expected :)

I find it great that you find similarities to the Turbo Levo! Will hopefully only get better!



andrea_104kg said:
I noticed that the engine starts to appear due to the cadence and not the pressure. This can in some cases be unpleasant. Downhill just move the pedals and you can hear the engine start empty, something that didn't happen before. It is unpleasant because it seems that the free wheel is broken and the engine runs without gears.
Even with the bike lifted off the ground, just turn the pedals without any pressure to start the engine exactly after a quarter of a turn, just like in a hub motor with 12-magneto pas.

That is because we have a much higher resolution now. But I can easily fix this! The problem should not be there in Torque Assist as it has a threshold. Can add the threshold in Power Assist as well thanks to your feedback, andrea_104kg!



andrea_104kg said:
For the rest the only real bug is the backward resistance at the start but just a turn of the pedals and it disappears. I haven't tried the other ways, I'm not interested.

This will be fixed in the Alpha 3! :)
 
shaddi said:
Thinking further, if the serial protocol could be smarter, we could also use a laptop or a phone to set up the motor, push everything into the eprom and than we could use simpler displays for the daily usage.
Thanks for being clear that your reason is a feature that is out of scope of this project.
 
casainho said:
When I implemented that part of EEPROM on the motor controller I was expecting it would be needed, now I think the contrary.

Since the project is to run TSDZ2 with feature rich displays like 850C and SW102 Bluetooth, what I think should happen:

1. Motor controller starts up and the variables have unknown values, only the variable invalid_varables is 1.

2. System waits until invalid_variables is 0.

3. Once first configurations package arrives from the display, the variables are set to correct values and invalid_variables is set to 1, then, system will be ready and motor will be ready to work.

I am developing the torque sensor full calibration (again) and I plan to use 84 bytes for configurations only for this feature. I think we should save this amount plus the already existing amount from programing memory of motor controller.

So we are on the same page?

Initialize some variables and let others be initialized after all the packages have been received. You would not mind if we make it so there are runtime variables?

For users that want to skip the display they simply use the EEPROM code to do so.
 
shaddi said:
casainho said:
h
Since the project is to run TSDZ2 with feature rich displays like 850C and SW102 Bluetooth, what I think should happen:

1. Motor controller starts up and the variables have unknown values, only the variable invalid_varables is 1.

2. System waits until invalid_variables is 0.

3. Once first configurations package arrives from the display, the variables are set to correct values and invalid_variables is set to 1, then, system will be ready and motor will be ready to work.
i don't understand why you are insisting in cutting a valuable feature off the code. How many space can be saved if we cut away all the eeprom functions? At the current state they make no sense, right. But this can be corrected with litte effort and we gain one more safety feature for "breaking parts in the field".

Thinking further, if the serial protocol could be smarter, we could also use a laptop or a phone to set up the motor, push everything into the eprom and than we could use simpler displays for the daily usage. Thinking of the SW102, there is a lot of work for compressing all those configuration stuff in there...

Sorry, i don't want to sound like i'm angry :) I really love this project and i'm very appreciated for all the work that has gone into the code.


I really do not think you are perceived like that! But yes, usually discussions tend to make people sound angry :) But we should not be afraid of discussing things like these as it is the only way of exploring different viewpoints!

I do not think Casainho is limiting the possibility to use the TSDZ2 without the display. He is only trying to say that the main project should focus on making firmware that works with a display. As it can be difficult to develop one firmware that has support for setups with and without a display while at the same time having a massive motor controller upgrade, two displays on their way and also an advanced torque sensor calibration that will change everything quite a bit.

But this will change when the project matures and the development settles down a bit. Then we can start considering different implementations and maybe even make one universal motor controller firmware that supports:

1. No display
2. KT-LCD3
3. 850C
4. SW102

Not saying this will happen and/or is possible (no need to discuss this) but am just throwing things out there as I do not want anyone to feel they will be left behind.

And just so that everyone knows, whatever I implement will not in any way stop anyone from modifying the TSDZ2 in any way they like. I always strive to make the code more modular, simple to understand and accessible to anyone.
 
buba said:
shaddi said:
casainho said:
h
Since the project is to run TSDZ2 with feature rich displays like 850C and SW102 Bluetooth, what I think should happen:

1. Motor controller starts up and the variables have unknown values, only the variable invalid_varables is 1.

2. System waits until invalid_variables is 0.

3. Once first configurations package arrives from the display, the variables are set to correct values and invalid_variables is set to 1, then, system will be ready and motor will be ready to work.
i don't understand why you are insisting in cutting a valuable feature off the code. How many space can be saved if we cut away all the eeprom functions? At the current state they make no sense, right. But this can be corrected with litte effort and we gain one more safety feature for "breaking parts in the field".

Thinking further, if the serial protocol could be smarter, we could also use a laptop or a phone to set up the motor, push everything into the eprom and than we could use simpler displays for the daily usage. Thinking of the SW102, there is a lot of work for compressing all those configuration stuff in there...

Sorry, i don't want to sound like i'm angry :) I really love this project and i'm very appreciated for all the work that has gone into the code.


I really do not think you are perceived like that! But yes, usually discussions tend to make people sound angry :) But we should not be afraid of discussing things like these as it is the only way of exploring different viewpoints!

I do not think Casainho is limiting the possibility to use the TSDZ2 without the display. He is only trying to say that the main project should focus on making firmware that works with a display. As it can be difficult to develop one firmware that has support for setups with and without a display while at the same time having a massive motor controller upgrade, two displays on their way and also an advanced torque sensor calibration that will change everything quite a bit.

But this will change when the project matures and the development settles down a bit. Then we can start considering different implementations and maybe even make one universal motor controller firmware that supports:

1. No display
2. KT-LCD3
3. 850C
4. SW102

Not saying this will happen and/or is possible (no need to discuss this) but am just throwing things out there as I do not want anyone to feel they will be left behind.

And just so that everyone knows, whatever I implement will not in any way stop anyone from modifying the TSDZ2 in any way they like. I always strive to make the code more modular, simple to understand and accessible to anyone.
I think it is a strategic error to increase the project complexity. Supporting more different user types will add more options paths for users and so more confusion, more work for developers to support users, users will be dispersed, will be harder to maintain the same the quality compared to have a smaller and a more focused project, the project as a whole will be weaker.

Don't count with me to develop and maintain a project I don't believe, that I am not motivated to.
 
Sorry, i think casainho is already mad at me, that was not my intention :-(

My scope of the whole project is to get a motor that outperforms many other commercial systems out there. And i think all the developers involved till now have already made that possible. I love how my bike performs (and i'm still on 0.18, hehe).

My hope is that all active developers come to an reasonable compromise between flexibility and extensibility. Too many forks will kill every progress. I don't want to cherry-pick code from various forks to get the best out of everyone :)

Casainho, i don't want you to maintain or do support for something that you don't use yourself. I know from other projects, that this is very frustrating. But if you want that more developers get involved and to improve the master branch, you should listen to discussions or arguments for other possibilities besides your need. Please, don't get me wrong, english is not my native language and i think i'm sounding a bit to harsh :-(

The only thing i want is, that current developers put the pro's and con's about decisions side by side. In this example, saving x bytes of code/flash/eeprom against the possibility that the motor runs (let it be in the case of a failure) without a display. Is it worth it to cut it now? Should we cut the functions later if you have implemented your calibration routines and don't have enough space? How many users would like to have the possibility of running without a display? Do we have other functions we can cut (if there are not uses by any users) or other ways of reducing the code size? Frans-Willem is doing crazy stuff in his fork :p

And once again, sorry if i'm sounding harsh or criticizing. Thats not my intention :-(
 
The project owner rules, others can only humbly request

Or fork a new project branch, that they can play with all they like,

ideas from which the OG Dev may (or may not) choose to incorporate in the main branch later on.

How FOSS works. . .
 
buba said:
elfnino said:
48V high cadence mode - (menu 0:3: value 2 ) is not working for me, the engine stops above 500 ERPS as it would do with normal 48V mode. I did memory cleanup by writing zeros (even it is not needed in alfa2 where the EPROM issues is already solved) so that should not be the case.

Sad to hear that! May I ask what your cadence is when you feel there is a problem and it is not assisting? Sorry to answer you with a question but just want to make sure!

I can feel that motor assist stops (hits the wall) approximately at cadence of 90 rpm in normal and high cadence mode . Strange that so far I am the only one who has reported this.
If anyone is using 48V high cadence mode can you confirm it is working fine with the alfa2 ?
 
I agree with casainho. user needs are too many and too different. the project must be simple and work well from the motor side.
 
Hm, casainho and me splitted our developments on the Kuntengs one day also, as I had different prefers and finally casainho quit the Kunteng project to concentrate on the TSDZ2.

john61ct said:
Or fork a new project branch, that they can play with all they like,
Yes, you are right, but it would be fine to have a central overview somewhere, who is developing in which direction. I didn't recognize the activities of frans wilhelm until today :)
Perhaps we can spend one page on the main wiki, where the developers can describe their motivation and do some "marketing" for their ideas.

edit: just added the wiki page :D :
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Interesting-forks

regards
stancecoke
 
stancecoke said:
Yes, you are right, but it would be fine to have a central overview somewhere, who is developing in which direction. I didn't recognize the activities of frans wilhelm until today :)
Perhaps we can spend one page on the main wiki, where the developers can describe their motivation and do some "marketing" for their ideas.
I like this idea because currently there are developers working very fast and they are not communicating here but instead using github only: https://github.com/OpenSource-EBike-firmware/SW102_LCD_Bluetooth/issues/3

Here is the current state of SW102 Bluetooth firmware, what can be seen on the video:
- configurations menu
- there are sections on configuration menu (even better than current 850C configurations menu) like: wheel settings; battery; assist level; etc
- user enters in the "wheel settings" section and changes the "wheel perimeter" value
- user enters in the "speed units" section and changes from "km/h" to "mph"
- user leaves the configurations screen and enter the main screen (that has near the design discussed previously)

Current TODO list: https://github.com/geeksville/SW102_LCD_Bluetooth/blob/khwip/TODO.md

[youtube]zIf8hCtIuJI[/youtube]
 
casainho said:
stancecoke said:
Yes, you are right, but it would be fine to have a central overview somewhere, who is developing in which direction. I didn't recognize the activities of frans wilhelm until today :)
Perhaps we can spend one page on the main wiki, where the developers can describe their motivation and do some "marketing" for their ideas.
I like this idea because currently there are developers working very fast and they are not communicating here but instead using github only: https://github.com/OpenSource-EBike-firmware/SW102_LCD_Bluetooth/issues/3

Here is the current state of SW102 Bluetooth firmware, what can be seen on the video:
- configurations menu
- there are sections on configuration menu (even better than current 850C configurations menu) like: wheel settings; battery; assist level; etc
- user enters in the "wheel settings" section and changes the "wheel perimeter" value
- user enters in the "speed units" section and changes from "km/h" to "mph"
- user leaves the configurations screen and enter the main screen (that has near the design discussed previously)

[youtube]zIf8hCtIuJI[/youtube]

I understand Geeksville is doing a wonderful job and really putting down hours to make the SW102 work. No matter what display anyone prefers between the 850C or the SW102, you got to appreciate the dedication and fine work! Nice to see!
 
elfnino said:
buba said:
elfnino said:
48V high cadence mode - (menu 0:3: value 2 ) is not working for me, the engine stops above 500 ERPS as it would do with normal 48V mode. I did memory cleanup by writing zeros (even it is not needed in alfa2 where the EPROM issues is already solved) so that should not be the case.

Sad to hear that! May I ask what your cadence is when you feel there is a problem and it is not assisting? Sorry to answer you with a question but just want to make sure!

I can feel that motor assist stops (hits the wall) approximately at cadence of 90 rpm in normal and high cadence mode . Strange that so far I am the only one who has reported this.
If anyone is using 48V high cadence mode can you confirm it is working fine with the alfa2 ?

What you describe should happen to anyone regardless of mode! Will fix and thank you so much for testing and reporting!
 
casainho said:
buba said:
And just so that everyone knows, whatever I implement will not in any way stop anyone from modifying the TSDZ2 in any way they like. I always strive to make the code more modular, simple to understand and accessible to anyone.

I think it is a strategic error to increase the project complexity. Supporting more different user types will add more options paths for users and so more confusion, more work for developers to support users, users will be dispersed, will be harder to maintain the same the quality compared to have a smaller and a more focused project, the project as a whole will be weaker.

Don't count with me to develop and maintain a project I don't believe, that I am not motivated to.

I just want to clarify that I did not mean for us to add project complexity. I simply stated that no one should be worried for all the changes planned as it will never stop anyone from doing their thing in another fork. But that this project needs to focus on the things that is happening now.

I really hope you did not get any intentions wrong.

Anyway, I will assume we are on the same page regarding the EEPROM thing... Let me know if you feel more comfortable with leaving things as it is.
 
I just want to say that I will be developing today and making Alpha 3. Here is what I planned:

- EEPROM will be slightly more efficient thanks to mspider65!

- Motor temperature not displayed in odometer field when user selects it to be displayed, this will be sorted out!

- No assistance over 90 cadence, will be fixed!

- Backwards resistance that comes and goes, bye bye!

- Slightly better motor control in the low range when using Power Assist

- Maybe improve the throttle depending on user feedback

- Error code if the cadence calibration is not done and users are trying to use the Advanced Mode

- Maybe pedal assistance without pedal rotation in a very safe way!

- Overall improvements

And if I have missed something or users have more suggestions I will add that to! But will be rather absent from the thread so I can focus on development. But will of course read suggestions and also reply if there is something that I can help with!
 
Wonderful job buba! the emtb combined with torque mode is especially useful on the singletracks

I confirm that high cadence mode (48V motor) seems not to work properly

"Start without pedal rotation" is no more a feature ? I did really like it...

Moreover, a way to switch fast between the power, torque and cadence mode would be a good idea
 
NexusG said:
Wonderful job buba! the emtb combined with torque mode is especially useful on the singletracks

Very glad to hear you find it useful! That actually makes me very happy as I do not know how this eMTB compares to other eMTB modes from other forks or commercial products. Would like to hear some comparisons! But if you find it useful then it does serve a purpose!



NexusG said:
I confirm that high cadence mode (48V motor) seems not to work properly

"Start without pedal rotation" is no more a feature ? I did really like it...

Moreover, a way to switch fast between the power, torque and cadence mode would be a good idea

The "assistance-without-pedal-rotation" I will try to add. Especially if it can be as safe as what I had in mind! Will fix, consider and do my best! Thank you for the feedback!
 
Back
Top