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

[buba]

Upgraded from Alpha 3 directly to Alpha 5.

I have enabled and calibrated the advanced cadence sensor mode.

Cadence issue
Perfect again. Assistance well above 110rpm so plenty for me!

That feedback:

Power Assist
Power delivery seams smoother but overall assistance and therefore motor power is slightly higher, I had to reduce multipliers by about 0.2 each to get it to feel similar to 0.19.0 assistance levels.
This now feels similar at lower general human power, but I feel that if i push hard in lower assistance levels I can now get more assistance than I used to. Basically if feels like the range of the torque sensor is higher and therefore there is more assistance available if needed.

Not a bad thing but i have to say i find i am not really needing to change assistance level as much now. and tend to ride in level 3 out of 9 most of the time.

In some ways I prefer that and would consider dropping to 5 levels of assistance as its nice not to have to keep changing assistance level as much.

I think you are the first one to notice the increased operating range! Depending on setup and how the system is used it can be difficult to notice but the operating range is bigger and the resolution is many times higher in the 0.20.0. This has been an open secret and I just hoped somebody would notice!

So what you report is totally in line with how it should be. You will feel that the startup assistance will be greater as everyone usually pushes the pedals hard on startup. And now it will actually give more assistance when pushing harder. It will also be more responsive in every assist level as you note.

I will take that as very good feedback!

EMTB mode

Wow this really does work well now! Actually kind of loving this mode for general riding, It really feels sensitive to the torque applied and you can ride it at lower levels of motor power easily it just tends to hunt a little due to it being so sensitive so for road riding commuting, power assist mode for me is smoother overall. but for changing terrain and surface quality its a real joy to have immediate power on tap just by pushing hard. Awesome job!

Only thing I would say is that you have to go through many assist levels to enable it. I tend to ride in assist 3 so 7 presses of the up button is needed to enable EMTB mode, then to disable and return to assist level 3 again is 7 mode presses, can be a bit of a pain. Another reason why I am considering dropping to 5 levels of assist.

Might be worth considering a quicker way to enable this mode? Power and down together to jump direct to EMTB and again to return to previous level of assistance? I appreciate we are very limited to options here and down want to over complicate things.

I can try to make eMTB better and hunt less! So whatever sensitivity you set will work fine in the lower ranges. But very good and glad to know that you are satisfied with the eMTB mode! Thank you, Perryscope! It will only get better and better!

I do want to add that I experimented with a two variable eMTB setup. You would setup sensitivity and let us call it curve. Those two could pretty much define whatever characteristic you prefer and make the experience very natural. But this would mean eMTB would take more program space and I do not want to just "steal" all the available space.

Just to keep things simple for now, would it be possible if you try 4-5 assist levels for the default riding mode and then have eMTB over that? That would reduce the clicking and maybe work perfectly fine. Sorry for asking that. I hate rejecting otherwise very valid suggestions but am limited with program space and am trying to keep everything simple. I actually envisioned that users would reduce the assist levels maybe down to 2-3 and have eMTB on top for the extra power.

Cadence Mode
I have only done a quick test of this mode and to be honest it feels very similar to a hub motor with pedal assist sensor. Yes its very different when your used to torque sensing, but for those with the need for a smoother less sensitive assistance its great. I will have more feedback on this mode once my rider with special needs has had a test ride in the next few weeks.

I do agree. When in the same gear it is exactly as any other direct drive hub motor setup with a simple sensor measuring pedal rotation. When changing gears the ratio changes and there might be some more or less assistance. But in that case it is maybe better to stick to one gear and instead switch assist levels. And maybe more natural for some users. For single speed bikes there are no problems.

Awaiting more feedback

Filtering of display power reading

Yes definitely much less jumping around. I think the peeks are still higher that 0.19.0 but I am guessing more accurate, so its just a case of getting used to it I think.

Will improve this some more! There is a fine balance between accuracy and smoothness so will try to find a sweet spot.

Light modes
I have done some basic testing of these modes and here is a little video showing them working...

[youtube]gVfoSoI1MuM[/youtube]

Each mode works as expected, and I can understand why this is low priority but I would say a missing mode for me is.

