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

perryscope said:
I tested at 20-90 deg C using my 3D printer heater bed which can be set to a stable temperature, left at each temperature for 5 min to stabilise and cross-referenced with an IR thermometer. But at the higher temperatures, I am almost 20°C out assuming a 10mV per °C reading???
I think the issue might be the test. The sensor is exposed top ambient air as well as the table. Infrared thermometers are not very accurate and depend on a reliable emissivity of the surface.

A more reliable test can be done in your oven against a thermometer (a remote digital meat thermometer is best https://www.amazon.com/ThermoPro-TP-16-Thermometer-Stainless-Standard/dp/B017613C3C/ref=sr_1_1?s=home-garden&ie=UTF8&qid=1548193489&sr=1-1&keywords=digital+meat+thermometer+for+oven, a dial oven thermometer is not accurate). Set both on an aluminum pan that will serve as a sink shielding air currents and smoothing the on/off cycling of the oven thermostat. That lets the whole setup come to the same temperature.
 
perryscope said:
Are many people running the LM35 Temperature sensors in their motors?
Thanks for writing the article about TSDZ2 and the OpenSource firnware!!

https://empoweredpeople.co.uk/2019/01/20/experimenting-with-the-tsdz2-mid-drive-system/

That IR sensors are not very accurate. Try that multimeters with a thermocouple, they are accurate, even the cheap ones!!
 
buba said:
Do appreciate the time you took to write and give your thoughts! A very interesting comparison as well!

As you noted SDCC is very good at creating fast code and is one of the best compilers in that comparison. There are alternatives that could maybe change the size somewhat but I do not like to compromise in any way and would like to keep optimizing the code as much as possible. Removing a function is actually the last thing I would like to do and that will most likely never happen. The goal is to optimize and remove as much code as possible but still maintain the same functionality and readability.

http://www.colecovision.eu/stm8/compilers.shtml comparison is interesting, but I don't understand the size chart
sizes-2018.png
How does size vary depending on the benchmark being run?
 
casainho said:
perryscope said:
Are many people running the LM35 Temperature sensors in their motors?
Thanks for writing the article about TSDZ2 and the OpenSource firnware!!

https://empoweredpeople.co.uk/2019/01/20/experimenting-with-the-tsdz2-mid-drive-system/

That IR sensors are not very accurate. Try that multimeters with a thermocouple, they are accurate, even the cheap ones!!


Oh, no problem. It's a great project you have created Casainho.! So much of the e-bike solutions are closed and inflexible, our projects at Empowered People are a bit different from the norm and being able to fine-tune and adapt to such a degree is a must for me. I have some interesting projects planned to run a remote control for a bike and trike toe setup for disabled rider who has trouble with any form of control so the lead rider would need to set power assist levels and monitor battery etc. but for now I am just testing and learning on a spare bike of my own to get expensive of it.

I will try out the multimeter with a thermistor as well as you say maybe it's just not a good test.

Edit - Just done a quick test with the 100k thermister probe next to the LM35 (between the heater and the glass on the printer so creating a small oven and they are within 1°C of each other at 60°C reading so like you say it must have been an unfair temperature I was comparing with. Apologies, false alarm it looks like I do have a legit LM35 after all and it's reading well. :D
 
My bike is away getting a needed sand blasting and paint. So whenever I test the firmware I use my fathers bike. He installed the firmware and connected everything on his own bike. But not all was made completely weatherproof. Well it was, but it really needs extra protection due to the weather we are riding in and also the situations we put it through. Today I received a call from him. The call was accompanied with a picture of a slightly burnt cable.

Whenever you have heavy snowstorms, salt, sub zero temperatures, offroad routes, heavy water levels when the temperature warms up for just half a day and then some more on top of that, you are asking for trouble. This bike endured so much this winter it was bound to happen sooner or later. We like to test the hardware like this. :twisted:

Long story short: there was a small short circuit on his setup.

This changes my plans for the pull request slightly. As I have no bike and especially no hardware to test the firmware on for now. I still think it is a good idea to submit the pull request but as I have no way of confirming my fixes I would ask for some extra understanding.

Will update as soon there are updates and please do not forget that I read all posts. I do not miss any feedback or great suggestions. Sometimes it will just take me longer to answer.
 
buba said:
My bike is away getting a needed sand blasting and paint. So whenever I test the firmware I use my fathers bike. He installed the firmware and connected everything on his own bike. But not all was made completely weatherproof. Well it was, but it really needs extra protection due to the weather we are riding in and also the situations we put it through. Today I received a call from him. The call was accompanied with a picture of a slightly burnt cable.

Whenever you have heavy snowstorms, salt, sub zero temperatures, offroad routes, heavy water levels when the temperature warms up for just half a day and then some more on top of that, you are asking for trouble. This bike endured so much this winter it was bound to happen sooner or later. We like to test the hardware like this. :twisted:

Long story short: there was a small short circuit on his setup.

Here is the picture by the way:
https://drive.google.com/drive/folders/1HJMJc7cc9YsG1G83TUbpZwQxJcO2m023

Will maybe have time to fix the cable and make it all waterproof back at my fathers place today. Then I will be able to test the firmware before I submit the pull request. If the fixes are confirmed to be okay we can move on with other functions, features and/or issues some of you mentioned! :)
 
buba said:
buba said:
My bike is away getting a needed sand blasting and paint. So whenever I test the firmware I use my fathers bike. He installed the firmware and connected everything on his own bike. But not all was made completely weatherproof. Well it was, but it really needs extra protection due to the weather we are riding in and also the situations we put it through. Today I received a call from him. The call was accompanied with a picture of a slightly burnt cable.

Whenever you have heavy snowstorms, salt, sub zero temperatures, offroad routes, heavy water levels when the temperature warms up for just half a day and then some more on top of that, you are asking for trouble. This bike endured so much this winter it was bound to happen sooner or later. We like to test the hardware like this. :twisted:

Long story short: there was a small short circuit on his setup.

Here is the picture by the way:
https://drive.google.com/drive/folders/1HJMJc7cc9YsG1G83TUbpZwQxJcO2m023

Will maybe have time to fix the cable and make it all waterproof back at my fathers place today. Then I will be able to test the firmware before I submit the pull request. If the fixes are confirmed to be okay we can move on with other functions, features and/or issues some of you mentioned! :)
Good luck.
Right at the "waterproof" connector.
 
