TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Electric Motors and Controllers
nbdriver   100 mW

100 mW
Posts: 37
Joined: Jul 31 2015 4:38am
Location: Belgium

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by nbdriver » Aug 06 2019 10:05am

buba wrote:
Aug 06 2019 7:56am
nbdriver wrote:
Aug 06 2019 3:59am
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 ?
Power Assist:

1. Measure the torque sensor value and convert it to torque.
2. Measure the cadence.
3. Calculate human power, it is defined as torque * cadence.
4. The target motor power is calculated by human power * assist level multiplier. So if we measure a value of 200 watts human power and multiply it with an assist level multiplier of 2.0 we will be asking the motor to assist us with 400 watts motor power.

Result: the more you sweat the more assistance you will get.


Torque Assist:

1. Measure the torque sensor value.
2. The target motor torque is calculated by torque * assist level multiplier

Result: the more you push on the pedals the more assistance you will get.

There are no advantages. Just different experiences. Personal preference :)
Thank you buba for this complete answer, i will try power mode tonight.

casainho   1.21 GW

1.21 GW
Posts: 3588
Joined: Feb 14 2011 2:43pm

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by casainho » Aug 06 2019 10:21am

buba wrote:
Aug 06 2019 6:56am
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.
Developer of the Flexible OpenSource firmware for EBike motor controllers (TSDZ2 and KT) and LCDs (KT-LCD3 and Bafang 850C color LCD).

If you like my work, please consider making a donation. I am being using the donations to buy needed resources for my developments. My paypal: casainho AT gmail.com.

buba   10 kW

10 kW
Posts: 550
Joined: Aug 31 2018 12:36am

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by buba » Aug 06 2019 1:19pm

perryscope wrote:
Aug 06 2019 8:58am
thineight wrote:
Aug 06 2019 8:51am
perryscope wrote:
Aug 06 2019 7:26am
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..
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!
Last edited by buba on Aug 06 2019 6:10pm, edited 2 times in total.
GitHub: https://github.com/leon927
PayPal: leonstor at bredband.net

elfnino   100 mW

100 mW
Posts: 38
Joined: Mar 06 2019 5:09am

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by elfnino » Aug 06 2019 1:37pm

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:

buba   10 kW

10 kW
Posts: 550
Joined: Aug 31 2018 12:36am

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by buba » Aug 06 2019 2:05pm

casainho wrote:
Aug 06 2019 10:21am
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 wrote:
Aug 06 2019 10:21am
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 wrote:
Aug 06 2019 10:21am
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
Last edited by buba on Aug 07 2019 6:09am, edited 1 time in total.
GitHub: https://github.com/leon927
PayPal: leonstor at bredband.net

buba   10 kW

10 kW
Posts: 550
Joined: Aug 31 2018 12:36am

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by buba » Aug 06 2019 2:23pm

elfnino wrote:
Aug 06 2019 1:37pm
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 wrote:
Aug 06 2019 1:37pm
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 wrote:
Aug 06 2019 1:37pm
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 wrote:
Aug 06 2019 1:37pm
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!
GitHub: https://github.com/leon927
PayPal: leonstor at bredband.net

casainho   1.21 GW

1.21 GW
Posts: 3588
Joined: Feb 14 2011 2:43pm

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by casainho » Aug 06 2019 2:29pm

buba wrote:
Aug 06 2019 2:05pm
casainho wrote:
Aug 06 2019 10:21am
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 wrote:
Aug 06 2019 10:21am
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 wrote:
Aug 06 2019 10:21am
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.
Developer of the Flexible OpenSource firmware for EBike motor controllers (TSDZ2 and KT) and LCDs (KT-LCD3 and Bafang 850C color LCD).

If you like my work, please consider making a donation. I am being using the donations to buy needed resources for my developments. My paypal: casainho AT gmail.com.

andrea_104kg   100 W

100 W
Posts: 152
Joined: Mar 05 2018 5:51pm

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by andrea_104kg » Aug 06 2019 3:15pm

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.

shaddi   100 mW

100 mW
Posts: 43
Joined: May 30 2018 3:20pm

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by shaddi » Aug 06 2019 3:30pm

casainho wrote: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.

buba   10 kW

10 kW
Posts: 550
Joined: Aug 31 2018 12:36am

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by buba » Aug 06 2019 3:46pm

andrea_104kg wrote:
Aug 06 2019 3:15pm
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 wrote:
Aug 06 2019 3:15pm
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 wrote:
Aug 06 2019 3:15pm
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! :)
GitHub: https://github.com/leon927
PayPal: leonstor at bredband.net

casainho   1.21 GW

1.21 GW
Posts: 3588
Joined: Feb 14 2011 2:43pm

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by casainho » Aug 06 2019 3:51pm

shaddi wrote:
Aug 06 2019 3:30pm
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.
Developer of the Flexible OpenSource firmware for EBike motor controllers (TSDZ2 and KT) and LCDs (KT-LCD3 and Bafang 850C color LCD).

If you like my work, please consider making a donation. I am being using the donations to buy needed resources for my developments. My paypal: casainho AT gmail.com.

buba   10 kW

10 kW
Posts: 550
Joined: Aug 31 2018 12:36am

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by buba » Aug 06 2019 4:05pm

casainho wrote:
Aug 06 2019 2:29pm
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.
GitHub: https://github.com/leon927
PayPal: leonstor at bredband.net

buba   10 kW

10 kW
Posts: 550
Joined: Aug 31 2018 12:36am

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by buba » Aug 06 2019 4:53pm

shaddi wrote:
Aug 06 2019 3:30pm
casainho wrote: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.
GitHub: https://github.com/leon927
PayPal: leonstor at bredband.net

casainho   1.21 GW

1.21 GW
Posts: 3588
Joined: Feb 14 2011 2:43pm

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by casainho » Aug 06 2019 9:36pm

buba wrote:
Aug 06 2019 4:53pm
shaddi wrote:
Aug 06 2019 3:30pm
casainho wrote: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.
Developer of the Flexible OpenSource firmware for EBike motor controllers (TSDZ2 and KT) and LCDs (KT-LCD3 and Bafang 850C color LCD).

If you like my work, please consider making a donation. I am being using the donations to buy needed resources for my developments. My paypal: casainho AT gmail.com.

shaddi   100 mW

100 mW
Posts: 43
Joined: May 30 2018 3:20pm

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by shaddi » Aug 07 2019 1:58am

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 :-(

john61ct   1 MW

1 MW
Posts: 1677
Joined: Dec 18 2018 2:06pm

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by john61ct » Aug 07 2019 2:00am

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. . .

elfnino   100 mW

100 mW
Posts: 38
Joined: Mar 06 2019 5:09am

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by elfnino » Aug 07 2019 2:11am

buba wrote:
Aug 06 2019 2:23pm
elfnino wrote:
Aug 06 2019 1:37pm
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 ?

andrea_104kg   100 W

100 W
Posts: 152
Joined: Mar 05 2018 5:51pm

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by andrea_104kg » Aug 07 2019 3:30am

I agree with casainho. user needs are too many and too different. the project must be simple and work well from the motor side.

User avatar
stancecoke   100 kW

100 kW
Posts: 1019
Joined: Aug 02 2017 2:56pm

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by stancecoke » Aug 07 2019 3:57am

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 wrote:
Aug 07 2019 2:00am
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-fir ... ting-forks

regards
stancecoke

casainho   1.21 GW

1.21 GW
Posts: 3588
Joined: Feb 14 2011 2:43pm

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by casainho » Aug 07 2019 4:22am

stancecoke wrote:
Aug 07 2019 3:57am
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-fir ... h/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 ... ip/TODO.md

Last edited by casainho on Aug 07 2019 9:33am, edited 1 time in total.
Developer of the Flexible OpenSource firmware for EBike motor controllers (TSDZ2 and KT) and LCDs (KT-LCD3 and Bafang 850C color LCD).

If you like my work, please consider making a donation. I am being using the donations to buy needed resources for my developments. My paypal: casainho AT gmail.com.

buba   10 kW

10 kW
Posts: 550
Joined: Aug 31 2018 12:36am

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by buba » Aug 07 2019 5:46am

casainho wrote:
Aug 07 2019 4:22am
stancecoke wrote:
Aug 07 2019 3:57am
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-fir ... h/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)

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!
GitHub: https://github.com/leon927
PayPal: leonstor at bredband.net

buba   10 kW

10 kW
Posts: 550
Joined: Aug 31 2018 12:36am

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by buba » Aug 07 2019 5:51am

elfnino wrote:
Aug 07 2019 2:11am
buba wrote:
Aug 06 2019 2:23pm
elfnino wrote:
Aug 06 2019 1:37pm
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!
GitHub: https://github.com/leon927
PayPal: leonstor at bredband.net

buba   10 kW

10 kW
Posts: 550
Joined: Aug 31 2018 12:36am

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by buba » Aug 07 2019 6:06am

casainho wrote:
Aug 06 2019 9:36pm
buba wrote:
Aug 06 2019 4:53pm
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.
GitHub: https://github.com/leon927
PayPal: leonstor at bredband.net

buba   10 kW

10 kW
Posts: 550
Joined: Aug 31 2018 12:36am

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by buba » Aug 07 2019 6:29am

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!
GitHub: https://github.com/leon927
PayPal: leonstor at bredband.net

NexusG   1 µW

1 µW
Posts: 1
Joined: Aug 06 2019 7:36am

Re: TSDZ2 mid drive -- Flexible OpenSource firmware for TongSheng TSDZ2 mid drive motor

Post by NexusG » Aug 07 2019 6:33am

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

Post Reply