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

[marcoq]

Yes walk assist is open loop here a part of code:
View attachment code.c

 

[Ron Paul's Blimp]

Can I play devil's advocate? I think it might be really good for the overall project to include support for the OEM displays. I think there are probably a lot of people who would love to experiment with the firmware but are turned away by the need for a bunch of soldering and figuring out what donor cables to buy and all of that.

Supporting the OEM displays significantly lowers the barrier to entry -- no need to purchase a new display from China, no need to open any components, less soldering and much less confusing install process.

Then, once people have experimented using the OEM display they already have, the people who want more advanced display features will have an easier next step to trying one of the opensource displays. They already have their feet wet, it's less daunting to make an incremental step to the next thing.

One could imagine someone selling some products to make this easier (maybe a nice way for casainho to be rewarded for his efforts if he were interested in doing it):

1. Sell a programming cable (like Luna sells for Bafang). Paired with marcoq's eeprom configuration UI, this is everything the novice user would need to get started. They buy a single thing for $20 - $30, download hex files and the config tool, and they're up and running.

2. Sell 850C displays with the proper connector already in place and a stable version of the firmware already flashed for users who want to take the next step. They've already been able to try the firmware using their OEM displays, so they're already 'hooked' and it's an easier decision.

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

Can you talk a little about those advanced features? It seems like, in terms of configuration, we can just move the advanced configuration to be done at flashing time instead of configured on the display, using marcoq's UI. This is what people already do with the bafang mid-drives. In terms of display (the nice graphs and such you're making for the 850C), well obviously the OEM display can't show those -- but neither can the KT-LCD3, and neither could the KT-LCD5, if we ported your firmware to that.

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

I might be misunderstanding or oversimplifying, but after reading the diffs between marcoq's tree and yours, it didn't seem so bad to me? If you want to add a new configuration variable to your opensource displays, we just need to add it to the new config tool for the OEM displays. You personally could probably just do nothing. You release version N of your firmware that uses a new variable, and people using OEM display will make the needed changes to the config tool because they'll know they can't use version N with OEM displays until they do that.

