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

casainho said:
Although I got the sequence, I may be doing something wrong on the code... Maybe you can look at it. Look at 850C init code to compare, as it is similar idea.

By guessing I mean try to find other codes where init codes are similar.

So after some digging on the internet I think we have an SH1107 controller. I compared this init code (line 571 and following):
https://github.com/micooke/sparkfun...3975c3c73a57fda14be3/src/SFE_MicroOLED.h#L571
with your init code and it fits quiet well although some are missing or different. You can find some comments in this text file:


I do STM32 F0/F1 development for living but never get in touch with display programming and initialization. So you are for sure more competent. If I have to guess, I miss the command 0xAF (display ON) at the end of your init code and I also read that timing is crucial during initialization (but I don't see any wait states in the other code) and after initialization (the other code waits for 100 ms).

U8G2 Library supports SH1107 also:
https://github.com/olikraus/u8g2/blob/master/csrc/u8x8_d_sh1107.c

The SH1107 Datasheet:
https://www.displayfuture.com/Display/datasheet/controller/SH1107.pdf
 
casainho said:
Nick said:
I really like those SW102 displays because do be honest I think the LCD3 is far from a modern good looking display and the 850c is way to big.
My opinion on LCDs.

LCD3 was nice for the development because it is flexible enough so I could send debug data to it while developing the code. Also this LCD is cheap and was simple and fast to develop for. It is also very easy to open and solder the flash/debug pins.
Currently LCD flash memory is full, can't handle any more features.

850C is the big and has the RTC that let us implement time clock. I always drive against the clock that is shown on this LCD, for me is very important to have this.
This LCD is also not very hard to open and solder the flash/debug pins.
The big screen is way better on configuration menus and data that is presented to user. I also want to present data is numeric fields and/or graphs (2 graphs OR 1 graph and 4 numeric fields OR 8 numeric fields).
This LCD has 512kBytes memory and only about 1/4 of is is being used right now.

SW102 is the hardest to open and solder the flash/debug pins. It is small and has Bluetooth, something some users are asking.
Has no RTC, so no time clock.
The screen is very small but for configurations and advanced data, we can develop a mobile app.
Has the potential to communicate with the Smart Bluetooth BMS and this way integrate on the same system the EBike motor, BMS, LCD and mobile app.
The drive of LCD is not yet working.
Has 256KBytes of flash memory but about half of that is used by the Bluetooth stack. If we want to add the Bluetooth bootloader, I am afraid we can end up like LCD3, without memory.

500C, it is impossible to open to solder the flash/debug pins (unless users cut the enclosure at a specific location to access the board).
Has a medium size and share the hardware with 850C although misses the RTC (time clock).
---

I think 850C and SW102 are good ones because they are very different and may be useful for different type of users. The 500C is in the middle on this 2 and so I would skip this one.
potentially sw102 can sync the time with the smartphone
 
e3s said:
potentially sw102 can sync the time with the smartphone
I don't have much experience with RTCs but I know that the microcontroller NRF51 on SW102 can use very low power and maybe we can keep it always enabled because it should not discharge the battery. Maybe it can try to keep the time and update the time when the user smartphone is near.
 
Nick said:
If I have to guess, I miss the command 0xAF (display ON) at the end of your init code
I think you are right!! I ignored the full sequence of init the logic analyzer recorded because I saw all zeros that I guessed was to blank the display. We can see that the very last command is 0xAF (and it appears only once, there!).
And there is a delay of 32ms after last zero and the 0xAF.

image.png


Can you try it? You can copy from the DSView logic analyzer recorded files: https://github.com/OpenSource-EBike-firmware/Color_LCD/tree/master/Bafang_LCD_SW102/DSLogic_save_files_LCD_data_signals
 
i know we are out of space for new code on the ktlcd3, but on future displays it would be great to have a battery profile menu.
where everything needed to swap to a different voltage, capacity of battery was able to be saved. and switched between with ease.
 
la8rat said:
i know we are out of space for new code on the ktlcd3, but on future displays it would be great to have a battery profile menu.
where everything needed to swap to a different voltage, capacity of battery was able to be saved. and switched between with ease.
So you need that? Can you please explain why and how are doing it??
 
casainho said:
la8rat said:
i know we are out of space for new code on the ktlcd3, but on future displays it would be great to have a battery profile menu.
where everything needed to swap to a different voltage, capacity of battery was able to be saved. and switched between with ease.
So you need that? Can you please explain why and how are doing it??

good morning

i have 3 batteries, 13s3p 13s5p and a 14s5p i swap between the batteries often for short fast ride i use 13s3p the others for longer rides. they all obviously need different setting that are spread across a few different menus.
i find i forget the various setting and what menu they are in.
how to implement? not sure maybe a nested sub menu for battery profiles names then lower menu for settings per battery.
 
Hi! So, I'm about to order parts for a build.

However;

According to local regulations:

You are restricted to 250w and 25km/h
OR
You are restricted to 1000w and 25km/h (albeit, its not allowed to have restrictions that's easily removable to increase speed aaand then some other requirements)

Question:

How hard is it to set 25km/h as top speed, and simply remove said setting field in the configuration menu?
 
casainho said:
Nick said:
If I have to guess, I miss the command 0xAF (display ON) at the end of your init code
...
Can you try it? You can copy from the DSView logic analyzer recorded files: https://github.com/OpenSource-EBike-firmware/Color_LCD/tree/master/Bafang_LCD_SW102/DSLogic_save_files_LCD_data_signals

I will set up the Dev Environment and do some first steps with this MCU. But this will take some days as my time is the limiting factor :(
But as soon as everything is up and running, I maybe can help with development.
 
I found an issue were motor would suddenly turn on when rotating pedals backwards. I solved that, all seems fine now.

I was testing walk assist and it was very strong to me so I changed the code that walk assist level represents now ADC step current, which is the minimum unit of current possible on the system. I still think is far from perfect but I think is not worst than original firmware.

Here the new beta: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.19.0-beta3
 
Today I tried the 0.19beta2 and I found out the following issues:

1. The displayed speed is correct, the passing time is correct, but the basic distance unit of the odometer increases by 0.2 km instead of 0.1 km.
Practically it doubles the distance travelled (and the distance left estimation).
I will double check the settings but I never experienced this before.
2. Walk assist too strong.. I did not test extensively but you have to run (not walk) besides the bicycle to keep up..
3. If I use the 1st assistance (I set it to a low value like 0.1) and the motor is currently giving some power, if I switch to assistance 0 while pedalling the motor keeps giving power even if I stop pedalling. It does not detected that assistance 0 is set (no power should be present) and even that there is no pedals turning.
4. I felt, in some assist level, that the motor cuts with a bit of delay when I stop pedalling. Not a problem if you have the brake cut off but still annoying.
I will try to reproduce to better report the behaviour.

Enough for today.. hope this helps the developers.

On the positive side, the backwards resistance seems ok now, no issues with a normal use in 40 km.
 
la8rat said:
casainho said:
la8rat said:
i know we are out of space for new code on the ktlcd3, but on future displays it would be great to have a battery profile menu.
where everything needed to swap to a different voltage, capacity of battery was able to be saved. and switched between with ease.
So you need that? Can you please explain why and how are doing it??

good morning

i have 3 batteries, 13s3p 13s5p and a 14s5p i swap between the batteries often for short fast ride i use 13s3p the others for longer rides. they all obviously need different setting that are spread across a few different menus.
i find i forget the various setting and what menu they are in.
how to implement? not sure maybe a nested sub menu for battery profiles names then lower menu for settings per battery.
I wrote an issue here so we will not forget but it is a kind of complex task, personally, I am not motivated to do it.
 
thineight said:
Today I tried the 0.19beta2 and I found out the following issues:

1. The displayed speed is correct, the passing time is correct, but the basic distance unit of the odometer increases by 0.2 km instead of 0.1 km.
Practically it doubles the distance travelled (and the distance left estimation).

I will double check the settings but I never experienced this before.
2. Walk assist too strong.. I did not test extensively but you have to run (not walk) besides the bicycle to keep up..
3. If I use the 1st assistance (I set it to a low value like 0.1) and the motor is currently giving some power, if I switch to assistance 0 while pedalling the motor keeps giving power even if I stop pedalling. It does not detected that assistance 0 is set (no power should be present) and even that there is no pedals turning.
4. I felt, in some assist level, that the motor cuts with a bit of delay when I stop pedalling. Not a problem if you have the brake cut off but still annoying.
I will try to reproduce to better report the behaviour.

Enough for today.. hope this helps the developers.

On the positive side, the backwards resistance seems ok now, no issues with a normal use in 40 km.

Bolded happens to me also with 0.19.X (BETA).
I try today beta2
 
casainho said:
I was testing walk assist and it was very strong to me so I changed the code that walk assist level represents now ADC step current, which is the minimum unit of current possible on the system. I still think is far from perfect but I think is not worst than original firmware.

I would of loved to hear some feedback of why this has happened and what the problem was exactly. I think there is something different causing the problem - not the previous code. Can someone else confirm the walk assist worked with high level of adjustability and precision and that it has suddenly changed in the last firmware changes? If this is the case even the Cruise function will not function properly so this leads me to believe this needs investigation.

I just got home from abroad and will try to test the firmware changes the next couple of days.



thineight said:
Today I tried the 0.19beta2 and I found out the following issues:

1. The displayed speed is correct, the passing time is correct, but the basic distance unit of the odometer increases by 0.2 km instead of 0.1 km.
Practically it doubles the distance travelled (and the distance left estimation).
I will double check the settings but I never experienced this before.

Will fix! :)



thineight said:
2. Walk assist too strong.. I did not test extensively but you have to run (not walk) besides the bicycle to keep up..

Very strange. There is a bug introduced with the last couple of firmware changes. Can confirm it worked as expected just before the last couple of changes to the motor controller firmware. See above discussion.



thineight said:
3. If I use the 1st assistance (I set it to a low value like 0.1) and the motor is currently giving some power, if I switch to assistance 0 while pedalling the motor keeps giving power even if I stop pedalling. It does not detected that assistance 0 is set (no power should be present) and even that there is no pedals turning.
4. I felt, in some assist level, that the motor cuts with a bit of delay when I stop pedalling. Not a problem if you have the brake cut off but still annoying.
I will try to reproduce to better report the behaviour.

I think Casainho is trying to solve this. :)



thineight said:
Enough for today.. hope this helps the developers.

As always, thanks thineight!



dameri said:
thineight said:
Today I tried the 0.19beta2 and I found out the following issues:
...

Bolded happens to me also with 0.19.X (BETA).
I try today beta2

Thank you dameri, see above!
 
Please try latest beta that is 3:

https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.19.0-beta3
 
casainho said:
Please try latest beta that is 3:

https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/v0.19.0-beta3

I try if I manage in programming. I have again problems.
I have to check cables etc.

Thank you for publishing new version quickly.
 
I guess beta3 solves perhaps 1-2 of the issues listed above, but not them all. Better wait the next one, at least for the bug n.1 :wink:
Correct me if I'm wrong
 
buba said:
thineight said:
2. Walk assist too strong.. I did not test extensively but you have to run (not walk) besides the bicycle to keep up..

Very strange. There is a bug introduced with the last couple of firmware changes. Can confirm it worked as expected just before the last couple of changes to the motor controller firmware. See above discussion.
Your last code had that issue and on beta2, I decide to try that smallest current units -- sorry for changing your code before you had the opportunity to improve it. But can can always go backwards.

One day I would like to control the motor ERPS using the PWM duty-cycle, where motor ERPS target --> motor ERPS at wheel_speed at 5km/h.
 
thineight said:
I guess beta3 solves perhaps 1-2 of the issues listed above, but not them all. Better wait the next one, at least for the bug n.1 :wink:
Correct me if I'm wrong

Just wanted to test my solution for the distance bug and validate it. Will give feedback ASAP but looks good for now!

Tested walk assist with the wheels in the air and the motor gave full power and would not stop. I have an on-off switch on the battery so was able to force the system off. Have not setup the Walk Assist function with the new controller firmware. Just wanted to quickly test the beta 3.

Would not advice anyone testing without taking appropriate precautions and setup the system correctly, please be safe!
 
casainho said:
buba said:
thineight said:
2. Walk assist too strong.. I did not test extensively but you have to run (not walk) besides the bicycle to keep up..

Very strange. There is a bug introduced with the last couple of firmware changes. Can confirm it worked as expected just before the last couple of changes to the motor controller firmware. See above discussion.
Your last code had that issue and on beta2, I decide to try that smallest current units -- sorry for changing your code before you had the opportunity to improve it. But can can always go backwards.

One day I would like to control the motor ERPS using the PWM duty-cycle, where motor ERPS target --> motor ERPS at wheel_speed at 5km/h.

The code is unchanged since 0.18.X where it worked and got validated from the users. That is why I said there has to be something new to the controller firmware that changes the operation of the function.

But there is no problem at all and we can always go back! Just want to know what happened as it is more powerful now for some reason.

I tried controlling the current in the first ever experiment on the walk assist but the problem was that there is a finite, and rather small, number of steps in the measurement of the current (ADC). This means the difference between steps is large for controlling a bike in the "walk assist mode" that needs precise control. Same thing on the Cruise function. Both functions jumped around more when controlling the current rather than motor PWM directly.

I regret not sharing the entire development on this and why both Cruise and Walk Assist were made with PWM control on the TSDZ2. I think what you suggest:

casainho said:
One day I would like to control the motor ERPS using the PWM duty-cycle, where motor ERPS target --> motor ERPS at wheel_speed at 5km/h.

... is the best implementation on the Walk Assist as it would be a closed loop system. This is definitely a good future enhancement.
 
mittkonto said:
Hi! So, I'm about to order parts for a build.

However;

According to local regulations:

You are restricted to 250w and 25km/h
OR
You are restricted to 1000w and 25km/h (albeit, its not allowed to have restrictions that's easily removable to increase speed aaand then some other requirements)

Question:

How hard is it to set 25km/h as top speed, and simply remove said setting field in the configuration menu?

Hi!

In Sweden you fall under the category: "moped klass II". That is to say a maximum motor power of 1000 watt and a maximum speed of 25 km/h. But you still need insurance when using it on the roads. On top of this, as you mentioned, you need to fulfill many other requirements for that class of transportation. So to be fully legal there is a lot of work.

But if you manage to fulfill all the requirements and you are only left with the speed setting being too easy to change there is sadly no implementation of what you are looking for. It is possible to make a firmware locked to a maximum speed of 25 km/h and with a maximum motor power of 1000 watts. But then it would be necessary to write a custom firmware for every country and its different laws and regulations.

Even the stock firmware has the ability to easily change the maximum speed. Sorry if this does not help but just wanted to clear it out.
 
buba said:
mittkonto said:
Hi! So, I'm about to order parts for a build.

However;

According to local regulations:

You are restricted to 250w and 25km/h
OR
You are restricted to 1000w and 25km/h (albeit, its not allowed to have restrictions that's easily removable to increase speed aaand then some other requirements)

Question:

How hard is it to set 25km/h as top speed, and simply remove said setting field in the configuration menu?

Hi!

In Sweden you fall under the category: moped klass II. That is to say a maximum motor power of 1000 watt and a maximum speed of 25 km/h. But you still need insurance when using it on the roads. On top of this, as you mentioned, you need to fulfill many other requirements for that class of transportation. So to be fully legal there is a lot of work.

But if you manage to fulfill all the requirements and you are only left with the speed setting being too easy to change there is sadly no implementation of what you are looking for. It is possible to make a firmware locked to a maximum speed of 25 km/h and with a maximum motor power of 1000 watts. But then it would be necessary to write a custom firmware for every country and its different laws and regulations.

Even the stock firmware has the ability to easily change the maximum speed. Sorry if this does not help but just wanted to clear it out.
Would be possible for a quick override of max speed limit value that is sent from LCD, override to 25km/h or any other value.
The same for motor max power value.

As this is very simple to do, I think users should do that by themselves and maybe write some notes to help next others.
 
casainho said:
la8rat said:
casainho said:
la8rat said:
i know we are out of space for new code on the ktlcd3, but on future displays it would be great to have a battery profile menu.
where everything needed to swap to a different voltage, capacity of battery was able to be saved. and switched between with ease.
So you need that? Can you please explain why and how are doing it??

good morning

i have 3 batteries, 13s3p 13s5p and a 14s5p i swap between the batteries often for short fast ride i use 13s3p the others for longer rides. they all obviously need different setting that are spread across a few different menus.
i find i forget the various setting and what menu they are in.
how to implement? not sure maybe a nested sub menu for battery profiles names then lower menu for settings per battery.
I wrote an issue here so we will not forget but it is a kind of complex task, personally, I am not motivated to do it.

ok thanks for taking a note of it. ive made myself a chart with menu locations and values. its on my phone so its not a huge hassle any more.
 
Back
Top