buba said:
buba said:
My bike is away getting a needed sand blasting and paint. So whenever I test the firmware I use my fathers bike. He installed the firmware and connected everything on his own bike. But not all was made completely weatherproof. Well it was, but it really needs extra protection due to the weather we are riding in and also the situations we put it through. Today I received a call from him. The call was accompanied with a picture of a slightly burnt cable.

Whenever you have heavy snowstorms, salt, sub zero temperatures, offroad routes, heavy water levels when the temperature warms up for just half a day and then some more on top of that, you are asking for trouble. This bike endured so much this winter it was bound to happen sooner or later. We like to test the hardware like this. :twisted:

Long story short: there was a small short circuit on his setup.

Here is the picture by the way:
https://drive.google.com/drive/folders/1HJMJc7cc9YsG1G83TUbpZwQxJcO2m023

Will maybe have time to fix the cable and make it all waterproof back at my fathers place today. Then I will be able to test the firmware before I submit the pull request. If the fixes are confirmed to be okay we can move on with other functions, features and/or issues some of you mentioned! :)

Saltwater is definitely not the Ebikers friend! I think that looks fixable assuming the electrical contacts are still good inside. I hope you get it sorted quickly.

Just on a similar point, to tidy up the cable splice between the KT-LCD3 screen cable and the larger 8 pin cable I 3D printed a simple shroud, which can be glued in place to keep the weather out..
cable cover.jpg

Happy to share the design if anyone wants one, it's easy to make if you have access to a 3D Printer. You could add a similar shroud to add a better seal to the main 8-pin connector to help keep the water out. I think from memory on the Bafang multiway connector there is an overlap and an internal seal to help weatherproof it.
 
perryscope said:
Saltwater is definitely not the Ebikers friend! I think that looks fixable assuming the electrical contacts are still good inside. I hope you get it sorted quickly.