If you want to send a new variable from the controller to the opensource displays to show something fancy, well, we just literally do nothing for OEM (i.e., don't change the OEM serialization function). People using OEM displays miss out. Maybe it encourages them to want to buy an 850C from you.

In other words, it seems like the only main places of code divergence are: 1. adding uart serialization / deserialization functions for OEM displays (marcoq already did this), 2. adding a simple abstraction layer to the config variables (so they can come from either eeprom or the display), and 3. adding a tool to write config vars to eeprom. #1 will never change since the OEM display firmware won't change. #2 should be very low-touch. #3 will need updating, but you don't need to do it personally. That tool can live in marcoq's tree even (or someone else's if he doesn't want to maintain it).

 

[marcoq]

I have released the new version of the Controller firmware compatible with both the VLCD6 and KT-LCD3 diplay. I have also released the Java configuration interface (TSDZ2 Configurator ver. 0.1.0).
Have a good day.

https://github.com/qmarco/TSDZ2-Smart-EBike-compatible-with-original-VlCD6-display/blob/master/README.md

 

[Ron Paul's Blimp]

When wiring up the KT-LCD3, if you're not using brake sensors, what do you do with the brake wire from the controller? Leave it unconnected? Or tie it to P+ (green on 6 pin, blue on 8 pin)?

 

[casainho]

When wiring up the KT-LCD3, if you're not using brake sensors, what do you do with the brake wire from the controller? Leave it unconnected? Or tie it to P+ (green on 6 pin, blue on 8 pin)?

I think you can leave the wires unconnected. I will put this note on the wiki.

 

[marcoq]

I have released the new version of the Controller firmware compatible with both the VLCD6 and KT-LCD3 diplay. I have also released the Java configuration interface (TSDZ2 Configurator ver. 0.1.0).
Have a good day.

https://github.com/qmarco/TSDZ2-Smart-EBike-compatible-with-original-VlCD6-display/blob/master/README.md

Excuse me .... this is the right link: https://github.com/qmarco/TSDZ2-Smart-EBike-compatible-with-original-VlCD6-display

 

[stancecoke]

I have released the new version of the Controller firmware compatible with both the VLCD6 and KT-LCD3 diplay. I have also released the Java configuration interface (TSDZ2 Configurator ver. 0.1.0).

Great work!
But please don't send tanks to me, as I am a pacifist

regards
stancecoke

 

[marcoq]

I have released the new version of the Controller firmware compatible with both the VLCD6 and KT-LCD3 diplay. I have also released the Java configuration interface (TSDZ2 Configurator ver. 0.1.0).

Great work!
But please don't send tanks to me, as I am a pacifist

regards
stancecoke

stancecoke! My project was born thanks to your "template"!!!

 

[marcoq]

I forgot that for use TDSZ2-Configurator... SDCC compiler must be installed as explained by casainho here: https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Development

 

[stancecoke]

My project was born thanks to your "template"!!!

I just had to smile about your typo :wink:

tanks --> carro armato
thanks --> grazie

A tutorial for setting up the toolchain in windows is on our Wiki-pages. Of course you have to use marcoq's repo instead of the Kunteng-repo.
The batch-files don't work, if the zipfiles are extracted with the default path-names (too long or special charakters, I don't know.)
Why do you zip the project at github at all? (I know, git is not selfexplaining, but there are enough short tutorials how to syncronize your local workspace with github and there are just a very few commands to to learn....)

regards
stancecoke

 

[Djoene]

I have released the new version of the Controller firmware compatible with both the VLCD6 and KT-LCD3 diplay. I have also released the Java configuration interface (TSDZ2 Configurator ver. 0.1.0).

Great work!
But please don't send tanks to me, as I am a pacifist

regards
stancecoke

I see the experimental high cadence mode, does it work with the 48V motor and LCD6?

 

[casainho]

After many years of ebikes and Endless Sphere forum, I think I started the first and only one (up to now) OpenSource firmware for ebikes!! and took some years, it was not quick and cheap, but was strategic.

Some days ago I got in a chat with another OEM, that reflects what I would not like to happen:

I will introduce myself before going further. My name is ZZZZZ and I have a small shop in ZZZZZ where I transform "normal" bikes into electric bikes. My goal is to make people happy, get more people on bikes, help old and disabled persons to be able to ride bicycles and improve the environment. Of course, as it is my job I try to earn enough money to feed my family also.
I hardly sell parts, my business is really to "create" systems adapted to the needs of my clients and build it on their bikes.

(...)

My goal is to have an EU legal version (as I risk 5 years of prison and €11000 fine if my shop sells "illegal bikes") that I can setup for my clients needs and build on their bikes.
Clients shouldn't have easy access to advanced settings for before mentioned legal reasons.

So, the flexibility of our firmware is important for OEMs (after all, they would need to pay to factory for custom features!) but in the end they will lock out the users, be it because legal reasons, warranty, protect business model, etc.

I am not against OEMs, business or laws, but protecting the environment is a higher objective, above all!!

So, my focus will continue to be developing and share knowledge and technology (as OpenSource) for final users as me and that seems to go kind of against the manufactures/OEMs/sellers. I want to put my very limited resources only on a path that will provide final users with flexibility, even if that means not the most quick and cheap solutions.

To resume: I want to only focus my energy on developing firmware for TSDZ2 + LCDs that let final users have all the freedom and advanced features (contrary to the needs of manufactures/OEMs/sellers that are asking for cheap and quick solutions and that lock out the final users).

Can I play devil's advocate? I think it might be really good for the overall project to include support for the OEM displays. I think there are probably a lot of people who would love to experiment with the firmware but are turned away by the need for a bunch of soldering and figuring out what donor cables to buy and all of that.

Supporting the OEM displays significantly lowers the barrier to entry -- no need to purchase a new display from China, no need to open any components, less soldering and much less confusing install process.

Then, once people have experimented using the OEM display they already have, the people who want more advanced display features will have an easier next step to trying one of the opensource displays. They already have their feet wet, it's less daunting to make an incremental step to the next thing.

One could imagine someone selling some products to make this easier (maybe a nice way for casainho to be rewarded for his efforts if he were interested in doing it):

1. Sell a programming cable (like Luna sells for Bafang). Paired with marcoq's eeprom configuration UI, this is everything the novice user would need to get started. They buy a single thing for $20 - $30, download hex files and the config tool, and they're up and running.

2. Sell 850C displays with the proper connector already in place and a stable version of the firmware already flashed for users who want to take the next step. They've already been able to try the firmware using their OEM displays, so they're already 'hooked' and it's an easier decision.

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

Can you talk a little about those advanced features? It seems like, in terms of configuration, we can just move the advanced configuration to be done at flashing time instead of configured on the display, using marcoq's UI. This is what people already do with the bafang mid-drives. In terms of display (the nice graphs and such you're making for the 850C), well obviously the OEM display can't show those -- but neither can the KT-LCD3, and neither could the KT-LCD5, if we ported your firmware to that.

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

