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

buba said:

I was not looking at that particular bug for the latest pull request but since it is Christmas we might have a fix in version 0.17 beta-3... :wink:

Will make another pull request if it seems to work after my tests.

On a side note, I took the liberty to help out with the wiki for 0.17.X. Updated some text and also the menu layout.

Click to expand...

You pull request seems good. I hadn't chance to test the code but it makes sense!!

And the wiki changes are good!! Nice to see "my english" improved

Here is the new v0.17.0-beta3: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.17.0-beta3

marcoq "program memory" tested with LCD5
it work, but :
changing assist level have no effect ( seems to work max assist always )
changing curent amp have no effect ( tried even at 9 amp, it s egual )

whith original firmware i used 14 Amp on my 27.5 SR boost and 13 Amp on my 26 TS .

With this firmware it seems smoth ( not soo brutal than original firmware )
nothing more noticed ...

Soo data memory seems to be programed as i only flash program memory and as this software was programmed for VLCD6, i thinck it's why i noticed the problems
but as i m novice in programing and i don t know how doing change using the memory data he gave .

And, yes, walk assist mode work, seems as previous, assist level as no effect on walk assist mode .

to be continued ( with hope ) ....

ok, made some more tests ;
in fact changing assist level work but very differently than original firmware,
edit after a real ride test : in fact changing assist level don t work with lcd5 as long as you don t change the data memory yourself for adapting to VLCD5 display,
begin more stronger with a curent amp ramp that wasn t existing in original firmware .

