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

[sabergo]

Are any more torque sensor readings of any value?

I was experimenting with the sensor measurements yesterday. The bike read 38 resting, but after a short ride it read 36 (resting). The max reading with me putting all weight (99.5 kilo) was 72 (on relatively flat ground). Firmware 18.2 on LCD 3.

I'll get some luggage scales or something and test if more samples are needed.

I'd planned to upgrade to the 850C, but I have to get a new soldering iron and some wick to clean up my first attempt

 

[fi7ippo]

Seems original does not implement that shifting, maybe we could use the Bafang shift sensor but seems no cares about it on TSDZ2.

This works perfectly in parallel on the brake sensor. I'd be curious to try it together with the Kit Archer D1X, but it costs as much as the TSDZ2 ...
Returning to the sensor, it has a braking pulse of 0.5 seconds when the shift cable moves. I bought it for $ 20 last year on eBay.
In my opinion, when the gear is increased it is ok. Feeling is fun when you go up a gear!
But if you're downshifting, it would have been useful to have a greater delay, maybe double, 1s! I don't think there are sensors with different delays for up or down gear, maybe with 1s of delay, if you find it it would be better.

Now thinking about the sensor the problem of downshifting, could be solved by firmware. Maybe setting a minimum braking time of 1 or 1.5s from when the brake sensor is activated.
Or, maybe You, Buba or others, it might as well surprise us with a parameter "Minimum braking time" in some submenu, even if I think it is not a priority thing at the moment, but good for safeguard the entire transmission, especially when you let your friends try your bike...

 

[buba]

This is the graph of my torque sensor and follows the same as presented before by another user (and I though I did a good calibration but in the end, it starts at 35 while it should start at 25).

Anyway, were is the graph. I used a fixed weight of 15 kgs to be able to measure up to 50 kgs (did max of 35 kgs with my arm). The last value of 115 kg was my weight + the 15 kgs and that makes sense to me. Max measured value was 70 of unknown weight.

Interesting that there are two seemingly linear regions. So theoretically possible to have a lot of range with the torque sensor if calibrated correctly.

We also need ADC 10 bits value and not only 8 bits, as it should improve the resolution from the 15 kg / ADC unit to 3.75 kg / ADC unit on the high end scale.

Already switched to 10 bit values in my development version so am glad you feel it will be better. Can confirm it already works much nicer!

 

[buba]

Just noticed I accidentally had the: Allow users to send you private messages: set to 'no'

Sorry to anyone that has tried to send me messages! I genuinely do not know how or when this was set but it is sorted out now.

Some messages are not relevant in the thread so it is good to be able to privately send messages. But almost all questions regarding the firmware, discussions, improvements, feedback and suggestions should be here in the thread so it is shared with the community.

 

[stancecoke]

Returning to the sensor, it has a braking pulse of 0.5 seconds when the shift cable moves.

There's no need for a shift sensor on a system with a torquesensor, as the motor reduces power automatically if you are turning the pedals with lower torque with your legs for shifting, as you do on any normal bike without a motor....

regards
stancecoke

 

[elfnino]

Returning to the sensor, it has a braking pulse of 0.5 seconds when the shift cable moves.

There's no need for a shift sensor on a system with a torquesensor, as the motor reduces power automatically if you are turning the pedals with lower torque with your legs for shifting, as you do on any normal bike without a motor....

regards
stancecoke

I would expect the same however due to the power off delay (about 1s) this doesn't work as good as in theory.

 

[elfnino]

Hello Popo15,

Have you enabled the throttle in the Configuration Menu under the Motor Controller Setup?

https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Features-and-configurations-for-version-0.19.X#7_Motor_Controller_Setup

good morning, if enabled and it does not work, thank you very much.

Have you set the number to ”2”?

- Motor Controller Setup, Submenu 4

Set to ”2” for the Throttle funtion

(Set to ”1” for Motor Temperature function)

(Set to “0” for no optional function)

And can you check the:

- Advanced Technical Data, submenu 0

... to see if the throttle value changes?

Pop15, just to be 100% sure, I re flashed my motor and LCD3 to 0.19.0 release and ran the factory defaults. after setting motor control setup as above I can confirm the throttle works for me perfectly. Like Buba says, first test is to check if you see throttle values change under the advanced technical menu. if you don't there must be a cable fault and the motor is mot getting a throttle signal. you should see the throttle input value even if you have throttle disabled.