(7) lights FLASHING when enabled, but ON when braking regardless if lights are enabled

That's what I would use generally.

I understand there are capacitors on the light circuit so faster flashing would be difficult to achieve?, which again would be preferable as I feel its more visible but its nick picking and very low priority

I can add that and increase the frequency! And thank you for the video! I was hoping someone would post a video showing off how it works!

Overall, Thank you for the detailed post and taking the time to write and explain what you think! Means a lot for the entire community!

 

[buba]

As for the weight on the pedals measurement. It could be added but I think what would be best is to remove the pedal torque value displayed together with cadence and human power and replace it with the weight on pedals. Would that be okay with everyone? That would maybe be more natural.

I think that untill torque sensor is fully calibrated, showing weight on pedals will be a very wrong value and will be a frustration to users as it implies an expectation that it will show a correct value.

Yes, but I just thought to replace the pedal torque with the pedal weight on the 4. Pedal Data. Seeing the pedal weight is better as more users understand that compared to torque. And that will only get better with the coming torque calibration you will implement. I know it is not accurate but we have two choices:

- Remove the pedal torque value in 4. Pedal Data (odometer field)
- Replace the pedal torque value with pedal weight (odometer field)

My torque sensor without calibration shows at least up to 40 kg and I think that is good enough to keep everything as it is but just replace pedal torque with weight in the odometer field. Again, I think this is good enough for the 0.20.0 and until you create the 0.21 with the pedal torque calibration.

Otherwise I think we should remove the pedal torque value. But that would be a bad idea as users are using Power Assist. And that is very dependent on users having the possibility to adjust the ADC pedal torque conversion and adjusting it. Because all users are now defaulted to your measurements and conversion numbers.

 

[perryscope]

I think you are the first one to notice the increased operating range! Depending on setup and how the system is used it can be difficult to notice but the operating range is bigger and the resolution is many times higher in the 0.20.0. This has been an open secret and I just hoped somebody would notice!

So what you report is totally in line with how it should be. You will feel that the startup assistance will be greater as everyone usually pushes the pedals hard on startup. And now it will actually give more assistance when pushing harder. It will also be more responsive in every assist level as you note.

I will take that as very good feedback!

Ooh , do I win anything? :wink:

Just to keep things simple for now, would it be possible if you try 4-5 assist levels for the default riding mode and then have eMTB over that? That would reduce the clicking and maybe work perfectly fine. Sorry for asking that. I hate rejecting otherwise very valid suggestions but am limited with program space and am trying to keep everything simple. I actually envisioned that users would reduce the assist levels maybe down to 2-3 and have eMTB on top for the extra power.

Yes I kinda came to that conclusion, The only reason i ran 9 assist levels was to have quick and fine adjustment of the assist i was getting to suite the terrain, but if I can have more control by varying my riding style ( push harder and pedal harder for a short burst) and cut that down to like you say 3 levels the jump to eMTB is much less hassle and an easier to use mode. I may experiment with that. Feels a bit like when i went from a 3 x 7 gear setup to 1 x 9 yes you have less gears but the right gears, simple but effective.

 

[buba]

I think you are the first one to notice the increased operating range! Depending on setup and how the system is used it can be difficult to notice but the operating range is bigger and the resolution is many times higher in the 0.20.0. This has been an open secret and I just hoped somebody would notice!

So what you report is totally in line with how it should be. You will feel that the startup assistance will be greater as everyone usually pushes the pedals hard on startup. And now it will actually give more assistance when pushing harder. It will also be more responsive in every assist level as you note.

I will take that as very good feedback!

Ooh , do I win anything? :wink:

How about you get the light behavior you wanted in an Alpha version that will be released within one hour? :wink: And you get slightly faster flash frequency! And maybe some other small things!

https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/0.20.0-(DEVELOPMENT)-%7C-KT-LCD3-%7C-TSDZ2-%7C-Manual#10_Advanced_Setup

Just to keep things simple for now, would it be possible if you try 4-5 assist levels for the default riding mode and then have eMTB over that? That would reduce the clicking and maybe work perfectly fine. Sorry for asking that. I hate rejecting otherwise very valid suggestions but am limited with program space and am trying to keep everything simple. I actually envisioned that users would reduce the assist levels maybe down to 2-3 and have eMTB on top for the extra power.