I can t change assist level %, soo for me level 1 is too stronger
( i m not programmer, i tried to modify data and flashed it but program modify data memory and doesn't accept change .

It s different, i must test casainho firmware with lcd3 to check and be able modify something

as it s the first time i test this firmware and only small test i can t see if it s very different, i will try using it in VTT because this the only thing wich is interessing me .

cu all

marcoq, casainho,

I'm interested in using the VLCD6 because I like the small compact form factor (and my motor came with one). I like the flexibility of setting things via display, but I'm willing to set them via programming the controller instead in exchange for the form factor I prefer.

So, given that, I was reading through the earlier conversation between you two and thinking about how to integrate marcoq's work into the main project in a way that makes everyone happy.

Reading through marcoq's code now, it's all done with #ifdefs which I think doesn't satisfy casainho's desire that a single firmware binary will work with either display (if I understood his desire correctly).

casainho, I assume that both the LCD3 and 850C are using the same package encodings so nothing on the controller side needs to change to support the 850C? So we have one pair of encodings (to controller and to display) for the 'open' displays (KT-LCD3, 850C, etc), and another for the 'oem' displays (VLCD6, etc)?

What if we have the controller side detect whether it's an 'open' display or an 'oem' display rather than using #ifdefs? Maybe that's as simple as checking the uart buffer length since I see casainho is already using an 8 byte buffer and OEM is using 6. Presumably casainho's isn't going to get smaller, and OEM isn't going to get bigger (since they want to maintain compatibility with the motors and displays already in the field). If that's too hacky, maybe we could add a magic number to the 'open' display package sent from the display. Maybe even a version number for more future flexibility.

So anyway, then, once we can dynamically detect if the package came from an oem or open display: we have one uart tx encoder function for the oem displays, and another for the open displays, and same for rx decoders. On rx, we populate whatever values we got from the display, and any that didn't get populated (because open displays support them but not oem), we fall back to using values from what's on the eeprom. On tx, we use the encoding corresponding to the last package we received (i.e., if we got an 'open' package from the display, encode an 'open' package to send back, etc).

As far as how we get those values to eeprom, either way already discussed seems fine -- the user writes them to either the hex file or directly to the controller.

Does that sound good to you both? If so, I think a good path would be:

1. Change to make the controller firmware to detect 'open' displays (and maybe change the 'open' displays to identify themselves).
2. [If necessary; I haven't checked closely] Refactoring to make the controller read display-derived values from a data structure that can be populated from either an open display, or from oem + eeprom values.
3. Define encoding / location in eeprom for writing config values needed for oem displays.
4. Add oem encoding / decoding functions (marcoq has already done the heavy lifting).

Skimming through marcoq's code, I think for this first set of changes it'd be better to leave walk assist out, since that's a good chunk of the code and complexity and it'll be simpler to separate the two things.

casainho said:

buba said:

I was not looking at that particular bug for the latest pull request but since it is Christmas we might have a fix in version 0.17 beta-3... :wink:

Will make another pull request if it seems to work after my tests.

On a side note, I took the liberty to help out with the wiki for 0.17.X. Updated some text and also the menu layout.

Click to expand...

You pull request seems good. I hadn't chance to test the code but it makes sense!!

And the wiki changes are good!! Nice to see "my english" improved

Here is the new v0.17.0-beta3: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.17.0-beta3

Click to expand...

OK that has fixed the motor watt meter. :thumb:

But there is an oddity with battery state of charge. I had noticed it before but did not look at in any detail until the wattmeter and fast variable adjust was sorted. Before I try to explain just to say SoC works perfectly in Buba's 16.1 but not in 17.0 betas 1,2 and 3 .

These results are with a fully charged battery about 58.0v and I have the fully charged reset value set to 57.6v (config menu 2 submenu 2)

There is something wrong with the logic in Config menu 2 submenus 0 and 1 (Battery power set up).

Submenu 0 is supposed to enable (1)/ disable(0) the state of battery charge display in the temperature field but it no longer does that, instead Submenu 1 enables SoC in the temp field when it is set to 1 and disables it when set to 0. The SoC charge in the temperature field also wrongly reads 10 and it was this value of 10 which first caught my attention.

Submenu 0 now disables(0) enables(1) displays 2.0 and 2.1 in the odometer field but this is further complicated that when submenu 1 is set to 0 displays 2.0 and 2.1 both read 0 and when submenu 1 is set to 1 display 2.0=100 and 2.1=0 but to be expected as submenu 1 sole role is supposed to be a decrement or increment selection.

Just to repeat these functions work perfectly in Buba's 16.1 and the values I have given are for a fully charged battery


I hope all that makes some sense.
Cheers

Ron Paul's Blimp said:

marcoq, casainho,

I'm interested in using the VLCD6 because I like the small compact form factor (and my motor came with one). I like the flexibility of setting things via display, but I'm willing to set them via programming the controller instead in exchange for the form factor I prefer.

So, given that, I was reading through the earlier conversation between you two and thinking about how to integrate marcoq's work into the main project in a way that makes everyone happy.

Reading through marcoq's code now, it's all done with #ifdefs which I think doesn't satisfy casainho's desire that a single firmware binary will work with either display (if I understood his desire correctly).

casainho, I assume that both the LCD3 and 850C are using the same package encodings so nothing on the controller side needs to change to support the 850C? So we have one pair of encodings (to controller and to display) for the 'open' displays (KT-LCD3, 850C, etc), and another for the 'oem' displays (VLCD6, etc)?

Click to expand...

I think a much simpler approach would be to just have the display type as a parameter in the EEPROM. This could simplify things if even more displays are supported.

After using LCD3 for a month or so, I just got an 850C working. Unfortunately Im not happy with the result. To be able to use will require I bring reading glasses on my ride and many of the configuration things (like offroad power limit >275) just dont work.

Im going to move forward with the VLCD6 and my own software based off marcoqs code. I like the minimal interface and its what I originally wanted to use. I appreciate all the work to set configuration stuff but I just dont need it

linklemming said:

I think a much simpler approach would be to just have the display type as a parameter in the EEPROM. This could simplify things if even more displays are supported.

After using LCD3 for a month or so, I just got an 850C working. Unfortunately Im not happy with the result. To be able to use will require I bring reading glasses on my ride and many of the configuration things (like offroad power limit >275) just dont work.

Im going to move forward with the VLCD6 and my own software based off marcoqs code. I like the minimal interface and its what I originally wanted to use. I appreciate all the work to set configuration stuff but I just dont need it

Click to expand...

Yeah that works too. Will you submit PRs to casainho's tree as you go? There's no point in us both doing it.

I'm hoping posters and readers take a moment to send some dollars to casainho! Let's do what we can to keep the research and coding going. This is really quite amazing! I'm in for a few bucks, you?


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

First off, dont necessarily take my comments as anything bad, Im just offering my experiences.

Took the TSDZ2 with 0.16 software and 850C display out for a ride today.

Forget my previous comment on the display fonts being too small like in the configuration setup. I can see it just fine as long as I up the brightness(long press of + key). The new configuration menu system is SO much nicer.

About 10 miles into the ride, I noticed the speed display and motor power were not changing on the display. I also noticed that although the assist levels changed on the display, I couldnt notice any effect while riding. About 15 miles in I decided to try to fix that and couldnt power off the display with the power button. I was at the lowest assist level on the display although I know the actual assist level was much higher. I turned off the power from the battery.

Upon powering back up, I noticed that I seem to only have the lowest assist level (confirmed by motor output being really low). I rode for about 5 miles like this and it was driving me crazy. More of a workout than I wanted and rain/snow was closing in.

I decided to reset to factory defaults and all seemed good again and all assist levels seemed to work. Rode about 5 miles this way before the speed and motor power stopped updating. Once again, the assist level didnt seem to have an effect.

So one more factory reset to make the final leg home.

So Im going to ditch the 850C later today and go back to the LCD3 for now (with the nicer 850C buttons) and am going to order a VLCD6 and get that working to my liking.

linklemming said:

So Im going to ditch the 850C later today and go back to the LCD3 for now (with the nicer 850C buttons) and am going to order a VLCD6 and get that working to my liking.

Click to expand...

Are you going to submit PRs to casainho's tree? What kind of timeline are you looking at? Unless you're going to get started pretty soon (or unless marcoq would like to do it), I'll probably try to integrate his VLCD6 stuff using the strategy I described a few posts ago (separating it from his walk assist stuff and determining the display type at runtime instead of compile time).

Ron Paul's Blimp said:

linklemming said:

So Im going to ditch the 850C later today and go back to the LCD3 for now (with the nicer 850C buttons) and am going to order a VLCD6 and get that working to my liking.

Click to expand...

Are you going to submit PRs to casainho's tree? What kind of timeline are you looking at? Unless you're going to get started pretty soon (or unless marcoq would like to do it), I'll probably try to integrate his VLCD6 stuff using the strategy I described a few posts ago (separating it from his walk assist stuff and determining the display type at runtime instead of compile time).

Click to expand...

Dont let me hold you back from anything, do what you need to do.

Im just going to do my own thing from here on out. I have my own opinions on what needs to be done and just want to implement them as I see fit(for me). If it works out, I might start my own fork...happens all the time with opensource.

I have alot of my own ideas and just want to try them as I see fit and as my time allows.

Kudos to casainho and marcoq for their work, I just have my own desires and priorities which might not align.

linklemming said:

First off, dont necessarily take my comments as anything bad, Im just offering my experiences.

Took the TSDZ2 with 0.16 software and 850C display out for a ride today.

Forget my previous comment on the display fonts being too small like in the configuration setup. I can see it just fine as long as I up the brightness(long press of + key). The new configuration menu system is SO much nicer.

About 10 miles into the ride, I noticed the speed display and motor power were not changing on the display. I also noticed that although the assist levels changed on the display, I couldnt notice any effect while riding. About 15 miles in I decided to try to fix that and couldnt power off the display with the power button. I was at the lowest assist level on the display although I know the actual assist level was much higher. I turned off the power from the battery.

Upon powering back up, I noticed that I seem to only have the lowest assist level (confirmed by motor output being really low). I rode for about 5 miles like this and it was driving me crazy. More of a workout than I wanted and rain/snow was closing in.

I decided to reset to factory defaults and all seemed good again and all assist levels seemed to work. Rode about 5 miles this way before the speed and motor power stopped updating. Once again, the assist level didnt seem to have an effect.

So one more factory reset to make the final leg home.

So Im going to ditch the 850C later today and go back to the LCD3 for now (with the nicer 850C buttons) and am going to order a VLCD6 and get that working to my liking.

Click to expand...

Thanks for the feedback. I am using 850C on my ebike so I have to deal with that issues also. The firmware is just at his begin, it needs a lot of more work.

When I can't power of, I just enter configurations menu and then power off works again. Although some data fields are not updated after some time, the motor keeps working well for me.

Again, it needs a lot of more working and I am not having free time lately to work on it, but I will do it for sure.

hello,
en utilisant l archive de marcoq comme base, j ai reussi a modifier le " data memory " pour l ajuster a mes besoins .
Il est nécessaire de modifier la table " data memory " " on the fly " avec le stlink connecté, car ainsi l " option byte " ce met a jour, sinon vous avez une erreur .
voici le set up que j ai utilisé pour une batterie de 36V ( 10S )

Using the marcoq archive as a base, I managed to modify the 'data memory' to fit my needs.
It is necessary to modify the table 'data memory' 'on the fly' with the connected stlink, because thus the "option byte 'this updates, otherwise you have an error.
here is the set up that I used for a battery of 36V (10S)

0x004000 : AA 08 00 11 19 22 01 23 08 2D 01 00 19 0A 0A C4 ( modified by program memory after first warm up )
0x004000 : AA 05 00 0E 23 ( data memory modified for my set up )
0x004010 : 00 3B 01 08 10 1E 32 00 00 04 0C 14 1C 14 23 01
0x004010 : 00 3B 01 05 0F 1E 32
0x004020 : 19 00 4B 55 0A 0C 12 1A 20 28 14 00 00 00 00 00
0x004020 : 18

0x004001 : 05 (level factor x10 )
0x004003 : 14 amp = 0E ( batt max courant )
0x004004 : 350W = 35 = 23 ( moteur max power x10 )
0x004013 : 5 = 05 ( lvl 1 )
0x004014 : 15 = 0F ( lvl 2 )
0x004015 : 30 = 1E ( lvl 3 )
0x004016 : 50 = 32 ( lvl 4 )
0x004020 : 450w/25 = 18 ( max batt power div 25 )

will post archive if needed, must do more improvment because, it s always too strong for my need .

have fun .
PS : flashing using all port needed ( rst, gnd, swin, +V ) battery unplugged .

using this set up and a wattmeter
moderate pedaling; lvl 1= 48w, lvl 2= 130w, lvl 3=280w
strongly pedaling : lvl 1 reach about 200w, lvl 2 about 330w ...max power about 440w with first test .

i will improve my set up as i don t need many power and next step will be build my own 11s battery for improve rpm .

casainho, can you share what you use for debugging / testing? I didn't see anything on the wiki. I'm new to embedded stuff. What's the best way to get some printf debugging going (or a real debugger)? Is there an STM tool I can use to get stdout over the stlink somehow while still having the wheel speed sensor wired up? I'd rather use Linux or MacOS but I can make Windows work if I have to. Thanks!

Ron Paul's Blimp said:

casainho, can you share what you use for debugging / testing? I didn't see anything on the wiki. I'm new to embedded stuff. What's the best way to get some printf debugging going (or a real debugger)? Is there an STM tool I can use to get stdout over the stlink somehow while still having the wheel speed sensor wired up? I'd rather use Linux or MacOS but I can make Windows work if I have to. Thanks!

Click to expand...

I use Linux and here are my notes:
https://opensourceebikefirmware.bitbucket.io/development/Development_tools--Linux--Step-by-step_tutorial_development_tools.html

A small video, may be usefull for french users .

[youtube]6Y6byG9E7Ss[/youtube]

casainho said:

I use Linux and here are my notes:
https://opensourceebikefirmware.bitbucket.io/development/Development_tools--Linux--Step-by-step_tutorial_development_tools.html

Click to expand...

Awesome. What's your physical connection like for the TSDZ2? Can you get serial port output while having both the wheel sensor and display connected?

This is what I get for cutting my French classes. I so envy my multilingual EU friends!

Ron Paul's Blimp said:

casainho said:

I use Linux and here are my notes:
https://opensourceebikefirmware.bitbucket.io/development/Development_tools--Linux--Step-by-step_tutorial_development_tools.html

Click to expand...

Awesome. What's your physical connection like for the TSDZ2? Can you get serial port output while having both the wheel sensor and display connected?

Click to expand...

The serial port I use is the one that communicates with LCD.

Rafe said:

OK that has fixed the motor watt meter. :thumb:

But there is an oddity with battery state of charge. I had noticed it before but did not look at in any detail until the wattmeter and fast variable adjust was sorted. Before I try to explain just to say SoC works perfectly in Buba's 16.1 but not in 17.0 betas 1,2 and 3 .

These results are with a fully charged battery about 58.0v and I have the fully charged reset value set to 57.6v (config menu 2 submenu 2)

There is something wrong with the logic in Config menu 2 submenus 0 and 1 (Battery power set up).

Submenu 0 is supposed to enable (1)/ disable(0) the state of battery charge display in the temperature field but it no longer does that, instead Submenu 1 enables SoC in the temp field when it is set to 1 and disables it when set to 0. The SoC charge in the temperature field also wrongly reads 10 and it was this value of 10 which first caught my attention.

Submenu 0 now disables(0) enables(1) displays 2.0 and 2.1 in the odometer field but this is further complicated that when submenu 1 is set to 0 displays 2.0 and 2.1 both read 0 and when submenu 1 is set to 1 display 2.0=100 and 2.1=0 but to be expected as submenu 1 sole role is supposed to be a decrement or increment selection.

Just to repeat these functions work perfectly in Buba's 16.1 and the values I have given are for a fully charged battery


I hope all that makes some sense.
Cheers

Click to expand...

The bug is now fixed and some more improvements have been made. Thank you for reporting it! Pull request is active and hopefully a new official version will be released so you can test the updates.

Please take a look at the updated wiki. It shows how to setup the Battery SOC function with the new menu logic.

Anyone that would like to test the new firmware should take a quick look at the wiki as there are updates.

https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Usage-and-configuration-of-firmware-version-0.17.x

buba said:

The bug is now fixed and some more improvements have been made. Thank you for reporting it! Pull request is active and hopefully a new official version will be released so you can test the updates.

Please take a look at the updated wiki. It shows how to setup the Battery SOC function with the new menu logic.

Anyone that would like to test the new firmware should take a quick look at the wiki as there are updates.

https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Usage-and-configuration-of-firmware-version-0.17.x

Click to expand...

Here is the latest beta version. Let's see if new issues are found due to changes on this version and if not, soon it will be released as a stable version:

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

casainho said:

buba said:

The bug is now fixed and some more improvements have been made. Thank you for reporting it! Pull request is active and hopefully a new official version will be released so you can test the updates.

Please take a look at the updated wiki. It shows how to setup the Battery SOC function with the new menu logic.

Anyone that would like to test the new firmware should take a quick look at the wiki as there are updates.

https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Usage-and-configuration-of-firmware-version-0.17.x

Click to expand...

Here is the latest beta version. Let's see if new issues are found due to changes on this version and if not, soon it will be released as a stable version:

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

Click to expand...

All looking good so far, will road test tomorrow. Great work on the documentation too.

Thank you Buba and Casainho.

Last tests with marcoq firmware and VLCD5 ...
all work fine, easy to modify when you know what to do
altought modifying current ampere ( max current for controleur ) don t work on display and must be modify directly using STlink in data memory as assist level and other parameters .

This configuration is perfect for a basic use, some features aren t suffisant for my use soo next step will use casainho firmware with LCD3, but this set up is perfect for lambda users who are not agressive in their use ( moutain climbing ) and don t need all features avaiable on display like LCD3 .

here a small video of my last test ( i wanted to now if "current limiting for controleur ) avaiable in advanced set up of VLCD5 was working also on this firmware : definitely no !, only what was stored in eeprom is used .

[youtube]jrNj1JNd9JM[/youtube]

here is the final set up choosed

DM resultat apres programmation
0x004000 : AA 03 00 10 1E 22 01 23 08 2D 01 00 19 0A 0A C4
0x004010 : 00 3B 01 03 08 10 1E 00 00 04 0C 14 1C 14 23 01
0x004020 : 20 00 4B 55 0A 0C 12 1A 20 28 14 00 00 00 00 00


0x004001 : 03 (default value assist level factor x10 )
0x004003 : 16 amp = 10 ( default value battery max current )
0x004004 : 300W = 30 = 1E ( default value motor max power x10 )
0x004013 : 03 = 03 ( lvl 1 )
0x004014 : 08 = 08 ( lvl 2 )
0x004015 : 16 = 10 ( lvl 3 )
0x004016 : 30 = 1E ( lvl 4 )
0x004020 : 500w/25 = 20 ( max batt power div 25 )

Hi all. I just flashed KT-LCD3, next I flash the motor.

Thanks jbalat & andyme for instructions and of course casainho for the development.

A couple questions:

1. Before I flash the motor, where are the torque sensor calibration constants stored? In the motor or the VLCD5? How do I prevent losing coefficients and input them into the open source system?

2. The ST V link I have puts out 3.3V, not 5V. It seemed to flash but the LCD was super dim. Is it OK to use 5V from another source?

Thanks

Hi guys.
I have just finished programming the user interface in Java, which will allow you to modify all the "fixed" parameters of the controller Fimware made by casainho. It will be possible to modify the parameters related to the use of the VLCD6 display, moreover it will be possible to select the use of the KT-LCD3 display. In the future it may be possible to use a smartphone that communicates with the firmware via a Bluetooth connection. I need a few days to debug the user interface before publishing it, in the meantime I want to thank stancecoke for using its software as a starting point for this project. We will update soon.