When I tested throttle on 0.19.0 it reacts more like on/off switch. I've got either full throttle or nothing.. Could you confirm that you can maintain lower speed by pressing throttle lightly and gradually it increase by pressing it harder?

 

[Popo15]

good afternoon, v. 19 beta 8 the accelerator goes perfect from less to more .. :thumb:

 

[casainho]

Motor power limit Set value after user preference. A tip is to install the motor temperature sensor if a lot of power is frequently needed so as not to overheat the motor. Or set a lower motor power limit. If you setup Street Mode this will effectively be the power limit when going offroad, i.e. when using the bike on non-public roads.

Buba, I just saw now that you changed the quick power limit and moved it to configurations menu.

I think this does not make sense, even the description, because it is not the power that heats the motor but instead the current -- and we have already the max current limit on configurations.

I did implement on 850C as I did on first time, a quick menu to change it on the main screen. Seems this feature was not understood. I use it a lot when I want to manage my small battery pack charge on long mountain bikes rides -- for instance, I know I use about 1000 watt/hour for a 100kms ride of 3000m of positive accumulated climb.

 

[buba]

Returning to the sensor, it has a braking pulse of 0.5 seconds when the shift cable moves.

There's no need for a shift sensor on a system with a torquesensor, as the motor reduces power automatically if you are turning the pedals with lower torque with your legs for shifting, as you do on any normal bike without a motor....

regards
stancecoke

I would expect the same however due to the power off delay (about 1s) this doesn't work as good as in theory.

Just wanted to add that the power off delay will be considerably reduced in the coming 0.20.0!

 

[buba]

Motor power limit Set value after user preference. A tip is to install the motor temperature sensor if a lot of power is frequently needed so as not to overheat the motor. Or set a lower motor power limit. If you setup Street Mode this will effectively be the power limit when going offroad, i.e. when using the bike on non-public roads.

Buba, I just saw now that you changed the quick power limit and moved it to configurations menu.

I think this does not make sense, even the description, because it is not the power that heats the motor but instead the current -- and we have already the max current limit on configurations.

I did implement on 850C as I did on first time, a quick menu to change it on the main screen. Seems this feature was not understood. I use it a lot when I want to manage my small battery pack charge on long mountain bikes rides -- for instance, I know I use about 1000 watt/hour for a 100kms ride of 3000m of positive accumulated climb.

I understand why you want to keep it and what it adds to the experience. But the "quick-set-power-limit-menu" is still there just as you originally implemented it and even I use it now with the improved button logic! Mostly for development reasons but as you mentioned there are a lot of different benefits with the quick-set-power-limit-menu.

I just added the power limit in the configuration menu so that users have somewhere to set the power limit if they have disabled the "quick-set-power-limit-menu".

I think this does not make sense, even the description, because it is not the power that heats the motor but instead the current -- and we have already the max current limit on configurations.

You are correct but as the power is a product of voltage and current and the voltage is somewhat constant compared to the current it is safe to explain that more power will equal more heat. In other words, I do not think it does not make sense but if you feel we need to explain this more I am not against anything. Just do not know if it is necessary.

 

[fi7ippo]

Returning to the sensor, it has a braking pulse of 0.5 seconds when the shift cable moves.

There's no need for a shift sensor on a system with a torquesensor, as the motor reduces power automatically if you are turning the pedals with lower torque with your legs for shifting, as you do on any normal bike without a motor....

regards
stancecoke

I would expect the same however due to the power off delay (about 1s) this doesn't work as good as in theory.

Just wanted to add that the power off delay will be considerably reduced in the coming 0.20.0!

Hi Buba, I'll hope you consider to set a "minimum brake activation time" that could be fixed at 1-1.5, enough for any shift sensors if there is no time for a configurable parameter!

For stancecoke, in my opinion yes and no: in the sense, it is true we do not need the gear sensor having the torque sensor, but the brake cut (gear sensor) is immediate and the gear is changed in a moment, if also lighten the pressure on the pedals, the delay is much greater.
I tried turning it off after more than a year of using it, and I missed it!

 

[mctubster]

You are correct but as the power is a product of voltage and current and the voltage is somewhat constant compared to the current it is safe to explain that more power will equal more heat. In other words, I do not think it does not make sense but if you feel we need to explain this more I am not against anything. Just do not know if it is necessary.