Yes I kinda came to that conclusion, The only reason i ran 9 assist levels was to have quick and fine adjustment of the assist i was getting to suite the terrain, but if I can have more control by varying my riding style ( push harder and pedal harder for a short burst) and cut that down to like you say 3 levels the jump to eMTB is much less hassle and an easier to use mode. I may experiment with that. Feels a bit like when i went from a 3 x 7 gear setup to 1 x 9 yes you have less gears but the right gears, simple but effective.

You totally understand what I thought and envisioned! Try it out and we will make adjustments in one way or another if it just does not work!

 

[casainho]

As for the weight on the pedals measurement. It could be added but I think what would be best is to remove the pedal torque value displayed together with cadence and human power and replace it with the weight on pedals. Would that be okay with everyone? That would maybe be more natural.

I think that untill torque sensor is fully calibrated, showing weight on pedals will be a very wrong value and will be a frustration to users as it implies an expectation that it will show a correct value.

Yes, but I just thought to replace the pedal torque with the pedal weight on the 4. Pedal Data. Seeing the pedal weight is better as more users understand that compared to torque. And that will only get better with the coming torque calibration you will implement. I know it is not accurate but we have two choices:

- Remove the pedal torque value in 4. Pedal Data (odometer field)
- Replace the pedal torque value with pedal weight (odometer field)

My torque sensor without calibration shows at least up to 40 kg and I think that is good enough to keep everything as it is but just replace pedal torque with weight in the odometer field. Again, I think this is good enough for the 0.20.0 and until you create the 0.21 with the pedal torque calibration.

Otherwise I think we should remove the pedal torque value. But that would be a bad idea as users are using Power Assist. And that is very dependent on users having the possibility to adjust the ADC pedal torque conversion and adjusting it. Because all users are now defaulted to your measurements and conversion numbers.

Well, I just did that, exchanged pedal torque value to pedal weight value, so users can see that torque sensor full calibration is working as expected. I agree that is much more understandable by final user the value to be in weight.

 

[casainho]

Today I was testing the firmware and update process using Bluetooth of SW102.

And I forgot to say that as we can see on the screenshot, there 2 services (cycling speed and cadence, battery) that are specific for integration/sending data to Strava!!

The Nordic UART service is the regular UART transmission of data just like happens now between the display and the motor controller, but this time from the display to mobile app:

 

[buba]

Well, I just did that, exchanged pedal torque value to pedal weight value, so users can see that torque sensor full calibration is working as expected. I agree that is much more understandable by final user the value to be in weight.

That will be very nice to see on a graph as well! We get a lot of data now from the motor controller but sadly we do not use it in any meaningful way except display on the KT-LCD3. But for the users that love riding data it will make a big difference with the new displays.

 

[geeksville]

yep! Though fair warning, I've only implemented the battery profile fully so far. so the CSC profile to upload cadence/speed (and related pedal power profile) aren't fully complete yet. They will enumerate but the data I'm sending up is marked invalid for now.

 

[e3s]

Today I was testing the firmware and update process using Bluetooth of SW102.

And I forgot to say that as we can see on the screenshot, there 2 services (cycling speed and cadence, battery) that are specific for integration/sending data to Strava!!

The Nordic UART service is the regular UART transmission of data just like happens now between the display and the motor controller, but this time from the display to mobile app:

For other fitness app is the same thing?

 

[casainho]

yep! Though fair warning, I've only implemented the battery profile fully so far. so the CSC profile to upload cadence/speed (and related pedal power profile) aren't fully complete yet. They will enumerate but the data I'm sending up is marked invalid for now.

I am not a Strava user but I went to the app, started a search for the sensors and then OS-EBike sensors did appear and I was able to pair with them

 

[geeksville]

btw: I'm even more excited about the option of exposing human pedal power input. Which I probably won't get to for a few wks.

For anyone curious, the SW102 task list is here: https://github.com/OpenSource-EBike-firmware/SW102_LCD_Bluetooth/blob/master/TODO.md

