TSDZ2 mid drive with 860C, 850C or SW102 displays only -- Flexible OpenSource firmware (Casainho code only)
- Thread starter casainho
- Start date
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,045
Yes but please check if this make sense, try look at the ADC values, simulate and try think if it was the same as apply brake sensor.vshitikov said:
For a first testing version I will not make it configurable, just later after you say it is working.
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,045
Look that my USB<->UART don´t have any LED so that would bring confusion to make a such detailed information of something the user may not have.bergerandfries said:
Maybe a good idea is to make some notes explaining that if it does not work, for user to make sure the TX and RX wires are correct and if user is using a USB<->UART that has LED, to use them to understand if the communications are happening.
If you write this notes, I can add to the wiki. Must be generic notes and not specific as there many different USB<->UART on the market.
casainho said:
Sorry for the delayed answer. I was doing a small project with the kids at home.
Condition ACD torque sensor value Threshold configuration
Left Pedal Right Pedal delta summed
Stand still 0 kg 134 140
Motor running - A.L. 1 118 127 29 #define COASTER_BRAKE_TORQUE_THRESHOLD 40
Motor off 1 kg 128 137 9 #define COASTER_BRAKE_TORQUE_THRESHOLD 13
(In edit mode the table looks fine, but displayed in the forum is not aligned). In case you can not see it I have to put is as a photo or send it by email.)
These are the values I have measured. They differ a bit from the config, maybe because of the delay they are send to the display.
For threshold 40 on my bike I see the sum for the left and right pedal is 29. Thats a bit excessive.
Trying with Assist level 0. Braking force of 1 kg per pedal. On my bike on the left pedal I get delta 6 and on the right 3 with a sum of 9. Approximated to the existing configuration value of 40, for me desired value should be only 30 % of it or about 13.
#define COASTER_BRAKE_TORQUE_THRESHOLD 13
About the motor stop, we may try two options:
1. Exactly the same motor braking function that we use for the hand brake.
2. In case 1 is not good for the motor which I really doubt, fade out of motor power for a predefined period of time may be implemented.
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,045
Ok, that is the important information.plpetrov said:
Now, please look at the motor speed ERPS and see how that value changes when you are pedaling with motor turned off/ assist level 0.
Does that value is 0 when you brake? If you do sucessive brakes, do you see the value changing??
casainho said:
About the motor speed:
1. Turning forward I do not see change of the value. It remains 0. May be once I saw 1 but I can not reproduce it any more.
2. Braking:
a. Soft braking - the value goes to 50 - 60
b. Mid power braking - the value is between 90 and 100
c. Hard sudden braking - the value is between 130 and 140
The tests are done with the real wheel rotating free in the air with no load.
skestans
100 W
casainho said:
That's not what's happening in my case. The clock is never reset to 0h0 on startup, it's just inaccurate. How long it takes before becoming inaccurate depends on how long was the display powered on between uses. I used the bike 2x10 minutes 24h ago, the clock is still accurate right now. When I was doing my testing, I didn't use the bikes for a whole week except turning the display on at regular interval to check the time and reconfigure it if needed. In this second scenario, the clock couldn't stay accurate for more than 2h off.
This happens on two bicycles, both with displays that have a timestamp on the back of 2019/09 and 2019/10.
Thus, I don't think it's an internal battery problem. There is more going on.
Also, good luck returning the display once it has the FOSS firmware on it: warranty is void and the seller won't take it back.
sparked
100 µW
- Joined
- Mar 28, 2020
- Messages
- 9
Olá casainho, first of all a big thanks for all your hard work (and that of others) on this fantastic firmware. Coming from 850C_v0.6.8(bootloader)/v0.55 I am now trying to update to 850C_v0.7.0-bootloader/v.0.65 for safety reasons, but running into the error-message you mentioned here:
Could you further explain what might be causing this problem? The display never moves past this screen and can only turn it off by switching off the battery.
On a side note: I can confirm another inaccurate clock.
casainho said:
Could you further explain what might be causing this problem? The display never moves past this screen and can only turn it off by switching off the battery.
On a side note: I can confirm another inaccurate clock.
With the coaster brake version of the motor, turning the pedals backwards immediately creates negative torque.hefest said:
In the freewheel bikes, I think there is one more clutch that will prevent the creation of the negative torque, as the clutch will disengage. I don’t know if with the PAS sensor is possible to detect the backwards pedal rotation and eventually the angle by which the pedals have been rotated backwards. I am afraid only Casainho will be able to answer this questions.
bergerandfries
1 W
- Joined
- Mar 2, 2019
- Messages
- 59
Thanks for that point of view casainho! I knew it would be good to discuss it in the forum before deciding on final text. I would draft something like this then and ask for feedback from tomcys and others:casainho said:
After you have selected the firmware file for 850c display with the "OpenFirmWare" button and pushed the "UpdateFirmWare" button, if the Activity Log shows "waiting..." repeatedly, even after a quick press of the power button on the display, check that the display LCD screen shows nothing but black. If the flashing does not start and the message in the program kept repeating "waiting...", you might be able to get some information from your USB to UART device (for example, some devices have LEDs that can show voltage present on transmit or receive. If you power the display on and off with a long press of the power button, you may see LED behavior to help you determine the problem). Also, while the APT software is waiting, the numbers values near the APT window at the bottom labelled "Tx" are constantly increasing, while number near the window labelled "Rx" stays at "0". This means that there is a problem with Tx and/or Rx connection. Check your wiring for breaks or reversal and try again.
This morning I went to flash v0.7.0 because I was on 6.8 and had some of the bad issues.
Anyway I hooked it up and flashed it and now the display is dead and will not power up.
My steps were as follows.
Battery removed from the trike.
Display disconnected but remote buttons still connected.
Plugged box into display and then into USB port.
Opened Apt burn tools
Opened the port – no errors
Opened the firmware file
Pressed Update firmware
Then pressed the power button on remote and the firmware update completed without error. Watched the progress meter move.
After finished I closed the software and disconnected it.
The cables and box were purchased from Eco-bikes so I did not build or wire the programming cables.
Any idea what I may have done or if there is any way to fix it.?
Anyway I hooked it up and flashed it and now the display is dead and will not power up.
My steps were as follows.
Battery removed from the trike.
Display disconnected but remote buttons still connected.
Plugged box into display and then into USB port.
Opened Apt burn tools
Opened the port – no errors
Opened the firmware file
Pressed Update firmware
Then pressed the power button on remote and the firmware update completed without error. Watched the progress meter move.
After finished I closed the software and disconnected it.
The cables and box were purchased from Eco-bikes so I did not build or wire the programming cables.
Any idea what I may have done or if there is any way to fix it.?
Hello
First of all a little introduction. I started using this forum when I decided to electrify my longtail cargo bike Yuba Sweet Curry.
I really like opensource firmware for Tongsheng, great project and many talented people working together. I'm not very experienced in firmware but rather in electronics.
I have read about the improvements with the overrun that were done in the other branch by Mbrusa user on this forum. I really like the idea because the biggest trouble with electrified bikes is the chain/derailler wear and slippage.
I finally got impatient and decided to merge Mbrusa changes about the overrun inside the Casainho code for the 0.54 FW used with my 850C display.
It took me a while to get familiar with the Casainho code for the motor but I start to understand state machine for the motor control in the motor.c .
Finally I succeed in replicate what Mbrusa did on the Buba branch within the Casainho code. We can see the improvement in terms of the overrun. Casainho code was already not very bad in terms of the overrun. We had about ~0.7 sec of the overrun in the current version. I decided to go for improvement because I wanted to prevent my chain slipping during the gear change. Mbrusa version gives about 0.25 sec of the overrun depending on the pedal rotation speed. One can feel clear motor stop. I kept the original Mbrusa code which is explained here:
https://endless-sphere.com/forums/viewtopic.php?f=30&t=104232&p=1536265#p1536256
and here
https://endless-sphere.com/forums/viewtopic.php?f=30&t=98281&p=1538893#p1538893
I'm attaching the Motor.c file for those who want to play with it. I did not use the latest version but with the stable release 0.54
I might merge it to the latest one tomorrow if people are interested.
I don't know if throttle will work with it I did not test it as I don't have it on my bike (most probably it will not work). There might be some bugs as I only quickly tested it for 5 minutes, cannot do more in the current confinement in France.
The changes are very minimal.
First of all a little introduction. I started using this forum when I decided to electrify my longtail cargo bike Yuba Sweet Curry.
I really like opensource firmware for Tongsheng, great project and many talented people working together. I'm not very experienced in firmware but rather in electronics.
I have read about the improvements with the overrun that were done in the other branch by Mbrusa user on this forum. I really like the idea because the biggest trouble with electrified bikes is the chain/derailler wear and slippage.
I finally got impatient and decided to merge Mbrusa changes about the overrun inside the Casainho code for the 0.54 FW used with my 850C display.
It took me a while to get familiar with the Casainho code for the motor but I start to understand state machine for the motor control in the motor.c .
Finally I succeed in replicate what Mbrusa did on the Buba branch within the Casainho code. We can see the improvement in terms of the overrun. Casainho code was already not very bad in terms of the overrun. We had about ~0.7 sec of the overrun in the current version. I decided to go for improvement because I wanted to prevent my chain slipping during the gear change. Mbrusa version gives about 0.25 sec of the overrun depending on the pedal rotation speed. One can feel clear motor stop. I kept the original Mbrusa code which is explained here:
https://endless-sphere.com/forums/viewtopic.php?f=30&t=104232&p=1536265#p1536256
and here
https://endless-sphere.com/forums/viewtopic.php?f=30&t=98281&p=1538893#p1538893
I'm attaching the Motor.c file for those who want to play with it. I did not use the latest version but with the stable release 0.54
I might merge it to the latest one tomorrow if people are interested.
I don't know if throttle will work with it I did not test it as I don't have it on my bike (most probably it will not work). There might be some bugs as I only quickly tested it for 5 minutes, cannot do more in the current confinement in France.
The changes are very minimal.
HughF
100 W
Any plans to implement an eMTB mode where it automatically steps up through the assist levels depending on torque input?
Similar threads