For a non technical person I believe power (ie Watts) is simpler to understand. Yes heating is related to current, but as buba suggested it is close enough to 1:1 to power (as the voltage is constant)

This also relates better to battery capacity in Watt hours.

 

[buba]

There's no need for a shift sensor on a system with a torquesensor, as the motor reduces power automatically if you are turning the pedals with lower torque with your legs for shifting, as you do on any normal bike without a motor....

regards
stancecoke

I would expect the same however due to the power off delay (about 1s) this doesn't work as good as in theory.

Just wanted to add that the power off delay will be considerably reduced in the coming 0.20.0!

Hi Buba, I'll hope you consider to set a "minimum brake activation time" that could be fixed at 1-1.5, enough for any shift sensors if there is no time for a configurable parameter!

Hi fi7ippo,

I have always felt that the gear changes are taking forever and I always need to be careful when shifting with the TSDZ2. This applies to the original and the open source firmware. But in the development version I am running there have been a lot of improvements that could help with this issue:

1. The resolution of torque, current control and overall system has increased so much that it works more like one would expect. When you apply small amounts of torque it only assists a very small amount. So you could almost shift when the TSDZ2 is engaged!

2. The Cadence Sensor - Standard mode of operation. This will work out-of-the-box but with a higher resolution and with more advanced code. No user setup required and will hopefully be much more responsive so it helps to power off and on the assist so users can shift faster. It is dynamic so depending on wheel speed it will adjust the response time.

3. The Cadence Sensor - Extreme mode. This is what I was so curios to develop and it works amazingly good. It effectively increases the resolution and response time by a factor of two! Together with the same dynamic code in the standard mode of operation it is even better. I am so proud of this and will try to make a thread update where I explain how it works.

If you want to use this mode it needs to be setup as every cadence sensor is slightly different. I have however made it so users only need to set one single value (!) and it will work out the rest! This enables very fast power on and off transitions so shifts can be executed in no time at all.

---------------------------------

When we have the 0.20.0 out for testing and the community feels we need to improve things even more I am happy to help in any way!

 

[casainho]

You are correct but as the power is a product of voltage and current and the voltage is somewhat constant compared to the current it is safe to explain that more power will equal more heat. In other words, I do not think it does not make sense but if you feel we need to explain this more I am not against anything. Just do not know if it is necessary.

For a non technical person I believe power (ie Watts) is simpler to understand. Yes heating is related to current, but as buba suggested it is close enough to 1:1 to power (as the voltage is constant)

This also relates better to battery capacity in Watt hours.

On the other hand, one of the most asked questions are what motor voltage should I buy and/or battery voltage combination. I think is important for users to understand that is current that heats the motor so they can choose the right voltage.

 

[casainho]

If you want to use this mode it needs to be setup as every cadence sensor is slightly different. I have however made it so users only need to set one single value (!) and it will work out the rest! This enables very fast power on and off transitions so shifts can be executed in no time at all.

I was looking at the new code you did for having the double resolution of cadence and I wonder if it is really necessary as it means another configuration for user.

I expect to be an issue that delay of 1 second. Were you able to debug it and find the reason why it happens? Because I expect no more than 0.2 seconds of delay and that would be neglegible.

 

[mctubster]

I have always felt that the gear changes are taking forever and I always need to be careful when shifting with the TSDZ2. This applies to the original and the open source firmware. But in the development version I am running there have been a lot of improvements that could help with this issue:

1. The resolution of torque, current control and overall system has increased so much that it works more like one would expect. When you apply small amounts of torque it only assists a very small amount. So you could almost shift when the TSDZ2 is engaged!

2. The Cadence Sensor - Standard mode of operation. This will work Plug-and-Play with the same resolution as before but with more advanced code. No user setup required and will hopefully be much more responsive so it helps to power off and on the assist so users can shift faster. It is dynamic so depending on wheel speed it will adjust the response time.

3. The Cadence Sensor - Extreme mode. This is what I was so curios to develop and it works amazingly good. It effectively increases the resolution and response time by a factor of two! Together with the same dynamic code in the standard mode of operation it is even better. I am so proud of this and will try to make a thread update where I explain how it works.

If you want to use this mode it needs to be setup as every cadence sensor is slightly different. I have however made it so users only need to set one single value (!) and it will work out the rest! This enables very fast power on and off transitions so shifts can be executed in no time at all.