and yep: these profiles are standard so any fitness app that talks to bluetooth sensors should be fine (not just Strava).

 

[casainho]

btw: I'm even more excited about the option of exposing human pedal power input. Which I probably won't get to for a few wks.

Well, pedal human power just makes sense when firmware has the torque sensor full calibration and although I already did implement that, it is not yet on development branch nor tested by other users, so will probably take that few weeks anyway

 

[btslo]

Is the cable on the SW102 really that short like in the pictures? (~10cm)

 

[buba]

Alpha 6 is here but is optional! It has some small improvements!

It is not necessary to try out the Alpha 6 unless you want to test the small changes made. The changes are listed below.

------------------------

Here is the wiki (work in progress):
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/0.20.0-(DEVELOPMENT)-%7C-KT-LCD3-%7C-TSDZ2-%7C-Manual

------------------------

Here is my Google Drive folder with the Alpha 6:
https://drive.google.com/open?id=1CPGT-V1ZX7FCzfhgbrPMYfbYtY4_JH2R

------------------------

Here is my branch where you can see the source code and latest changes:
https://github.com/leon927/TSDZ2-Smart-EBike/tree/testing-pwm-acc

------------------------

Here are the changes from Alpha 5:
- Tuned filtering
- More light configurations and increased flashing frequency slightly
- Removed pedal torque and replaced with pedal weight
- Added light symbol in configuration menu 10:5

------------------------

Comment:
The variables that are filtered in the display are:
- Battery voltage
- Battery Current
- Battery Power
- Pedal Power
- Pedal Cadence
- Pedal Weight

Let me know if you feel that something needs to be changed as for the filtering on those values. If you want the latest changes then you will have to update to the Alpha 6. Otherwise if you are happy with the Alpha 5 you will most probably be happy with the Alpha 6 changes. So no need to update.

 

[perryscope]

Is the cable on the SW102 really that short like in the pictures? (~10cm)

my cable is 62CM

 

[buba]

Users using the imperial system:

What are the shortcomings on the KTLCD3 in regard to displaying imperial units? What are the things you would like to be improved to have it be perfect in this regards?

Not saying this will be possible to implement due to program space constraints but want to know if there is anything I have missed that should be sorted out. Just so that we know.

Here are a couple of things I have noticed:

- Motor temperature in Fahrenheit
- Pedal Weight in pounds
- Street Mode speed limit in MPH

 

[casainho]

Is the cable on the SW102 really that short like in the pictures? (~10cm)

my cable is 62CM
sw102-cable.JPG

Here is my way that I think is safe and most easy (yes, I already break 2 units of SW102 before having this idea). If this works for others, maybe we should put on wiki:

I just went to cut a lateral from SW102 so I could solder the 3 wires for STLinkV2. I am not using the 3V3 as I am powering the SW102 from battery -- I think this is better as it is one less wire to solder and it is a bit hard to solder them on SW102.

I started to use a hand saw for metal and did cut the lateral part:





Then I simpled break it when I pulled with pliers.
Here the pads exposed. I had to I pull with pliers a small rubber sheet and had to cut a bit a plastic with a cuter knife:



Finally I soldered the 3 wires carefully and made sure there was no short circuits on them:



After flashing the bootloader and the firmware, it runs!!



Finally I can use the parts I removed and glue it. After all this, the key pad is working perfectly as original:

 

[perryscope]

Users using the imperial system:

What are the shortcomings on the KTLCD3 in regard to displaying imperial units? What are the things you would like to be improved to have it be perfect in this regards?

Not saying this will be possible to implement due to program space constraints but want to know if there is anything I have missed that should be sorted out. Just so that we know.

Here are a couple of things I have noticed:

- Motor temperature in Fahrenheit
- Pedal Weight in pounds
- Street Mode speed limit in MPH

One thing I would stress which is currently correct. In the UK we like to mix things up so we use MPH but Deg Centigrade not Fahrenheit abd KG or stones and pounds for human wieght depending on your age!

Yes I know don't ask!

I often find systems that let you choose metric or imperial change all references and don't let you have the granularity. In the US they use MPH and Fahrenheit and pounds as far as I know?

