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

[perryscope]

Having said that I am hopeful that we may be able to program over Bluetooth from the outset so hopefully we wont need to open it at all

That should be possible already, Geeksville developed a bootloader and firmware that should be accepted by the original SW102 but none of us have in our hands and original SW102 so we can't test yet.

Please read here how to flash our bootloader and firmware on a new SW102, without open it: https://github.com/OpenSource-EBike-firmware/SW102_LCD_Bluetooth/issues/35#issuecomment-525492910

Yes, I actually have a untouched unit to try this with tonight so will let you guys know how I get on.

 

[buba]

With A3 on coaster brake we are noticing that if you go from pedaling to brake quickly, as in an urgent braking situation, then backward resistance is there. If you then release the brake and then reapply the backward resistance is gone. Alternatively, if you have time to pause/coast before applying the brake, there is no backward resistance. Not absolutely sure but the resistance seems higher if you are in a higher level of assistance.

Good feedback and description! Will remember that and make some tests when I install the brake clutch! Did not expect I would be getting Coaster Brake feedback so soon so I do appreciate it as it prepares me for the different tests I need to do!

Thank you, Rydon!

Buba, just wondering if you had a chance to look at this with clutch installed. We did calibrate the PAS and had the same result.

Just installed the clutch and will do some testing!

Alpha 9 is up!


Here are the changes from Alpha 8:
- Walk Assist debounce time adjustable
- Walk Assist not changing assist level during accidental button bounce
- Some small display improvements
- Walk Assist, minor improvements

Thanks Buba you have made the walk assist mode just about perfect now :thumb:

That is great to hear!

 

[eyebyesickle]

Having said that I am hopeful that we may be able to program over Bluetooth from the outset so hopefully we wont need to open it at all

That should be possible already, Geeksville developed a bootloader and firmware that should be accepted by the original SW102 but none of us have in our hands and original SW102 so we can't test yet.

Please read here how to flash our bootloader and firmware on a new SW102, without open it: https://github.com/OpenSource-EBike-firmware/SW102_LCD_Bluetooth/issues/35#issuecomment-525492910

Yes, I actually have a untouched unit to try this with tonight so will let you guys know how I get on.

might want to hold off, I think I just killed a poor lil sw102 trying it. first one did take the update to completion, but after that..... crickets

 

[perryscope]

Having said that I am hopeful that we may be able to program over Bluetooth from the outset so hopefully we wont need to open it at all

That should be possible already, Geeksville developed a bootloader and firmware that should be accepted by the original SW102 but none of us have in our hands and original SW102 so we can't test yet.

Please read here how to flash our bootloader and firmware on a new SW102, without open it: https://github.com/OpenSource-EBike-firmware/SW102_LCD_Bluetooth/issues/35#issuecomment-525492910

Yes, I actually have a untouched unit to try this with tonight so will let you guys know how I get on.

might want to hold off, I think I just killed a poor lil sw102 trying it. first one did take the update to completion, but after that..... crickets

oh!, thanks for the heads up. are you able to try updating using the programming pins, or do you think its foo bared?

If it can be rescued by using the programming pins I am happy to take the risk, but will wait to hear before trying the Bluetooth method for now

 

[casainho]

are you able to try updating using the programming pins, or do you think its foo bared?

Sure it is. We are trying to have 2 different ways to install our Bluetooth bootloader:
1. flash our bootloader using Bluetooth on a new SW102
2. flash our bootloader using SWD pins on a new or used SW102

If 1. fails, 2. will always work. Seems that we don't have yet 1. working.

 

[buba]

With A3 on coaster brake we are noticing that if you go from pedaling to brake quickly, as in an urgent braking situation, then backward resistance is there. If you then release the brake and then reapply the backward resistance is gone. Alternatively, if you have time to pause/coast before applying the brake, there is no backward resistance. Not absolutely sure but the resistance seems higher if you are in a higher level of assistance.

Good feedback and description! Will remember that and make some tests when I install the brake clutch! Did not expect I would be getting Coaster Brake feedback so soon so I do appreciate it as it prepares me for the different tests I need to do!

Thank you, Rydon!

Buba, just wondering if you had a chance to look at this with clutch installed. We did calibrate the PAS and had the same result.

Just did a very quick test and I now know why there is a backwards resistance.

The problem is that the system only disables the motor if a couple of parameters are set. One of those parameters is the rotational speed of the motor. The rotational speed of the motor needs to be 0 if the motor is to be turned off.