---------------------------------

When we have the 0.20.0 out for testing and the community feels we need to improve things even more I am happy to help in any way!

I am very excited about these upcoming changes. The boost function and big delays in stop start being removed and improved will go a long way. Also getting more out of the torque sensor is very important, eg at high levels of assist the system just becames a pedelec, with no real responsiveness.

I wonder if we can get to the point where there is no assist level selection - I suspect speed / air resistance would have to be worked into the equation. That way if the rider is inputting high torque at a low speed we can assume the power is going into accelerating or climbing vs higher speeds at steady state with lower torque ... maybe the assist becomes a target speed for steady state rather than a blunt multiplier.

 

[buba]

If you want to use this mode it needs to be setup as every cadence sensor is slightly different. I have however made it so users only need to set one single value (!) and it will work out the rest! This enables very fast power on and off transitions so shifts can be executed in no time at all.

I was looking at the new code you did for having the double resolution of cadence and I wonder if it is really necessary as it means another configuration for user.

I expect to be an issue that delay of 1 second. Were you able to debug it and find the reason why it happens? Because I expect no more than 0.2 seconds of delay and that would be neglegible.

Will be setup in a way so that users have two options. Use the standard code that is much more improved and will work better. And if users wish they can calibrate the cadence sensor and get even more resolution. Best of two worlds!

Well the previous code measured a value of 10 RPM. This would be around 0.3 seconds. This is checked in a 100 ms loop so worst case would be 0.3 + 0.1 seconds. But then there is the motor ramp down of around 0.2 seconds medium power. So all in all around 0.6 seconds if the user immediately stops the pedals and there is no more transition measured. If there is even slightest pedal movement at the right time and position, which happens very often, it would add at least another 0.3 seconds. So we are up to 0.9 seconds.

Have verified this extensively and tested a lot. Am very sure of the things I have done and will try to post an update tomorrow.

I also want to add that the better experience that you get from even a small difference of 0.2 seconds is like night and day, imagine a difference of 0.8 seconds!

 

[casainho]

I wonder if we can get to the point where there is no assist level selection - I suspect speed / air resistance would have to be worked into the equation. That way if the rider is inputting high torque at a low speed we can assume the power is going into accelerating or climbing vs higher speeds at steady state with lower torque ... maybe the assist becomes a target speed for steady state rather than a blunt multiplier.

We know that current not calibrated torque sensors + our current implementation of firmware, the system can only measure up to max of maybe 15 kgs while with a calibrated torque sensor + a feature on firmware to use the full range of the torque sensor, the system should be able to measure up to 110 kgs (which is higher value than my own weight).

The assist multiplier will still be needed as users differs much. For instance, my son of 9 years old me and my girlfriend, we all have very different power in our legs as also body weight.

 

[buba]

When we have the 0.20.0 out for testing and the community feels we need to improve things even more I am happy to help in any way!

I am very excited about these upcoming changes. The boost function and big delays in stop start being removed and improved will go a long way. Also getting more out of the torque sensor is very important, eg at high levels of assist the system just becames a pedelec, with no real responsiveness.

When using the calibrated cadence sensor the power is almost instant. The stops are also very quick! Current control is noticeably nicer and more responsive. Paired with four times the resolution of the torque sensor there is much more control!

I wonder if we can get to the point where there is no assist level selection - I suspect speed / air resistance would have to be worked into the equation. That way if the rider is inputting high torque at a low speed we can assume the power is going into accelerating or climbing vs higher speeds at steady state with lower torque ... maybe the assist becomes a target speed for steady state rather than a blunt multiplier.

Good points! We will see :wink:

EDIT: Casainho just mentioned why assist level multipliers are good to have.

 

[casainho]

Will be setup in a way so that users have two options. Use the standard code that is much more improved and will work better. And if users wish they can calibrate the cadence sensor and get even more resolution. Best of two worlds!

I don't think it is best of two worlds because user will need anyway to understand/process all the information for this new configuration. And our firmware has already so many configurations that seems a less positive point when compared to original firmware.

Well the previous code measured a value of 10 RPM. This would be around 0.3 seconds. This is checked in a 100 ms loop so worst case would be 0.3 + 0.1 seconds. But then there is the motor ramp down of around 0.2 seconds medium power. So all in all around 0.6 seconds if the user immediately stops the pedals and there is no more transition measured. If there is even slightest pedal movement at the right time and position, which happens very often, it would add at least another 0.3 seconds. So we are up to 0.9 seconds.