Just on a similar point, to tidy up the cable splice between the KT-LCD3 screen cable and the larger 8 pin cable I 3D printed a simple shroud, which can be glued in place to keep the weather out..
cable cover.jpg

Happy to share the design if anyone wants one, it's easy to make if you have access to a 3D Printer. You could add a similar shroud to add a better seal to the main 8-pin connector to help keep the water out. I think from memory on the Bafang multiway connector there is an overlap and an internal seal to help weatherproof it.
Waterproof cables splices can also be made using glue-lined heat shrink tubing, for example,
https://www.mcmaster.com/74965k53
It is lined with a hot-melt coating and completely seals an inline cable splice.
The TSDZ2 motor cable splice in the 3rd photo in this post was made with moisture-seal heat shrink.
https://endless-sphere.com/forums/viewtopic.php?f=28&t=79788&p=1439930#p1439930
You can just barely see the clear adhesive squeezing out a bit at the end of the splice.
 
to do water proof connection i use self-caking adhesive tape (i hope it's correct in english)
as far as the functions of the LCD and the space in memory are concerned, I think that the measurement of the watts, the percentage of the battery and the eventual function of the remaining km is 3 functions for the same thing ...
I also think that calculating the remaining km is not easy, the calculation should change depending on the level of assistance or the watts, otherwise it is useless, if not accurate is just a gadget similar to the bosch. I prefer a precise wattmeter, but it is a personal preference
 
andrea_104kg said:
to do water proof connection i use self-caking adhesive tape (i hope it's correct in english)
as far as the functions of the LCD and the space in memory are concerned, I think that the measurement of the watts, the percentage of the battery and the eventual function of the remaining km is 3 functions for the same thing ...
I also think that calculating the remaining km is not easy, the calculation should change depending on the level of assistance or the watts, otherwise it is useless, if not accurate is just a gadget similar to the bosch. I prefer a precise wattmeter, but it is a personal preference

I use the same. The name I know it by is self-amalgamating tape.
 
andrea_104kg said:
to do water proof connection i use self-caking adhesive tape (i hope it's correct in english)
as far as the functions of the LCD and the space in memory are concerned, I think that the measurement of the watts, the percentage of the battery and the eventual function of the remaining km is 3 functions for the same thing ...
I also think that calculating the remaining km is not easy, the calculation should change depending on the level of assistance or the watts, otherwise it is useless, if not accurate is just a gadget similar to the bosch. I prefer a precise wattmeter, but it is a personal preference

Ciao Andrea, indeed all the 3 functions end up to the same concept: the more you demand to the motor, the quicker the battery drains.
The last trip I did, which was the first with the LCD3, I was monitoring the state of charge to estimate the possible battery duration but in the end of the day the indicator "100..0" did not give me a clear idea in terms of "practical information". I found quite useful, one time I used a bosch bike, to get the estimation of remaining km, which is updated every X second according to the ride conditions (assistance used, slope). For instance if you know you are about to climb 10 km of hill and you use assistance 3 and the indicator shows you "7 km remaining", you realize that the best option is to adopt assistance 2 otherwise you risk to run out of battery before you reach the top.
Of course the distance left indication is less interesting if your track is costantly up-down-up-down, but in other cases it has an added value in my opinion because gives you the confidence that you can complete your trip.

See how much space left we got after the code optimizations.. maybe there is no chance to get anything else implemented.
 
The TSDZ2 with the burnt connector is up and running. It got a well deserved service as well :thumb:

Therefore, I had the chance to quickly test the changes I have been working on. All seems fine. To be honest I am very excited to get it out for you all to test for yourselves! :) There will always be room for some improvements or bug fixes. Especially now that the entire firmware is getting optimized at the same time new functions are implemented.

Note that I am prioritizing making the current functions and features work and will later try to add the GREAT suggestions from all of you. When we come to a point where everything works we can make this version official and then work on a new version with new additions.

Changelog:
------------------------------------------------------------------------------------------------
- Fixed bug that did not set the screen brightness until user toggles lights
- Improved screen brightness setup, now the user immediately sees the screen brightness during setup
- Fixed bug that did not show imperial units in the new Wheel Speed sub menu in the odometer field
- Implemented a safer cruise/walk assist
- Developed a better Main Screen Setup with more custom settings
- It is now possible to set what to display in the temperature field, such as pedal cadence
- Removed the quick-change-temperature-field
- Optimized UART communication
- Made overall improvements: faster and takes up less space
- Changed the motor acceleration to amps per second, more intuitive
- Implemented an enable/disable throttle toggle. This maybe makes two hex versions for the motor controller (throttle and no-throttle) unnecessary as user can toggle the function on or off via firmware. But this is maybe unsafe to do and it may still be better with two separate versions.
- Some other smaller fixes
------------------------------------------------------------------------------------------------

The pull request is submitted and as always, I look forward to feedback from Casainho and of course from all users!

In this new update the firmware has been optimized and it is very important to RESET to default values OR go through the entire Configuration Menu and CONFIRM that everything is set to correct values so that it works as expected! Sorry if this causes any inconvenience!

Updated wiki:
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.18.X-(beta)
 
Kisazul said:
One of the main problems in the TSDZ2 motor is cadence, which is greatly reduced with a drop in battery voltage. One solution is to use 11S or 12S batteries for 36V and 14S for 48 volts. I want to share my opinion and find out the possibility of implementing constant cadence, which the user will choose in the menu...

This is something that will hopefully be solved with field weakening in the future! It is on the to-do list!


casainho said:
1. Change enter configuration menu to quick UP and DOWN + long UP and DOWN buttons. This would make less probably to enter this menu by mistake...

2. Remove specific menu for setup max power and instead implement the following code that I am using on Bafang 850C LCD...

Will definitely look into that! Nice work on the 850C by the way!


Rafe said:
I always run with startup power boost enabled set to kick in when cadence/torque is zero and pedalling restarts. Mostly this works fine but every now and then when I start pedaling again there isn't any pedal assist at all for about three seconds and the assist when it does restart it is normal assist and not power boost.

I've spent countless hours over long journeys trying to find a logic or sequence to this and so far it has escaped me. It usually comes to my attention on climbs as the incline levels off briefly and I stop pedaling for a few seconds and when I start pedaling again there is no assist and I'm under my own steam until it suddenly kicks in again. Sometimes the power boost is working perfectly for ages then suddenly it is not for a few restarts and then it is all working perfectly again.

It is left over from what we called 'the lag' which was worked on and if I recall correctly lasted longer and restarted in power boost mode and not normal assist as it does now. Perhaps your fresh eyes can find a solution?

The fact that you try to give as much information as possible regarding the bug and the events that trigger it makes it much easier to identify the code responsible for that behavior. That greatly increases the probability to solve the problem. Thanks!

Have some ideas but can not be completely sure because I have not looked at the code implementation of Boost at all. I will look into it but can not promise anything soon!

Cheers!


thineight said:
Just a suggestion, in case the memory is not enough. Perhaps the cruise control, being just a contingency measure, can be implemented differently in order to gain some space in memory.

That is a good suggestion and will work for many functions. But Cruise is mainly implemented in the Controller firmware and removing the function will sadly make no usable difference in the program memory space of the KT-LCD3. The display only activates the function in the controller.

Will try to optimize in other ways! I like the range estimate function you suggested and will try to look into it more and how to fit it into the firmware!


tomtom50 said:
http://www.colecovision.eu/stm8/compilers.shtml comparison is interesting, but I don't understand the size chart. How does size vary depending on the benchmark being run?

Tomtom50, The size difference is limited and the used benchmarks had greater impact on the speeds obtained than sizes obtained. They all performed about the same, size-wise, and some compilers could perform better if more consideration was put into optimizing for its strengths.

When looking at the size chart we see that SDCC, using Dhrystone as benchmark, generated a size of about 7500 bytes. The best one, Raisonance, generated a size of around 5500 bytes. This makes Raisonance generated code around 27 percent smaller than SDCC generated code. But comparing with and adding the speed in the equation, SDCC can be 31 percent faster when testing with the same benchmark, Dhrystone. So you win some, you lose some.

So much more to add to this but... I apologize if your question is not answered, Tomtom50!

casainho said:
[ Perryscope ] thanks for writing the article about TSDZ2 and the OpenSource firmware!!

https://empoweredpeople.co.uk/2019/01/20/experimenting-with-the-tsdz2-mid-drive-system/

Very nice article! I find it great that more and more get to read about and maybe even get involved in this community. And what a great organisation that is!
 
buba said:
...
Therefore, I had the chance to quickly test the changes I have been working on. All seems fine. To be honest I am very excited to get it out for you all to test for yourselves! :) There will always be room for some improvements or bug fixes. Especially now that the entire firmware is getting optimized at the same time new functions are implemented.
...
Updated wiki:
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.18.X-(beta)

Great news buba! Thanks again! How are you optimizing the firmware? Is this a compiler function?

Some of us would be happy to help test if we had a link!
 
Rydon said:
Great news buba! Thanks again! How are you optimizing the firmware? Is this a compiler function?

Some of us would be happy to help test if we had a link!

Thanks! The firmware is strictly optimized by rewriting the source code for now. The compiler and all build settings are the same so as not to create confusion and compatibility issues.

The firmware is being optimized by making it more condensed but still retaining functionality. This is possible to a point but there is always a limit.

I think Casainho will release the official beta as soon as he reviews the code and merges it.

But here is my personal folder with the latest firmware:
https://drive.google.com/open?id=1HJMJc7cc9YsG1G83TUbpZwQxJcO2m023

Do keep in mind that the firmware has been optimized and it is very important to at least look through the Configuration Menu and confirm that everything is set to correct values so that it works as expected! Best thing to do is to reset the firmware or to do as Rafe suggested, quoted here below. I really do apologize for any inconvenience!

Why ensure that everything is set correctly? I do not use two versions for the controller. Previously there has always been a throttle and a no-throttle version. So be careful that the throttle is not enabled if you have the motor temperature sensor installed. Or else the bike might start to move as soon as it is powered on.

To enable/disable the throttle or the motor temperature protection go to the configuration menu under the sub menu Motor Temperature Protection.

Updated wiki:
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.18.X-(beta)


Rafe said:
buba said:
- Scroll through the configuration menu and make sure everything is set as desired
- Make a total reset so the default values are loaded and then configure as desired

What I do and it works well for me is when I first start ST visual programmer it automatically presents pages of all zeros for both the programme memory and data memory, then I simply programme each tab with the zeros so nothing remains of the previous firmware. Then I write the new version into the programme memory.
 
buba said:
casainho said:
2. Remove specific menu for setup max power and instead implement the following code that I am using on Bafang 850C LCD...

Will definitely look into that! Nice work on the 850C by the way!
I am happy on the memory limitation of KT-LCD3 and so we will finish the project. What is your next project? Bafang 850C color LCD or the smaller KT-LCD5??

KT-LCD5 has the advantage of being smaller and is to be placed on one side on the handle bar, leaving free the center space for a mobile, GPS, etc.

KT-LCD5 is very similar to KT-LCD3 but has less the power field on the LCD, so the firmware would need the power field code removed (but the power field can still be shown on the odometer field, so is just the same code as LCD3 minus the power field code).

As you can see, the LCD driver IC is just the same 1622. The pins of STM8 may be different. I have 2 units of LCD5 to play and with my help and with your experience, I bet we could port the firmware in less then 1 week. Would be to place #ifdefs on the code differences of both LCDs, that would be on power field code, on LCD driver code and STM8 pins code.

See here the datasheets and pictures: https://opensourceebikefirmware.bitbucket.io/development/Motor_controllers--BMSBattery_S_series--LCD_control_panel.html



 
buba said:
Thanks! The firmware is strictly optimized by rewriting the source code for now. The compiler and all build settings are the same so as not to create confusion and compatibility issues.

The firmware is being optimized by making it more condensed but still retaining functionality. This is possible to a point but there is always a limit.

I think Casainho will release the official beta as soon as he reviews the code and merges it.
I was looking at the code changes and there are 2 things I would like you to clarify:

1. you added new features for showing variables on temperature field. Is that really need when you are looking to reduce the code?

2. you removed quick power limit configuration feature due to code size limitations but you added 1.?
 
casainho said:
I am happy on the memory limitation of KT-LCD3 and so we will finish the project. What is your next project? Bafang 850C color LCD or the smaller KT-LCD5??
...

It is exciting that the KT-LCD3 is soon completely finished! I am still thinking about my next project and what the next best step is.

In the meantime I am reading about the different displays and I thank you for the link to the KT-LCD5!


casainho said:
I was looking at the code changes and there are 2 things I would like you to clarify:

1. you added new features for showing variables on temperature field. Is that really need when you are looking to reduce the code?

2. you removed quick power limit configuration feature due to code size limitations but you added 1.?

This is because I have started to optimize the compiler as well. I am still looking at optimizing the source code and this is the main priority. But it may be good to look at the compiler settings as well. When setting the SDCC compiler to optimize for size we can have that new function and it takes up less space than before.

But even without optimization this new function takes up less space than before.

The pull request you received has no compiler optimizations as this is a work in progress. I do not want to bother you with this until I can give you my best advice on what to do.

I can not stress enough that the last thing I want to do is remove functionality so this is why I wanted to keep that function, albeit in a different form factor. If there are any problems it is easy to remove. But as there is some space now after my optimizations I found that it was a good idea to have it in the current pull request.
 
Hello everyone,

speaking about the KT-LCD3, for me, the button input doesn't feel very "snappy". It seems to be a bit laggy and it sometimes misses inputs. Is this a hardware/performance issue or is there maybe some room for code optimizations?

Greetings
Niklas
 
So which display should i order, I'm a bit confused. It looks like lcd3 has best support but configuration menus are a bit hard. I also see that there is some development with 850c and now i see lcd5 is in play as well? I'm planning to flash the casaihnos oss firmware in a month so don't know which one of the displays is going to be fully supported when the time comes.

I'm developer by trade but not much experience with controller programming, how can I help?

What do you guys think of using these connectors instead of original ones?

https://s.click.aliexpress.com/e/c4yQRgPO
 
hefest said:
So which display should i order, I'm a bit confused. It looks like lcd3 has best support but configuration menus are a bit hard. I also see that there is some development with 850c and now i see lcd5 is in play as well? I'm planning to flash the casaihnos oss firmware in a month so don't know which one of the displays is going to be fully supported when the time comes.

I'm developer by trade but not much experience with controller programming, how can I help?
LCD3.

And that 3 LCDs are very different, if firmware was ready for all of them, what would you prefer and why?
 
hefest said:
What do you guys think of using these connectors instead of original ones?

https://s.click.aliexpress.com/e/c4yQRgPO

Those are nice waterproof connectors but they are extremely bulky compared to the Higo's. They look fine under the hood of a car but not so nice hanging off of a bicycle. They do have the advantage of field termination whereas the Higo connectors are factory terminated. The waterproof connectors TongSheng and Bafang use are not much bigger than the wire cable they are part of and make for a clean conversion. If you are thinking of using it only to replace the 8 pin connector then perhaps you can hide it and it is a good choice.
 
Good Morning! beta v 0.18.2 excellent, only inconvenient, the on / off button together button up is activated very soon when wearing gloves, thank you very much for your time and dedication. :idea:
 
casainho said:
hefest said:
So which display should i order, I'm a bit confused. It looks like lcd3 has best support but configuration menus are a bit hard. I also see that there is some development with 850c and now i see lcd5 is in play as well? I'm planning to flash the casaihnos oss firmware in a month so don't know which one of the displays is going to be fully supported when the time comes.

I'm developer by trade but not much experience with controller programming, how can I help?
LCD3.

And that 3 LCDs are very different, if firmware was ready for all of them, what would you prefer and why?
I'd preferer lcd5, but only if it had settings a bit more descriptive. Lcd5 is smaller and I don't see my self looking into the screen a lot that it makes sense to have something as bulky as lcd3 and 850c. My guess is lcd5 is also cheaper.
 
Back
Top