There are two alternatives to solve this:

1. Allow to disable the motor if ERPS is below 40 instead of 0. From testing I noticed that I can get the motor to rotate to around 35 ERPS backwards so we need a threshold value of around 40.

2. Change the motor code slightly so it calculates backwards rotation as zero. (What I would do)

Casainho, would you mind if I change the motor.c code to address this issue? The hall sensor sequence should be:

 hall sensors sequence with motor forward rotation: 4, 6, 2, 3, 1, 5

If it is anything other than that I would simply set ERPS to 0. This would disable the motor when Coaster Brake versions of the TSDZ2 are braking and remove the backwards resistance.

 

[casainho]

Just did a very quick test and I now know why there is a backwards resistance.

The problem is that the system only disables the motor if a couple of parameters are set. One of those parameters is the rotational speed of the motor. The rotational speed of the motor needs to be 0 if the motor is to be turned off.

There are two alternatives to solve this:

1. Allow to disable the motor if ERPS is below 40 instead of 0. From testing I noticed that I can get the motor to rotate to around 35 ERPS backwards so we need a threshold value of around 40.

2. Change the motor code slightly so it calculates backwards rotation as zero. (What I would do)

Casainho, would you mind if I change the motor.c code to address this issue? The hall sensor sequence should be:

 hall sensors sequence with motor forward rotation: 4, 6, 2, 3, 1, 5

If it is anything other than that I would simply set ERPS to 0. This would disable the motor when Coaster Brake versions of the TSDZ2 are braking and remove the backwards resistance.

For me seems good idea to go with 2. And yes, looking at the sequence of hall sensors transition is a way to find rotation direction.

 

[buba]

Just did a very quick test and I now know why there is a backwards resistance.

The problem is that the system only disables the motor if a couple of parameters are set. One of those parameters is the rotational speed of the motor. The rotational speed of the motor needs to be 0 if the motor is to be turned off.

There are two alternatives to solve this:

1. Allow to disable the motor if ERPS is below 40 instead of 0. From testing I noticed that I can get the motor to rotate to around 35 ERPS backwards so we need a threshold value of around 40.

2. Change the motor code slightly so it calculates backwards rotation as zero. (What I would do)

Casainho, would you mind if I change the motor.c code to address this issue? The hall sensor sequence should be:

 hall sensors sequence with motor forward rotation: 4, 6, 2, 3, 1, 5

If it is anything other than that I would simply set ERPS to 0. This would disable the motor when Coaster Brake versions of the TSDZ2 are braking and remove the backwards resistance.

For me seems good idea to go with 2. And yes, looking at the sequence of hall sensors transition is a way to find rotation direction.

No more backwards resistance when braking for the Coaster Brake versions! Just tested, works great! Will add a couple more changes and features that should make the experience even better. For everyone!

 

[buba]

With A3 on coaster brake we are noticing that if you go from pedaling to brake quickly, as in an urgent braking situation, then backward resistance is there. If you then release the brake and then reapply the backward resistance is gone. Alternatively, if you have time to pause/coast before applying the brake, there is no backward resistance. Not absolutely sure but the resistance seems higher if you are in a higher level of assistance.

Good feedback and description! Will remember that and make some tests when I install the brake clutch! Did not expect I would be getting Coaster Brake feedback so soon so I do appreciate it as it prepares me for the different tests I need to do!

Thank you, Rydon!

Buba, just wondering if you had a chance to look at this with clutch installed. We did calibrate the PAS and had the same result.

Alpha 10 will be released tomorrow! Am finished with the changes but want to test it out some more and it just started raining. There will be several improvements and all users will benefit!

 

[perryscope]

That should be possible already, Geeksville developed a bootloader and firmware that should be accepted by the original SW102 but none of us have in our hands and original SW102 so we can't test yet.

Please read here how to flash our bootloader and firmware on a new SW102, without open it: https://github.com/OpenSource-EBike-firmware/SW102_LCD_Bluetooth/issues/35#issuecomment-525492910

Yes, I actually have a untouched unit to try this with tonight so will let you guys know how I get on.

might want to hold off, I think I just killed a poor lil sw102 trying it. first one did take the update to completion, but after that..... crickets

oh!, thanks for the heads up. are you able to try updating using the programming pins, or do you think its foo bared?

If it can be rescued by using the programming pins I am happy to take the risk, but will wait to hear before trying the Bluetooth method for now