Have verified this extensively and tested a lot. Am very sure of the things I have done and will try to post an update tomorrow.

I also want to add that the better experience that you get from even a small difference of 0.2 seconds is like night and day, imagine a difference of 0.8 seconds!

Did you verified that torque sensor signal is slower than the cadence sensor to measure that 10 RPM?

So, why not increase the min cadence to 20 RPM?
And then also reduce the motor ramp down?

And for your math, doubling the cadence resolution reduces only 0.15ms.

 

[buba]

Will be setup in a way so that users have two options. Use the standard code that is much more improved and will work better. And if users wish they can calibrate the cadence sensor and get even more resolution. Best of two worlds!

I don't think it is best of two worlds because user will need anyway to understand/process all the information for this new configuration. And our firmware has already so many configurations that seems a less positive point when compared to original firmware.

Okay, sad to hear you feel it will add complexity for the user. This is the exact reason I wanted to have it default to a setup where the user does not have to calibrate anything if they do not wish to. But if the user wishes to change just one value you can get instant startups and instant power downs with a nice experience throughout.

I compare it to the calibration of the torque sensor. I want alternatives where users do not need to calibrate if they do not want to. That is why I like Torque Assist. Users can use the TSDZ2 in the same way it is used in the original firmware. And if you want an even better experience you can calibrate the torque sensor. Also the best of both worlds.

Also here is some text I wanted to add in an update tomorrow:

Just one last thing: I can make the calibration process automatic. Just press a button and the cadence sensor will automatically calculate the best values. But I have already put down so much time and there are still more things to do. I already feel bad for taking so long as it is and I do not want to make things even more complicated. If it is okay with the community we can maybe save that for the future as I think the calibrations process is very simple and will work fine for the users that wish to calibrate. I think it is more important to have a beta out for testing.

But I think that you would rather I remove the entire "Cadence Double Resolution" and save that particular thing for the future. That would be totally fine with me and that is something I can do tomorrow. The cadence sensor code is still improved and we can add the "double resolution" later.

Did you verified that torque sensor signal is slower than the cadence sensor to measure that 10 RPM?

It is slower than my cadence sensor code, yes.

So, why not increase the min cadence to 20 RPM?

Increasing that value will make the startups slower. It is connected. You could make it so it starts with only torque applied but that is a workaround and not how the original firmware does it and they have it working very good at startups. Also it is very unsafe and adds another configuration to the user: startup without pedal assist.

And then also reduce the motor ramp down?

The motor ramp down is good to have around 20 as this does not induce any mechanical spikes in the system when under load. But it could be set to a slightly lower value. (Best would be to have a PI controller for the motor duty cycle but I think you wish to keep everything simple and not implement something much more complicated without too much gain, and I agree.)

I also want to add that the better experience that you get from even a small difference of 0.2 seconds is like night and day, imagine a difference of 0.8 seconds!

And for your math, doubling the cadence resolution reduces only 0.15ms.

Not sure if you meant this but the values of 0.2 and 0.8 is not something I calculated. Just wanted to say that 0.2 seconds is a big difference when riding the bike so imagine an even bigger value such as 0.8 seconds if there is a worst case scenario at slow speeds and >1 s.

 

[buba]

Quick update to the community:

Will add Casainho's branch where the torque is measured and approximated every pedal revolution, then my local eMTB branch and then there are the suggestions from users I will implement the next couple of days. Also need to update the wiki.

We will have a 0.20.0 beta out this coming week!

 

[casainho]

But I think that you would rather I remove the entire "Cadence Double Resolution" and save that particular thing for the future.

Let's see first how all of this works.

If we are talking about shutoff, why not start using different cadence values, one for startup and other for shutoff?

 

[elfnino]

But I think that you would rather I remove the entire "Cadence Double Resolution" and save that particular thing for the future.

Let's see first how all of this works.

If we are talking about shutoff, why not start using different cadence values, one for startup and other for shutoff?

In my humble opinion minimizing any startup/shutoff delay should be always one of the highest priority even if it would require more complex configuration or calibration. It is more natural, it improves a lot user experience especially in more technical bike riding when higher delay can disturb rider balance
Anyway you are doing the great job! and I trust you that you will find the best compromise to mitigate the delay :wink: