TSDZ2 mid drive with 860C, 850C or SW102 displays only -- Flexible OpenSource firmware (Casainho code only)
- Thread starter casainho
- Start date
HughF
100 W
Excellent - set the current ramp to maximum (10a), went and did another 20k - great performance. I am going to get my hands on my luggage scales on Wednesday then I can calibrate the torque sensor.r0mko said:
So far, very pleased with this firmware for my single speed bike. I don't really care for my blue gear, if it strips, I will replace it... I just want maximum performance when I stand on the pedals and this gives me that.
ezrider1199
10 W
- Joined
- Jul 2, 2019
- Messages
- 77
New firmware doesn't work. I went outside and it's getting a trickle of power using throttle and no assist at all. Have to go home. Casainho, are you using a different branch of code when you test? I'm just wondering what the QA and testing is like..
Edit: just experienced the bike lurch full power for a second when I was pedaling off the seat
Edit2: ok this partly my own fault. The assist was set at 0 and I couldn't see it in the sunlight. But why didn't the throttle work?? And why did the bike lurch under assist 0?? Also throttle seems to be going through some bad code logic because it keeps lurching - huge bug.
Edit: just experienced the bike lurch full power for a second when I was pedaling off the seat
Edit2: ok this partly my own fault. The assist was set at 0 and I couldn't see it in the sunlight. But why didn't the throttle work?? And why did the bike lurch under assist 0?? Also throttle seems to be going through some bad code logic because it keeps lurching - huge bug.
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,045
New firmware release v0.8.0
Download here: https://github.com/OpenSource-EBike-firmware/Color_LCD/releases/tag/860C_850C_SW102_v0.8.0
Changelog:
- corrected the long delay that motor took to stop after stop pedaling (thank to mbrusa)
- added street mode with quick configuration from display main screen
- added motor max power limit with quick configuration from display main screen
- added internal battery resistance automatic calculation
- corrected issue on motor selection type (thanks to r0mko)
- added negative torque signal for braking that should apply only to TSDZ2 coast brake version (thanks to plpetrov)
- corrected an issue where 860C display buttons were configured to be the same as 850C (no M button usage)
Download here: https://github.com/OpenSource-EBike-firmware/Color_LCD/releases/tag/860C_850C_SW102_v0.8.0
Changelog:
- corrected the long delay that motor took to stop after stop pedaling (thank to mbrusa)
- added street mode with quick configuration from display main screen
- added motor max power limit with quick configuration from display main screen
- added internal battery resistance automatic calculation
- corrected issue on motor selection type (thanks to r0mko)
- added negative torque signal for braking that should apply only to TSDZ2 coast brake version (thanks to plpetrov)
- corrected an issue where 860C display buttons were configured to be the same as 850C (no M button usage)
ezrider1199
10 W
- Joined
- Jul 2, 2019
- Messages
- 77
Just tested the firmware out. The absence of motor overrun is a great feeling. Found a bug - I had the motor lurch at assist 0 when pedaling off the seat. Another bug - throttle is definitely *broken* in this release. When you try to accelerate with the throttle, it starts jerking as if power keeps coming on and off. Also at assist 0, i was getting a trickle (very little) power when using the throttle. Please please fix!
casainho said:
HughF
100 W
r0mko, any plans to add the overrun fix to your quick and dirty torque mode release?
ezrider1199 said:
I think this is because of the overrun. @Casainho, did you check the original fix from mbrusa. He had to modify ebike_app.c in order not to use overrrun fix when throttle is configured, otherwise it cuts the power if user is not pedaling.
Another question, did you managed to sort what user plpetrov had reported with weird behaviour at assist levels greater than 10?
Thank you
HughF said:
Perhaps it makes sense to integrate the torque mode back into the new firmware, but it seems to have some issues, so for now I'd better stick to the v0.56 FW with torque mode and figure out what is the actual overrun fix among other code changes.
casainho said:
Casainho, thank you for the new release. I will finish with the last test you asked me to do on the previous version and then try this one. I was busy with different things and for some other reasons I could not find the motivation to go on with the tests. I see someone mentioned QA and testing. I hope this is only a joke. Otherwise it will be a good idea to think also about project management, product management, product ownership, etc..... Sounds familiar to some of you?!
It’s not about that. We need to help, support and contribute to all the efforts of Casainho in order to achieve good common results. They will not be perfect from the first attempt , will not come immediately and maybe be will take several iterations. It’s just our hobby...
ezrider1199
10 W
- Joined
- Jul 2, 2019
- Messages
- 77
Sorry, i shouldve filtered myself from posting the first post (which i posted immediately). But in the second one you can see what i've found in the testing, hopefully more objective and composed than the first. I too am super super thankful for casainho and the community. Use my bike nearly every day so the motor & this firmware was a huge lifestyle change.
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,045
1. I could not replicate yet the changes I did, one of them did not consider the assist level 0. Should be solved now.ezrider1199 said:
2. I don't have throttle and so I could not test but yes, as others alerted, I was keeping throttle disabled while cadence = 0 -- should be fixed now.
Please give feedback, here is the new TSDZ2 motor firmware version 0.57.1: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/releases/tag/TSDZ2-v0.57.1
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,045
I am now start to thinking on the new feature that is let user being able to disable the sensors:r0mko said:
- torque sensor
- cadence sensor
- brake sensor
- wheel speed sensor
So, when user decides to disable the cadence sensor, then the system should work with torque sensor mode. The contrary for when the user disables the torque sensor, then the system should work with cadence. When both disable (like when with issues like broke pedal or issue on pedal cranks), then system will be able to work with the throttle or virtual throttle.
So my plan is to implement:
- sensors disable by user
- torque mode
- cadence mode
- virtual throttle
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,045
Yes, you were right about the throttle - it is fixed now.vshitikov said:
About the weird behaviour at assist levels greater than 10, I don't know... I hope you guys can provide more feedback of your tests as I am not having this issues.
About the negative torque to brake on the coast brake version, I prepared a display firmware version that shows the ADC torque sensor value instead of the odometer so seeing the odometer on main screen will help to debug and see how the ADC torque sensor value when braking.
https://github.com/OpenSource-EBike-firmware/Color_LCD/tree/testing_coast_brake/firmware/releases/0.8.1
casainho said:
Casainho,
I did the test you asked for still with version 0.56.2. And good news
Test 1: Configured start pedal ground right. Right pedal placed at the lowest position.
- The system behaves much much better. I could reach assist level 19 and could not get the previous power bursts. There is still wobbling of the motor RPMs with peak when we get the max torque sensor values. Human power increases but only to 2 or 3 at max.
Test 2: Configured start pedal ground left. Left pedal placed at the top position. Same behaviour as in Test 1.
In other two possible scenarios left there is no change and the problem is there.
Based on this, I can suggest that may be we need to take into account the delta in the torque sensor value for 0 load between the right and left pedal. May be better the max and the min values that are different than the ones at the point we do the calibration. How exactly I do not know. May be in the linearisation function to shift the 0 value of one of the pedals or to calculate the average value and subtract it from the pedal with higher value and add the same to the pedal with lower value. This could be the easies solution to implement. If it will work I have an idea of other simple solutions but they may have other side effects.
Do you want me to test the current release also? Which tests you would prefer to be preformed and what data you need?
casainho
10 GW
- Joined
- Feb 14, 2011
- Messages
- 6,045
Did you try to see if you get higher values of ADC at other points different from the calibration points? I remember to test at least one torque sensor and I would get higher values outside of calibration point, where I expect that to not happen!! I guess this is a (bad) characteristic of the torque sensor... and if this happens, then part of the issue can be here? Can you test your torque sensor values?plpetrov said:
I will look at code again to see if I can spot something wrong. What I know:
- left and right pedals have different ADC values rate for each increased KG (the firmware considers each pedal different from the other to take this difference in consideration)
- both left and right pedals usually have the same ADC values for 0 KG on the calibration point
- at least some torque sensors measure higher values outside of the calibration point, which I think should not happen
I did not changed anything about torque sensor on latest release BUT you should be able to see the value on the main screen as the odometer value, so, may be useful to use the latest version of display 0.8.1.
HughF
100 W
I like the sound of this, it sounds like a sensible way forward.casainho said:
Hello
I just flashed all the latest FW and the display and performed a quick test run. All seems to work fine, I don't see any regression or problems but I haven't tested all the configurations as I don't have throttle.
The problems that user Plpetrov is reporting with the quick motor bursts: I do not observe it in the real run. I think it might be related to the testing with the rear wheel up. When I test like this motor spins very fast because it has no wheel resistance and it is quickly pushing the rear wheel to the maximum speed. So I think there is no real problem with the FW. Plpetrov you migh test it on the real run.
I just flashed all the latest FW and the display and performed a quick test run. All seems to work fine, I don't see any regression or problems but I haven't tested all the configurations as I don't have throttle.
The problems that user Plpetrov is reporting with the quick motor bursts: I do not observe it in the real run. I think it might be related to the testing with the rear wheel up. When I test like this motor spins very fast because it has no wheel resistance and it is quickly pushing the rear wheel to the maximum speed. So I think there is no real problem with the FW. Plpetrov you migh test it on the real run.
casainho said:
It seems we are getting closer to resolve the mystery. As I suspected from the very beginning the problem is due to some specifics of my torque sensor. Both of your assumptions above are not true in my case:
It is not the case with me. On the left pedal I have 134 and on the right pedal I have 140. The delta is 6.casainho said:
Again not my case.casainho said:
On the left pedal I have at the calibration point 134 with maximum of 140. The delta is 6.
On the right side I have at the calibration point 140 with maximum of 143. The delta is 3.
That explains why I have problems mainly on the left side and much lest on the right.
In order to fix that we need to implement some correction in order to avoid the jump when switching from left to right and back right to left, also take into consideration the max values that are different from the calibration ones.
The error in my case only from rotating the pedals is 6 + 3 = 13 and that is equal to about 2.5 kg efforts applied on the pedals to reach these values. Multiplied with the high asset value this gives a burst.
I know that my case might be an exception but I doubt I am the only one. Just the other have not paid attention to that. I remember some previous report on power burst btw. They could have been caused the same reason.
It is related to some peculiarities of my torque sensor. See my answer to Casainho. However I doubt that I am the only one with this problem. In my opinion it is there with everyone but in my case is very well represented as I am reaching some extremes due to the sum of two unexpected conditions.vshitikov said:
Yes this is exactly my case with the left pedal. At the calibration point I have 134 with the maximum of 140 while on the display I still read left side.casainho said:
I did two more tests to try to find a solution. The are maybe not the best ones but does not require programming.
Test 1. I changed the calibration values for 0 with the maximum for each side. That improved the situation a lot. Left side 140 right side 143.
Test 2. I tried to equalise the both calibration values changing both to 143. Did not like the result very close to the original problem.
Test 3. Desided to take a value at the middle. Both set to 139. Very good but still improvement to be desired.
plpetrov said:
If I had the development environment I would have tested the following solution:
1. Will introduce a correction parameter that represent the difference between the torque value sensor at the calibration point and and the maximum value for each pedal side.
2. Try to equalise the values at 0 kg for the left and right pedal sides in order to avoid jumps at the point at which we switch from left to right or back.
3. Try to smooth the torque values reading in order to avoid jump up and down. E.G. the value used in the control loop will be the average lets say of the last 3 values received from the torque sensor.
Any of the three options will improve the situation, however he smoothest operation we will achieve only by implementing the thee of them.
Am I right about my conclusions or I am missing something. There could be also other options but this is what I can propose based on my limited experience with this project.
Similar threads
