TSDZ2 mid drive with 860C, 850C or SW102 displays only -- Flexible OpenSource firmware (Casainho code only)
- Thread starter casainho
- Start date
windburner
1 W
- Joined
- Sep 24, 2019
- Messages
- 54
vshitikov said:
Actually, the TSDZ2 Option Byte data IS included in this archive. It is the last file in the list, as STOCKOPTIONBYTE.s19. Has saved me much headache across my various Factory reversions, as I neglected to save my original before my first flash.
silvocross
100 W
- Joined
- Jan 16, 2012
- Messages
- 141
I all,
I'm a really happy TSDZ2 user and I have to thank all developers for their great job on the open source code.
I am using the TSDZ2 build 0.57 together with an SW102 v0.8 from Casainho on my E-MTB and it works really well. I now built a second bike for my girlfriend and sice I don't have any additional advanced Display I flashed the mbrusa FW on it and I am impressed about the eMTB mode: it works perfectly while offroading.
I saw some activities from Buba back in july 2019 trying to include this mode, but having a look at the latest ebike_app.c code I am not able to find this feature anymore.
I would like to have this mode on my bike but I still want to have the additional functionalities coming with the SW102 Display, is it planned to work on this feature again or shall I create my own fork for this?
Thanks a lot
Silvio
I'm a really happy TSDZ2 user and I have to thank all developers for their great job on the open source code.
I am using the TSDZ2 build 0.57 together with an SW102 v0.8 from Casainho on my E-MTB and it works really well. I now built a second bike for my girlfriend and sice I don't have any additional advanced Display I flashed the mbrusa FW on it and I am impressed about the eMTB mode: it works perfectly while offroading.
I saw some activities from Buba back in july 2019 trying to include this mode, but having a look at the latest ebike_app.c code I am not able to find this feature anymore.
I would like to have this mode on my bike but I still want to have the additional functionalities coming with the SW102 Display, is it planned to work on this feature again or shall I create my own fork for this?
Thanks a lot
Silvio
HughF
100 W
Sw102 coupled with the torque only fork that r0mko has built is awesome. Really awesome.silvocross said:
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,047
hetm4n said:
Here is a new version for you test, I did slower the time for the motor to stop:
https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/tree/master/releases/0.57.3
My current plan is to try have 2 possibilities, one that motor stops very fast once we stop pedaling and other that takes more time and avoid the issue on the full suspension bicycles - the user would need to choose between this 2 possibilities on the display.
That is very good information. So, can you please confirm that the coast brake version is working well in terms of braking? How do you compare with original firmware in terms of braking?plpetrov said:
Let's see if we can find the 2 possibilities that will work for users like you and the other for users like hetm4n.
The improvement on the torque sensor, let's see if we can improve after.
silvocross
100 W
- Joined
- Jan 16, 2012
- Messages
- 141
casainho said:
OK, I'll take a deeper look in the next days on this. Thanks
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,047
Soon this change will make no difference as the current available processing power will mostly full used to be able to increase the cadence over 90 RPM while not sacrificing the energy efficiency.r0mko said:
Yes, I would like to be able to fine tune this value on the display but was not a priority. Did you try a lower value like 7 or 6? Going in that direction the motor will start to brake, so, less torque for the same current.r0mko said:
For adding this feature to fine tune, it is also need documentation to explain the user how to do it and how to test/validate - how did you do it?
What does not make sense to me here is that you are decreasing the motor reaction time by increasing the value of PWM_DUTY_CYCLE_RAMP_UP_INVERSE_STEP and on the other side try to decrease the motor reaction time as ramp up current value.r0mko said:
Ramp up current value is applied on top of PWM_DUTY_CYCLE_RAMP_UP_INVERSE_STEP, so, are you sure the current ramp really increased? because I don't think it is possible, I did that implementation and validation test for both of them.
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,047
I think the user should calibrate first the torque sensor and have a correct measurement of weight on the pedals, then, the emtb curve is applied and the user will clear understand that the emtb curve will apply an increasing assist factor when the user increases the pedal weight.silvocross said:
Would be good to try reuse the current code, if possible, of the curve for torque sensor calibration. This code uses 8 points but maybe the emtb curve could use 16 points.
Implementing the emtb curve on top of the weight on the pedals and before the calculation of the pedal human power, will make possible to keep the 2 options of using pedal torque or pedal human power as also user disable the torque sensor or cadence sensor if one of them is failing.
casainho said:
What you mean by original firmware? The stock one or your firmware before the implementation of the overrun issue fix and the implementation of the negative torque functionality?
Do you think it will make sense to test also the 0.57.3 with the coaster brake?
Anything on the e: 8 Comms issue that I experienced? Once it is shown on the display the motor assis is gone. However all the rest is working fine. I see all information from the motor on the display e.g. like data from the different sensors, I can control the lights, I can edit the configuration.
First I tried 5 and got very substantial increase of low-end torque, but very weak assist at high RPM. I decided to go further and set value to 0, but got very high current and weak assist at any RPM. The sound of the motor has also changed, it became louder. Then I set it to 7, this value gave a nice push at low end but virtually no assist over 560 ERPS, so I decided to stick to 8, which appears to be a sweet spot for a 36V motor at 48V and experimental high-cadence setting for motor type. The only validation and testing equipment was the motor current display vs. subjective perceptions, so you decide whether or not to consider this as a solid evidence.casainho said:
casainho said:
My thoughts were the following. The PWM ramp step is 64µs, so with step of 40 the full range sweep from 0 to 255 for PWM takes 0,65 seconds. Since an average PWM ramp up during startup is about 0->60% (0-155), the value of 40 has no influence on motor responsivity, but helps to back off the motor when a sudden drop of load occurs (switching a gear, for instance).
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,047
The stock firmware, how does it compare in terms of the braking?plpetrov said:
If you think coast brake works well, so I think there is no point to test even older firmware versions.
In the middle of so many messages, I missed it.plpetrov said:
The error "e: 8 Comms" happens when the communication fails for over 1 second and it is a safe measure, like if user is pressing assist level but communications fail like the wires brake or something. I tried to use a lower value like 0.5 seconds but I got issues with SW102 and then I had to increase to 1 second.
Yes, that is a fatal error and motor will stop working until you restart the system.
Makes sense that the issue increases to you with high assist levels / high battery current because the higher the battery current the higher the interference on the communications cables -- I would say you can have some less then good contacts on the connectors for the display (maybe some oxidation due to water on the connector/wires??) or maybe the solution can be to take further the battery cable and the display cable... maybe you twisted them together??
I have not used the stock firmware since last year, so I am not sure how objective I can be in my conclusions. However:casainho said:
- I think your firmware handles much better the events that will precede a coaster braking. Stopping of the motor caused either by sharp decrease of the pedals' cadence AND / OR application of negative torque on the pedals. A nice feature will be to introduce a configuration value for the negative torque required to initiate motor braking. In case you feel in good mood and have time, maybe you can introduce one more value for torque braking for both the right and the left pedals for the cases like mine in which there is a difference in this value.
- In terms of "power howling" due to the always rotating pedals, I think the behaviour is exactly the same in case of free wheeling of the pedals. However with your software we have a significant improvement in case we have some weight on the pedals that will stop or delay the speed and power of the howling effect due to the torque braking. Here comes the importance of the configuration of this value as I would expect that for different weight of the legs of the cyclist, the user experience will be different. We might need different values for a kid that weights 20 kg and someone like us with weight of 90 +. Another point is the usage of the high assist levels. We know that with the stock firmware they are not there. So wee have either to introduce a limit or at least a warning to the coaster brake users in the Wiki to use them very carefully or to remove them from the configuration of their bikes as a safety feature.
casainho said:
The increased battery current and the interference to the communication cables was my first thought, as I have experienced this many times in my engineering practice. Using the maximum distance possible and crossing the cables at 90 degrees was done in the process of cabling. The only place where the 3 cables were running in parallel for 10 cm was at the exit of the motor. I cut the cable tie and separated the cables fixing them at different points now.
My connectors did never experienced any direct or indirect contact with water or extreme humidity. The cables extensions are done using soldering and the insulation is triple. The only concern I have is the length of the cable I have made, as for my bike I needed to to solder almost at full length one motor extension cable (80 cm) and one display extension cable (60 cm). At TTL levels the length of the cable might be critical for the serial transmission, however I did never experienced this or similar problem with the previous versions of the firmware. This might be just a coincidence though.
Thinking for bad contacts I tried unplugging ad plugging back the connectors. No change. Bending cables. No change.
Power on and off using the power button of the display. No change.
Unplugging and plugins back the battery. No change.
The only way to get out of the error condition was to change the power level and to restart the system by turning the power button for OFF and then ON. This cleared the error immediately.
I did also some other tests while having the error immediately after the motor initialisation message. I could enter and change motor configuration. I would monitor some of the values changing while rotating the pedals by hand w/o motor support, although not all values were available. There was no problem with switching on and off the lights.
All this makes me think that we have may be a bug that will appear only under a certain circumstance and may be cleared only after a combination of other circumstances. What is for sure:
Initiating conditions: is leaving the motor to run by itself at high asset level - 13 or up.
The exit condition: is change of power assist level (in my case to 0) and then power off and on. I think yesterday I achieved the same by resetting the display settings.
Simple power off and on does not clear the error. Same with battery disconnecting.
What is the voltage level at the TX and the RX wires. I assume it is 0 to 5 volts non inverted but I never measured it. Are the CPUs at the display side and motor side running both at 5 volts? Do we have any external or internal set in the controller pull up resistors? Do we set any values for them?
May be I need to order an oscilloscope in order to investigate further, in case I am the only one experiencing this issue. If I remember correctly there were other users describing similar issue even with older version of the firmware. It will be nice if we can collect more information or user experience on this.
I'm trying to compile the 850C display firmware with Eclipse under Windows 10, and it cannot find the header files located in the 860C_850C\src folder when compiling the common files, I get the following error:
In file included from ../../common/src/fault.c:1:
../../common/include/screen.h:8:10: fatal error: main.h: No such file or directory
8 | #include "main.h"
If I make a copy "main.h" in the folder common\include, it works but the same thing happens for all the header files.
I tried everything and cannot find a solution
@casainho or other, any ideas what I'm missing?
In file included from ../../common/src/fault.c:1:
../../common/include/screen.h:8:10: fatal error: main.h: No such file or directory
8 | #include "main.h"
If I make a copy "main.h" in the folder common\include, it works but the same thing happens for all the header files.
I tried everything and cannot find a solution
@casainho or other, any ideas what I'm missing?
agphil said:
Hello! I want to do the same both for the display and the motor. I remember seeing some posts related but I never saw an end to end manual how to prepare the development environment. Is it possible to get some help from those who have done it? I would prefer to base my attempt on a proven experience in order to avoid issues related with versions or configurations. This will be a nice addition to the wiki also.
@plpetrov I followed the steps listed there and was able to build the motor firmware:
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Development
Concerning the displays, one step missing is to set up Cygwin and the CDT, I think I'm close to be able to build the display firmware if the compiler could fine the header files.
I'm willing to update the wiki development page when I have every thing working.
[/quote]
https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Development
Concerning the displays, one step missing is to set up Cygwin and the CDT, I think I'm close to be able to build the display firmware if the compiler could fine the header files.
I'm willing to update the wiki development page when I have every thing working.
[/quote]
plpetrov said:
@agphil Thank you very much for the link. It is the perfect starting point. The only dilemma I have is on which operating system to set the environment. I use OSX as a guest operating system and I am running Linux and Windows as a virtual machines only. Any suggestions or recomendations?agphil said:
Similar threads