well I tried it but had the same issue as eyebyesickle. it took the bootloader update file fine. restarted but would not boot.
I tried multiple times to boot into DFU, but alas no joy . As It happened this was a unit I had opened but not yet programmed so i then connected via the programming pins and that method worked fine, so its working fine. but unfortunately no longer stock, to test again. i have a third unit arriving soon so we can test again on that. but for now. if anyone is willing to try this method be prepared to use the wired method if it fails.

 

[casainho]

well I tried it but had the same issue as eyebyesickle. it took the bootloader update file fine. restarted but would not boot.

Geeksville went very deep and is very experienced, I am almost sure he will be able to do it. Then, SW102 will be the recommended display on the wiki, as it will be the most easy one to install our firmware. Clearly much better for users than the first one we started with.

 

[andrea_104kg]

Today I did 2 tests: installed the alpha 9 version on the 36v engine, obviously it works great. thank you!
Unfortunately the emtb is still bad for me :-(
Later I tried to power the 48v bike with a 36v battery. It becomes very quiet, it is still fully usable on the road. I think we are the only ones who can use different batteries on a central
Thanks again.
but a small test of emtb based on power mode, just to see if it works?

 

[h27]

Hello
I am new to the forum and went through most of the post in this thread.
Great work - thanks to you big brains who have sacrificed so much time and effort to this project!
I I could not find an answer to the following beginner’s question here or in the wiki: I just ordered a 36v TSDZ2 motor, a 850C display and a 52V battery. If I want to flash the firmware to the 850C without the bootloader I will need the battery to power the display. Will this work with my wrong voltage of the battery (52 instead of 36)? Or would I first have to flash the motor/controller and set the correct value for the voltage? (And if the correct voltage has to be set first: How would I do that before my display works?)?
Thanks for your help.

 

[casainho]

Hello
I am new to the forum and went through most of the post in this thread.
Great work - thanks to you big brains who have sacrificed so much time and effort to this project!
I I could not find an answer to the following beginner’s question here or in the wiki: I just ordered a 36v TSDZ2 motor, a 850C display and a 52V battery. If I want to flash the firmware to the 850C without the bootloader I will need the battery to power the display. Will this work with my wrong voltage of the battery (52 instead of 36)? Or would I first have to flash the motor/controller and set the correct value for the voltage? (And if the correct voltage has to be set first: How would I do that before my display works?)?
Thanks for your help.

It will work with any battery voltage, don't worry.

 

[btslo]

Today I did 2 tests: installed the alpha 9 version on the 36v engine, obviously it works great. thank you!
Unfortunately the emtb is still bad for me :-(
Later I tried to power the 48v bike with a 36v battery. It becomes very quiet, it is still fully usable on the road. I think we are the only ones who can use different batteries on a central
Thanks again.
but a small test of emtb based on power mode, just to see if it works?

Try a higher sensitivity for emtb, like 6-7 or 8.

 

[Rydon]

No more backwards resistance when braking for the Coaster Brake versions! Just tested, works great! Will add a couple more changes and features that should make the experience even better. For everyone!

That is awesome news. You guys truly rock!

 

[elem]

V 0.20 alpha 8 tested in a MTB ride, full ride using eMTB sensibility 7 , 32km 1000m D+, 275Wh used

eMTB could save energy

 

[andrea_104kg]

Today tour of 53 km, 800m altitude difference v. 20 alpha5, no off-road but all unpaved roads.
Full gt force mtb bike. Everything perfect, used only power mode trying to save on consumption but not too much, about 600wh consumed.
Thanks to the modification of the engine he never reached even the 70 ° even on slopes of 20%.
Weight of the cyclist over 100 kg. Maximum satisfaction!

 

[elfnino]

Have just a few points for the A9 finetune:

Odometer field 7:2,3
While setting average or peak speed in Odometer Field the AVG and MAX indication is shown in Wheel Speed Field and desired speed is shown in both fields (Odometer and Speed). However there is bug when AVG/MAX indication disappears after Odometer field menu 7 is changed and the desired speed value (peak/average) still remains in Wheel Speed Field.

Personally I would like to keep Current Speed in Wheel speed while simultaneously having average/peak in the Odometer Field.
I don't see any benefit of having same value in two field in the same time but community might not agree with me. But at least the the disappearing indication could be fixed easilly..

Cruise & Walk assist lunch from eMTB mode
With A9 the eMTB is really nice however each time to start Walk assist I have to downshift from eMTB to Assist level which is little annoying.

 

[buba]

Today I did 2 tests: installed the alpha 9 version on the 36v engine, obviously it works great. thank you!
Unfortunately the emtb is still bad for me :-(
Later I tried to power the 48v bike with a 36v battery. It becomes very quiet, it is still fully usable on the road. I think we are the only ones who can use different batteries on a central
Thanks again.
but a small test of emtb based on power mode, just to see if it works?

Very glad to hear that you had a great experience on the 36 V motor!

I am afraid to change the eMTB now because:

1. Users already use the current eMTB and some are satisfied.
2. I would need to create another eMTB based on power so users can switch between eMTB modes. This would take up more space and I am not comfortable to "borrow" more space when there are a lot more things to fit inside the motor controller.

It will be possible to further improve everything in the future. And then experiment with more functionality and different implementations! Imagine the difference the torque sensor calibration will have that Casainho is planning! So do not perceive the 0.20.0 as the final version. This project will always steadily improve and evolve!

I value the feedback from the community immensely! There will always be someone that thinks of something and then someone else thinks of another thing. And a third thing gets to be implemented that is perfect for all. Together we are slowly making the world's best firmware for the TSDZ2. Without the user suggestions and different views from everyone we would be nowhere close to the firmware we have today.

So I do hope you understand I respect your desire for a power based eMTB! It would be very simple to implement but it needs to go together with everything else planned. It will just take time and cooperation to make everything fit. For the time being, I truly hope you are satisfied with the Power Assist mode and that everything else is working perfectly for you!

 

[buba]

V 0.20 alpha 8 tested in a MTB ride, full ride using eMTB sensibility 7 , 32km 1000m D+, 275Wh used

eMTB could save energy

Amazing, Elem!

Today tour of 53 km, 800m altitude difference v. 20 alpha5, no off-road but all unpaved roads.
Full gt force mtb bike. Everything perfect, used only power mode trying to save on consumption but not too much, about 600wh consumed.
Thanks to the modification of the engine he never reached even the 70 ° even on slopes of 20%.
Weight of the cyclist over 100 kg. Maximum satisfaction!

That sounds great!

 

[buba]

Have just a few points for the A9 finetune:

Odometer field 7:2,3
While setting average or peak speed in Odometer Field the AVG and MAX indication is shown in Wheel Speed Field and desired speed is shown in both fields (Odometer and Speed). However there is bug when AVG/MAX indication disappears after Odometer field menu 7 is changed and the desired speed value (peak/average) still remains in Wheel Speed Field.

Personally I would like to keep Current Speed in Wheel speed while simultaneously having average/peak in the Odometer Field.
I don't see any benefit of having same value in two field in the same time but community might not agree with me. But at least the the disappearing indication could be fixed easilly..

That is actually a "feature" so that users can switch between Current/Average/Max speed and decide what they want in the Wheel Speed field to be displayed. This is similar to how many other e-bikes have it but you would prefer it to be limited to the odometer field? Or maybe only display when in the wheel speed sub menu?

More user inputs are welcome so we can decide for the best setup!

Cruise & Walk assist lunch from eMTB mode
With A9 the eMTB is really nice however each time to start Walk assist I have to downshift from eMTB to Assist level which is little annoying.

Glad to hear that, Elfnino!

Cruise should work when using eMTB but Walk Assist is different because you need to choose assist level for Walk Assist. And that is mainly why it is disabled when the assist level is 0 or eMTB. I would recommend to reduce the number of assist levels so you have less clicking to do and can quicker get to the assist level you need. Let me know if you have other suggestions!

Maybe: 3-4 Assist levels + eMTB? (If I am suggesting a setup you already use, I do apologize!)

 

[elfnino]

Have just a few points for the A9 finetune:

Odometer field 7:2,3
While setting average or peak speed in Odometer Field the AVG and MAX indication is shown in Wheel Speed Field and desired speed is shown in both fields (Odometer and Speed). However there is bug when AVG/MAX indication disappears after Odometer field menu 7 is changed and the desired speed value (peak/average) still remains in Wheel Speed Field.

Personally I would like to keep Current Speed in Wheel speed while simultaneously having average/peak in the Odometer Field.
I don't see any benefit of having same value in two field in the same time but community might not agree with me. But at least the the disappearing indication could be fixed easilly..

That is actually a "feature" so that users can switch between Current/Average/Max speed and decide what they want in the Wheel Speed field to be displayed. This is similar to how many other e-bikes have it but you would prefer it to be limited to the odometer field? Or maybe only display when in the wheel speed sub menu?

More user inputs are welcome so we can decide for the best setup!

Let's wait for more inputs..
Nevertheless in current implementation the display graphics AVG and MAX are not shown when Average/Max is selected
and Odometer Field has other than menu 7 selected. (It is displayed properly only with menu 7 in Odo field) I think it is kind of bug which could be fixed.

Cruise should work when using eMTB but Walk Assist is different because you need to choose assist level for Walk Assist. And that is mainly why it is disabled when the assist level is 0 or eMTB. I would recommend to reduce the number of assist levels so you have less clicking to do and can quicker get to the assist level you need. Let me know if you have other suggestions!

Maybe: 3-4 Assist levels + eMTB? (If I am suggesting a setup you already use, I do apologize!)

Actually less assist levels is not really helping. I use eMTB as the most powerful mode on the most difficult terrain and sometimes terrain is so difficult that I need to drop from the bike and use the Walk Assist and then continue with eMTB so it looks like : eMTB->Assist4->Walk->eMTB->Assist4-Walk . . .
May be the Walk Assist which is run from eMTB mode could inherit PWM duty cyckle value from the latest Assist level ?
Perhaps it is not that easy as I see it

 

[buba]

Have just a few points for the A9 finetune:

Odometer field 7:2,3
While setting average or peak speed in Odometer Field the AVG and MAX indication is shown in Wheel Speed Field and desired speed is shown in both fields (Odometer and Speed). However there is bug when AVG/MAX indication disappears after Odometer field menu 7 is changed and the desired speed value (peak/average) still remains in Wheel Speed Field.

Personally I would like to keep Current Speed in Wheel speed while simultaneously having average/peak in the Odometer Field.
I don't see any benefit of having same value in two field in the same time but community might not agree with me. But at least the the disappearing indication could be fixed easilly..

That is actually a "feature" so that users can switch between Current/Average/Max speed and decide what they want in the Wheel Speed field to be displayed. This is similar to how many other e-bikes have it but you would prefer it to be limited to the odometer field? Or maybe only display when in the wheel speed sub menu?

More user inputs are welcome so we can decide for the best setup!

Let's wait for more inputs..
Nevertheless in current implementation the display graphics AVG and MAX are not shown when Average/Max is selected
and Odometer Field has other than menu 7 selected. (It is displayed properly only with menu 7 in Odo field) I think it is kind of bug which could be fixed.

Now I see and understand what you mean! You are correct, the symbols are not displayed! Will fix and thank you for your quick reply! Can add this to the Alpha 10 thanks to your help!

Cruise should work when using eMTB but Walk Assist is different because you need to choose assist level for Walk Assist. And that is mainly why it is disabled when the assist level is 0 or eMTB. I would recommend to reduce the number of assist levels so you have less clicking to do and can quicker get to the assist level you need. Let me know if you have other suggestions!

Maybe: 3-4 Assist levels + eMTB? (If I am suggesting a setup you already use, I do apologize!)

Actually less assist levels is not really helping. I use eMTB as the most powerful mode on the most difficult terrain and sometimes terrain is so difficult that I need to drop from the bike and use the Walk Assist and then continue with eMTB so it looks like : eMTB->Assist4->Walk->eMTB->Assist4-Walk . . .
May be the Walk Assist which is run from eMTB mode could inherit PWM duty cyckle value from the latest Assist level ?
Perhaps it is not that easy as I see it

Do you mean that it should use the assist level just before eMTB? That could be possible to fix but I am afraid that some users have really high values and could get surprised if accidentally on eMTB and enabling Walk Assist.

I understand the inconvenience you are trying to solve though!

EDIT: Have fixed the bug you reported! Thank you!

 

[perryscope]

Do you mean that it should use the assist level just before eMTB? That could be possible to fix but I am afraid that some users have really high values and could get surprised if accidentally on eMTB and enabling Walk Assist.

I understand the inconvenience you are trying to solve though!

EDIT: Have fixed the bug you reported! Thank you!

Just an idea but could you maybe store the last walkassist level used and assume that's a good starting point and set to that level unless the user changes the level while using walkassist, at which point you save the last level again?

I know i tend to use the same walkassist level when i use it and only change a little but another user will likely want a different level.

when you leave WalkAssist you could then return to the previous assist level /eMTB you were on , if you go back into walkassist you should still be at the right level as you were before.