I might be misunderstanding or oversimplifying, but after reading the diffs between marcoq's tree and yours, it didn't seem so bad to me? If you want to add a new configuration variable to your opensource displays, we just need to add it to the new config tool for the OEM displays. You personally could probably just do nothing. You release version N of your firmware that uses a new variable, and people using OEM display will make the needed changes to the config tool because they'll know they can't use version N with OEM displays until they do that.

If you want to send a new variable from the controller to the opensource displays to show something fancy, well, we just literally do nothing for OEM (i.e., don't change the OEM serialization function). People using OEM displays miss out. Maybe it encourages them to want to buy an 850C from you.

In other words, it seems like the only main places of code divergence are: 1. adding uart serialization / deserialization functions for OEM displays (marcoq already did this), 2. adding a simple abstraction layer to the config variables (so they can come from either eeprom or the display), and 3. adding a tool to write config vars to eeprom. #1 will never change since the OEM display firmware won't change. #2 should be very low-touch. #3 will need updating, but you don't need to do it personally. That tool can live in marcoq's tree even (or someone else's if he doesn't want to maintain it).

 

[Ron Paul's Blimp]

I am not against OEMs, business or laws, but protecting the environment is a higher objective, above all!!

So, my focus will continue to be developing and share knowledge and technology (as OpenSource) for final users as me and that seems to go kind of against the manufactures/OEMs/sellers. I want to put my very limited resources only on a path that will provide final users with flexibility, even if that means not the most quick and cheap solutions.

To resume: I want to only focus my energy on developing firmware for TSDZ2 + LCDs that let final users have all the freedom and advanced features (contrary to the needs of manufactures/OEMs/sellers that are asking for cheap and quick solutions and that lock out the final users).

Thanks for taking the time to explain your thought process. I still see it differently, but respect your motivations even if we can't agree on the outcome. To me, supporting the OEM displays provides the end user with more flexibility, not less. I picture a continuum of freedom, from least freedom to most:

1. Someone with a motor that can't be programmed / configured at all has the least freedom.
2. Someone with a motor like a BBS02/HD that they can flash advanced / OEM-only settings onto has more freedom.
3. Someone with a TSDZ2 with an OEM display has even more (because in addition to the freedom in #2, they can also read, modify, and install the opensource firmware).
4. Someone with a TSDZ2 with an 850C has the most (because they also have full control over the display).

You seem to be saying you don't want to make room for group 2 or group 3 in the project. But I see group 3 as a pathway to get people from group 1 moving towards group 4, not as a locked door. We're not locking anyone out of anything, because anyone who wants to can go buy a KT-LCD3 or 850C, just like they would have had to do anyway. But we make it easier for them by offering an iterative path. There may be people who get as far as 3 and stop because they don't want the advanced display features, but they'd be doing that by their own choice.

I see this from my own perspective as an end user; I'm not an OEM and I have no business interests in this space. I would rather have the additional choice and flexibility of using a wider variety of displays, especially including the display that came with my motor, even if it's just temporarily while I try out the firmware, and I later decide to use an advanced display.

From reading this thread, I think this is a common enough desire among end users that someone will probably fork the project, and I'd love to see all of the effort stay focused into a single repo where everyone can benefit rather than having the community split. From your email it sounds like the EU resellers will have a very strong motivation to do this.

It reminds me a bit of Linux working with peripherals with closed-source firmware. We all found it distasteful needing to install a binary blob of closed-source firmware for our wifi adapters to work on OEM laptops, but it was better than not using Linux at all, and it didn't serve the Linux community's goals to take a hard line and close off that part of the ecosystem and limit the user base to only people with the money and skills to replace a wifi card.

Thanks again for listening and offering your perspective (and all of your efforts!); I won't keep arguing with you about it

 

[elem]

First time i tried open source firmware in real mountain climbing conditions ...

it feel good !

36km, 1450D+, 278wh used .
seems it s using better energy than stock firmware, less destructive for primary gear ( nylon gear ) etc ...
feel less noise too .

next improvment will be build my own 12S battery, actualy using a 10S battery .

I don t know what human power could be but it seem it s " sur-estimated ", i don t thinck i m able to run about 400w
was using a small set-up, lvl 1 : 0.4*, lvl2 : 0.8* ... as i am running often with some friends without motor it s suffisant .

I must learn more about the use of LCD3 .

Thancks all, great improvment !

 

[Rafe]

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

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

Changes:

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

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

All looking very good indeed for Beta 5. The elapsed time function is yet another good idea. So much information is now available to the user to pass the time away on a long ride (carrying a printout of the functions essential). I've only given it a short test today but will try to get 50 or so miles in the next few days but have found no obvious bugs so far.

The only exception which you already know about is that indicated human power is still about twice what it should be but at least buba has reduced it by half from the extremely high readings (4x) in Beta 4. Accordingly I have my 9 assist level multipliers spaced from 0.2 to 2.0. 0.2x delivers a decent eco option of around 100 watts motor power and 2.0x is crazy running very late up a 20% hill power. (52v battery)

I only purchased the TSDZ2 out of interest much preferring to use the Bafang BBSHD but thanks to your software I have hardly used the BBSHD lately. If only the gearing was not so noisy.

Cheers.

 

[marcoq]

Here https://github.com/qmarco/TSDZ2-Smart-EBike-compatible-with-original-VlCD6-display I have updated my Repository... some bugs are now fixed.

 

[elem]

If only the gearing was not so noisy.

yes ! metal gear ... i don t like it .
will be back to nylon gear as open source firmware better for preserving nylon gear .

Was a long time i haven t used used metal gear, i can t ride whith this noise

 

[Rafe]

If only the gearing was not so noisy.

yes ! metal gear ... i don t like it .
will be back to nylon gear as open source firmware better for preserving nylon gear .

Was a long time i haven t used used metal gear, i can t ride whith this noise

The major problem I have found with open source software and the blue gear is throttle control, as it is either fully on or off with no actual throttling and as I have to improvise and use the throttle for walk assist in bottom gear up a 33% slope I have to be really careful as I start off climbing that it does not strip the blue gear when the panniers are full and heavy, in fact the only sensible way over this route is to run with the metal gear. The more I load the gearing the more silent it is though, with maximum noise in pedal assist 1 especially when the drive is lightly loaded and there is loads of backlash in the gear train.

 

[elem]

i don t use throttle, i hope for a wonderfull " walk assist " ...

Sometimes it s necessary to use walk assist in mountain climbing .

With stock firmware walk assist worked, but it was a " poor " walk assist, not really usefull,
i dream for a "walk assit " more powerfull and usefull .

 

[casainho]

i don t use throttle, i hope for a wonderfull " walk assist " ...

Sometimes it s necessary to use walk assist in mountain climbing .

With stock firmware walk assist worked, but it was a " poor " walk assist, not really usefull,
i dream for a "walk assit " more powerfull and usefull .

Same with me, even my throttle connection is used to the temperature sensor.

But sometimes I need a throttle when something broke on pedals/transmission/etc so I would like to implement virtual throttle, maybe a bit like what we need for a good walk assist where user can quick increase/decrease the wheel speedat values like 3km/h up to 6km/h. Power must also be configured.

 

[Rafe]

i don t use throttle, i hope for a wonderfull " walk assist " ...

Sometimes it s necessary to use walk assist in mountain climbing .

With stock firmware walk assist worked, but it was a " poor " walk assist, not really usefull,
i dream for a "walk assit " more powerfull and usefull .

Same with me, even my throttle connection is used to the temperature sensor.

But sometimes I need a throttle when something broke on pedals/transmission/etc so I would like to implement virtual throttle, maybe a bit like what we need for a good walk assist where user can quick increase/decrease the wheel speedat values like 3km/h up to 6km/h. Power must also be configured.

That is an excellent idea. Not for just when a pedal is broken but when climbing a trail in a deep rut and it is not possible to pedal which is the other main reason I like to have a throttle. And a virtual pedal would do away with having to fit a real one, although the advantage of a real throttle is that it is instantly available when needed.

 

[thineight]

Let me share my poor man's cable solution for whose in doubt on which cable tu buy and cut: just with the dupont cables supplied with the ST-LINK V2 clone it is sufficient to remove the plastic end at one side and to protect the metal end with a little piece of shrinking cable. The female ends can be plugged into the motor pins once the speed sensor is removed.
Worked at first attempt (cable length about 15-20 cm).

Casainho, if you wish you can embed the pictures in the how-to-conect wiki page https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Flash-the-firmware-on-TSDZ2 for easier reference.

Cheers

 

[elem]

Riding south french mountain, first ride with open source running .

[youtube]-BAI97_nvGk[/youtube]

 

[casainho]

Riding south french mountain, first ride with open source running .

[youtube]-BAI97_nvGk[/youtube]

I remember to see your videos with TSDZ2 on mountains when I found the first information about this motor. It is really nice to see that 1 year after, your preference goes to the firmware I started to it!! Who knows what will happen when we share something with others??

Would be nice if you could refer on the video description (this first one) that you are running TSDZ2 mid drive motor running tye flexible OpenSource firmware and link to project page.

 

[perryscope]

I have released the new version of the Controller firmware compatible with both the VLCD6 and KT-LCD3 diplay. I have also released the Java configuration interface (TSDZ2 Configurator ver. 0.1.0).
Have a good day.

https://github.com/qmarco/TSDZ2-Smart-EBike-compatible-with-original-VlCD6-display/blob/master/README.md

Excuse me .... this is the right link: https://github.com/qmarco/TSDZ2-Smart-EBike-compatible-with-original-VlCD6-display

TSDZ2 Newbie here, so please be kind!.

I have just flashed my TSDZ2 for the first time today with the Marcoq build (TSDZ2_Controller_vM0.16.B_VLCD6_and_TSDZ2_Configurator_v0.1.2) so I can test with the VLCD6 display for now. I do have a 850C display modified with an external connector but still trying to work out the toolchain for that path.

All has gone great flashing the firmware so I did a comparison against the stock Firmware on a small hilly loop around my house. Running on 36V 10S5P battery the stock firmware would pull about 15A max in highest assist level with hard pedaling however the opensource firmware tops out at 7A and is noticeably down on power. I am using a separate power analyzer on the bike to take live readings and peak readings.

To be fair it does not feel half the power I would say more like 70%.

I have been using the Java tool to edit a the motor wattage and set it to 500W (from 250W) but all other settings are using the default_configuration.ini settings. Battery voltage/and AMP settings seem fine and should deliver up to 17A without issue.

I'm sure I am missing something obvious, but I cannot think why the motor would use so much less power in full assist?
for flat general riding, it feels enough but I would like to have the option of the power that I was getting from the stock firmware, ideally a little more. I even switched back to the stock firmware to be sure, and sure enough, it was back to the full 15A I would expect.

I am familiar with a Bafang BBS02 500W on the same battery and that has noticeably more pull (all be it at 20A so nothing like the range!)

I am hoping to get close to that with the TSDZ2 after switching to 48V battery to keep the amps lower.

In my spare time I work for a disabled cycling charity and the long-term plan for the TSDZ2 is to help power large trikes, and recumbent hand trikes as well as towing recumbent hand trikes for disabled riders which the Bafang does brilliantly on a current combination we have , but I love the flexibility and size of the TSDZ2 and would like to use them where possible.

Hope you guys can give me some pointers.