So good to allow either for each option if that makes sense.

 

[buba]

Users using the imperial system:

What are the shortcomings on the KTLCD3 in regard to displaying imperial units? What are the things you would like to be improved to have it be perfect in this regards?

Not saying this will be possible to implement due to program space constraints but want to know if there is anything I have missed that should be sorted out. Just so that we know.

Here are a couple of things I have noticed:

- Motor temperature in Fahrenheit
- Pedal Weight in pounds
- Street Mode speed limit in MPH

One thing I would stress which is currently correct. In the UK we like to mix things up so we use MPH but Deg Centigrade not Fahrenheit abd KG or stones and pounds for human wieght depending on your age!

Yes I know don't ask!

I often find systems that let you choose metric or imperial change all references and don't let you have the granularity. In the US they use MPH and Fahrenheit and pounds as far as I know?

So good to allow either for each option if that makes sense.

Did not know that there is even a difference from generation to generation as well. So basically, in the best of worlds we would have options to configure whatever we wish to see because it is not as easy as one, two and three. :wink:

Will remember that and have in consideration!

 

[e3s]

Here is my way that I think is safe and most easy (yes, I already break 2 units of SW102 before having this idea). If this works for others, maybe we should put on wiki:

I just went to cut a lateral from SW102 so I could solder the 3 wires for STLinkV2. I am not using the 3V3 as I am powering the SW102 from battery -- I think this is better as it is one less wire to solder and it is a bit hard to solder them on SW102.

I started to use a hand saw for metal and did cut the lateral part

nice idea. It's a good alternative. So removing the pads as you made before you can brake the lcd structure?

 

[Waynemarlow]

I just went to cut a lateral from SW102 so I could solder the 3 wires for STLinkV2. I am not using the 3V3 as I am powering the SW102 from battery -- I think this is better as it is one less wire to solder and it is a bit hard to solder them on SW102.

If you know exactly which pad and its precise location, could you not simply drill 3 small holes and insert a probe onto each ? Once the bootloader is installed simply put a blob of silicon over the holes.

 

[geeksville]

I've just released our first end-user friendly alpha release of the SW102 code. Please see this thread for details:

https://endless-sphere.com/forums/viewtopic.php?f=30&t=99698&p=1488556#p1488554

 

[casainho]

I've just released our first end-user friendly alpha release of the SW102 code. Please see this thread for details:

https://endless-sphere.com/forums/viewtopic.php?f=30&t=99698&p=1488556#p1488554

I think we should add SW102 as an option on the wiki but noting that is alpha for now. The structure of firmware is way better than on the other LCDs, you are very experienced, I am sure it will become stable very soon.

Also it is very important that you want to make a common base firmware for both SW102 and 850C, that means 850C project quality will improve much from what is currently.

850C LCD can be programmed just like the TSDZ2 motor controller, without open the LCD anytime. On contrary, the SW102 is harder than LCD3. Maybe in future we can find a way to program SW102 just like 850C.

 

[mctubster]

Very excited to hear that and good to know what sensitivity level you are using! But also what you would prefer. I think it would be possible to improve the formula so eMTB is operating better and can fit your needs with only one assist mode. It should be great in any sensitivity level, that is the goal. Will consider everything you have said and think about it!

Hi Buba - potentially I missed it, but could you please explain the logic behind eMTB mode? It feels a bias toward torque at low rpm and then more toward power at higher rpm?

Anyway it is great. Successfully retired boost assist and also no random lags when starting off.

 

[Rafe]

Users using the imperial system:



Not saying this will be possible to implement due to program space constraints but want to know if there is anything I have missed that should be sorted out. Just so that we know.

Here are a couple of things I have noticed:

- Motor temperature in Fahrenheit
- Pedal Weight in pounds
- Street Mode speed limit in MPH

MPH a definite must.
Weight we still weigh our bodies in in stones and pounds and a lot of food, I won't even bother to explain the complexities of buying coal by the hundred weight :wink: KG is fine
Temp in either but Fahrenheit is my preferred purely because it is more sensitive ie 32 f to 100f is 68 increments but only 37.7 increments in degrees Celsius
If you are going to add an altimeter then in feet please.