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

[jbalat]

Help to debug lag issue
See about this issue here: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/issues/9

For the ones that are interested in helping solve this issue, please help by looking at the following values on LCD3:
9: Advanced technical data
submenu number configuration name description
3 Pedal torque sensor
4 Pedal cadence
5 Pedal human power
6 PWM duty cycle

The idea is to see how that values changes when the issue happen, like stop pedaling and then pedal again and look at that values. How do they change when the issue happen?

Ok so i stopped and started many times on my way in to work today. Due to display historesis I am unable to give you EXACT data but this was my perception.
Even after you stop pedalling the cadence drop slowly to zero, not immediately, if you peddle before it gets too low then there is no lag, if you wait too long or let it get to zero then lag exists.
Taking off from zero has less lag than when you start pedalling again while rolling
All the stats like torque sensor, cadence, human power, pwm and even ERPS motor speed all appear to work as they should however it appears you dont get any boost until ERPS is about 200.
When taking off from rest the ERPS 200 is achieved quicker ?
Perhaps when energising the motor we just add 200 offset ?

This brings me to my next idea.
Can we use a minimum ERPS to prevent backlash in the gears and reduce noise. The issue is to try and calculate the minimum ERPS based on your cadence so as to make sure gears are always tight but not too much to overheat the motor ore make the bike move. Of course when the wheel speed is zero then this should be turned off

 

[casainho]

Help to debug lag issue
See about this issue here: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/issues/9

For the ones that are interested in helping solve this issue, please help by looking at the following values on LCD3:
9: Advanced technical data
submenu number configuration name description
3 Pedal torque sensor
4 Pedal cadence
5 Pedal human power
6 PWM duty cycle

The idea is to see how that values changes when the issue happen, like stop pedaling and then pedal again and look at that values. How do they change when the issue happen?

Ok so i stopped and started many times on my way in to work today. Due to display historesis I am unable to give you EXACT data but this was my perception.
Even after you stop pedalling the cadence drop slowly to zero, not immediately, if you peddle before it gets too low then there is no lag, if you wait too long or let it get to zero then lag exists.
Taking off from zero has less lag than when you start pedalling again while rolling
All the stats like torque sensor, cadence, human power, pwm and even ERPS motor speed all appear to work as they should however it appears you dont get any boost until ERPS is about 200.
When taking off from rest the ERPS 200 is achieved quicker ?
Perhaps when energising the motor we just add 200 offset ?

This brings me to my next idea.
Can we use a minimum ERPS to prevent backlash in the gears and reduce noise. The issue is to try and calculate the minimum ERPS based on your cadence so as to make sure gears are always tight but not too much to overheat the motor ore make the bike move. Of course when the wheel speed is zero then this should be turned off

I got the same feeling as you on my tests.

First, looking at firmware I don´t see a reason for a delay (except the one I will mention). On hardware, there is a delay for the torque sensor signal, that seems to be low pass filtered quite a bit (compared to other torque sensor I worked with) - this delays happen when increasing or decreasing (when start pedaling AND when stop pedaling).

1. I also feel that when I start from 0 motor speed/wheel speed/ebike stopped, I feel the torque without delay BUT when the ebike is moving already, specially at higher speeds, and I did previous stop to pedal (electric motor stopped --> PWM duty-cycle = 0) and start pedaling again, I feel a delay to have motor torque!

What I think is happening is that motor takes time (delay) to increase from 0 speed to final speed that will equal to the rider actual cadence/wheel speed. The higher the ebike speed on 1., the longer the time (delay) the electric motor will take to achieve the final speed.

Can we increase the motor speed acceleration to try reduce that delay?
I think so, but I would go with care having the risk to burn the motor controller if not worst. On motor controller firmware, file config.h, we have this defines:

// *************************************************************************** //
// MOTOR CONTROLLER

// Choose PWM ramp up/down step (higher value will make the motor acceleration slower)
//
// For a 24V battery, 25 for ramp up seems ok. For an higher voltage battery, this values should be higher
#define PWM_DUTY_CYCLE_RAMP_UP_INVERSE_STEP 75
#define PWM_DUTY_CYCLE_RAMP_DOWN_INVERSE_STEP 25

What they mean? mean that wen we set motor_set_pwm_duty_cycle_target () our target duty-cycle, the real value duty-cycle will increase with a ramp at steps of that defines, where each steps takes the time of 64 micro seconds. A step value of 75 means 75*64us = 4.8 mili seconds. Let´s say the ebike speed/pedal cadence is a at a speed that duty-cycle should ram up to 200 for the motor to make torque. The ramp time is: 200 * 4.8ms = 0.96 seconds.

The brave ones can try to reduce the value of #define PWM_DUTY_CYCLE_RAMP_UP_INVERSE_STEP 75 but be warned that faster motor acceleration/faster motor energy increase/faster motor torque increase may be harder for the system (motor controller, gears, battery, etc) and we don´t know what can go wrong!!

 

[mgtroyas]

What you suggest seems similar to how the Rally car motor works: when you release the throttle the motor keeps the revs for some time, so when you press throttle again you don't need to wait for the motor going revs up again. That's why sometimes they show flame on the exhaust: motor at high rpm without load, the injected gas exits unused.

 

[jbalat]

It makes perfect sense that the faster you go the longer it will take for the motor to catch up with the cadence.
Does this value need to be a constant or can we ramp up quicker when based on the cadence and/or wheel speed ?
I’m happy to try it this way rather than just changing the constant...

The other way is to just go with my previous suggestion which is while the wheel speed >0 the motor should always be running to keep up the slack in the gears, it does not need to produce much power, maybe only 20w, this way it will already be at speed so there will be no delay once you apply torque apparently this is done on Bafang ??

 

[casainho]

It makes perfect sense that the faster you go the longer it will take for the motor to catch up with the cadence.
Does this value need to be a constant or can we ramp up quicker when based on the cadence and/or wheel speed ?
I’m happy to try it this way rather than just changing the constant...

The other way is to just go with my previous suggestion which is while the wheel speed >0 the motor should always be running to keep up the slack in the gears, it does not need to produce much power, maybe only 20w, this way it will already be at speed so there will be no delay once you apply torque apparently this is done on Bafang ??

I think all is possible to do but will need a lot of development time and testing. I do not have that time, maybe we should move all this information to the issue tracker and maybe someone later will take care of this.

Also I think the very first thing to do is to play with PWM_DUTY_CYCLE_RAMP_UP_INVERSE_STEP value. I put that values as a guess, I don´t have a clue if they can be lower to reduce the lag.

 

[jbalat]

Maybe EC and vscope can help
In the meantime I will try reducing this value of 75 to maybe 25 and see what happens

 

[maximusdm]

I know that the stock soft connects the power instantly.
Can we decompile the hex and check what is it doing the cases mentioned by you? Perhaps there is an easy way.

 

[Rafe]

I've had to put the metal gear on because I think the throttle which now has no fine control instantly ramps up full power which is too much for the blue gear (using as walk assist on cliff steps) but it may also have been caused by the power boost cutting in after the lag. As a result with the metal gear fitted the backlash in the gearing that jbalat talks about at low torque is very easy to hear as the motor constantly cycles on and off load.


By the way the power boost cutting in after the lag was quite nasty for me, both times starting an ascent after a descent I was in the wrong gear for manual climbing alone so went side ways across the slope to change down when suddenly the motor cut in on boost sending the bike off the track, not a nice experience when there is a long drop not far away.

 

[casainho]

(...) I think the throttle which now has no fine control instantly ramps up full power which is too much for the blue gear (...)

1. The motor ramps up with PWM_DUTY_CYCLE_RAMP_UP_INVERSE_STEP value, for both throttle or torque sensor as input signals.

2. The torque sensor signal seems to be a bit low to ramp up due to a low pass filter (delay) on hardware motor controller.

3. Seems the throttle signal has not a low pass filter (delay) on hardware and so this signal should be very fast to ramp up. We can add a low pass filter/delay on the firmware, if needed (since I do not use throttle nor I do have experience with throttles, I never found this need).

 

[maximusdm]

Today on my way to work and back I started having a nasty issue. After 2-3km of riding in city i get constant short power cut-offs. For 1 sec aprox power drops from 2-300w to 10 w then goes back up. Than after 30-40s I get it again. It is like getting hiccups from the motor.
I checked all diags. The measured torque and cadence and is all good. It just drops dead random.
EPS, PWD duty params are dropping and FOC angle is going to 1 from 3-4.

I did not change anything in soft, even tryed a reset to defaults and the problem persists.

Need some help... bad!

 

[Rafe]

Today on my way to work and back I started having a nasty issue. After 2-3km of riding in city i get constant short power cut-offs. For 1 sec aprox power drops from 2-300w to 10 w then goes back up. Than after 30-40s I get it again. It is like getting hiccups from the motor.
I checked all diags. The measured torque and cadence and is all good. It just drops dead random.
EPS, PWD duty params are dropping and FOC angle is going to 1 from 3-4.

I did not change anything in soft, even tryed a reset to defaults and the problem persists.

Need some help... bad!

I once had something similar and it was just the spoke magnet was loose and moving. When the signal is poor the measured speed can increase considerably and in my case going above the motor cut off road speed, then it all starts over again and so on. Having said that the indicated speed on the display gave the game away once I twigged what was happening.

 

[andrea_104kg]

I am still at version 0.7
I also have a turbo levo and I make comparisons.
the tsdz2 with the new firmware is very similar in behavior to brose, indeed perhaps allows you to make less effort!
I have no lag problems and I use it off-road.
The only problem is that the engine seems to remain under tension even when the pedals are still and sometimes the simple light pressure on the pedals starts the bike forward in a dangerous way. Has something changed since the 0.7 version that introduced the lag?

 

[jbalat]

I am still at version 0.7
I also have a turbo levo and I make comparisons.
the tsdz2 with the new firmware is very similar in behavior to brose, indeed perhaps allows you to make less effort!
I have no lag problems and I use it off-road.
The only problem is that the engine seems to remain under tension even when the pedals are still and sometimes the simple light pressure on the pedals starts the bike forward in a dangerous way. Has something changed since the 0.7 version that introduced the lag?

Menu 6,1 should be zero which is motor assist without peddle rotation. Turn it off unless you are using ebrakes

 

[jbalat]

By the way the power boost cutting in after the lag was quite nasty for me, both times starting an ascent after a descent I was in the wrong gear for manual climbing alone so went side ways across the slope to change down when suddenly the motor cut in on boost sending the bike off the track, not a nice experience when there is a long drop not far away.

I don’t use power boost, try turning it off. Also if you have set your power levels too high it can also jerk forwards like this, turn power down or trim it down using the top and middle buttons.

 

[jbalat]

I bet you all want to know if this worked ??

#define PWM_DUTY_CYCLE_RAMP_UP_INVERSE_STEP 75

Haha well it did !!!
I changed the value to 25
Lag is greatly reduced (in fact almost zero on take off) and as a bonus the bike is more responsive !!

 

[casainho]

I bet you all want to know if this worked ??

#define PWM_DUTY_CYCLE_RAMP_UP_INVERSE_STEP 75

Haha well it did !!!
I changed the value to 25
Lag is greatly reduced (in fact almost zero on take off) and as a bonus the bike is more responsive !!

And I was thinking more about the idea of keeping gears engaged, by using a min current value while ebike wheel is moving.

I think just before the speed and temperature limiter, we can impose a min current value if it is less than that min value. The min value can be something like 2 ADC units that is 0.3 amps. And we would impose this min value after checking that wheel speed > 5km/h --- all this code should be quick to do...

 

[jbalat]

Awesome, finally we are making some improvements to the motor !!!

 

[EndlessCadence]

Awesome, finally we are making some improvements to the motor !!!

I have the feeling that the lag problem didn't exist in older versions of the firmware (e.g. 0.3 -> 0.7?). But I can't find why. I looked through these old versions but I can't find something vital that has been changed and is causing this issue.

PWM_DUTY_CYCLE_RAMP_UP_INVERSE_STEP always had value 75.

For me personally, the lag problem is very annoying in day to day use of the bike.

The other thing I noticed is that while the code is more organized and release scripts etc are added, we've introduced a lot of complexity in the code in more recent versions. Also, some potentially dangerous functionality wasn't removed. I'm questioning how many users are using these features anyways.

I'm personally thinking of going back to a leaner version with only the required features for a nice and reliable bike with code that's very easy to maintain. This includes only 5 assist levels (multipliers). Redesigned offroad mode. We already have reported issues for most of this, see https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/issues. What do you think?

Meanwhile, I have the STM8 (processor in controller and display) ROM bootloader working, this means I'm able to update the firmware without any programmer. This currently still requires my computer.
I'm also experimenting with Bluetooth and am able to update the firmware of the Bluetooth module wirelessly. Hopefully, this can be combined soon, then we have a bike which can be updated and configured by Bluetooth!
This is why I was a bit silent the last few days

 

[andrea_104kg]

I am still at version 0.7
I also have a turbo levo and I make comparisons.
the tsdz2 with the new firmware is very similar in behavior to brose, indeed perhaps allows you to make less effort!
I have no lag problems and I use it off-road.
The only problem is that the engine seems to remain under tension even when the pedals are still and sometimes the simple light pressure on the pedals starts the bike forward in a dangerous way. Has something changed since the 0.7 version that introduced the lag?

Menu 6,1 should be zero which is motor assist without peddle rotation. Turn it off unless you are using ebrakes

i don't use boost and menu 6.q it's 0 but the problem re ma in..

 

[andrea_104kg]

Awesome, finally we are making some improvements to the motor !!!

I have the feeling that the lag problem didn't exist in older versions of the firmware (e.g. 0.3 -> 0.7?). But I can't find why. I looked through these old versions but I can't find something vital that has been changed and is causing this issue.

PWM_DUTY_CYCLE_RAMP_UP_INVERSE_STEP always had value 75.

For me personally, the lag problem is very annoying in day to day use of the bike.

The other thing I noticed is that while the code is more organized and release scripts etc are added, we've introduced a lot of complexity in the code in more recent versions. Also, some potentially dangerous functionality wasn't removed. I'm questioning how many users are using these features anyways.

I'm personally thinking of going back to a leaner version with only the required features for a nice and reliable bike with code that's very easy to maintain. This includes only 5 assist levels (multipliers). Redesigned offroad mode. We already have reported issues for most of this, see https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/issues. What do you think?

Meanwhile, I have the STM8 (processor in controller and display) ROM bootloader working, this means I'm able to update the firmware without any programmer. This currently still requires my computer.
I'm also experimenting with Bluetooth and am able to update the firmware of the Bluetooth module wirelessly. Hopefully, this can be combined soon, then we have a bike which can be updated and configured by Bluetooth!
This is why I was a bit silent the last few days

i think to do a fully BASIC versione whitout bug it's a good idea..
I don't understand, whit bluetooth you are capable to re-writing controller and LCD firmware whitout computer?

 

[Eremit]

Just flashed the 14.3 and something happens to the Offroad mode. Whatever I write in 7.1, it's activated on startup.

And another thought on offroad mode: 0.0 has a limit (default 50km/h) and there is another limit in 7.2.
With activated option offroad mode, this two should be switched, so that 0.0 has the legal and, with offroad option disabled, absolute limit, . And 7.2 should be the value of the offroad absolute limit (default 50km/h).

Seems more logical to me.

Anyway the Switched on offroad mode really need a fix. It's to unsafe for the city. You might forget that it's unleashed :wink:

 

[EndlessCadence]

Just flashed the 14.3 and something happens to the Offroad mode. Whatever I write in 7.1, it's activated on startup.

.....

Anyway the Switched on offroad mode really need a fix. It's to unsafe for the city. You might forget that it's unleashed :wink:

How do you conclude that offroad mode is activated? You should see a blinking assist symbol, not so easy to forget

 

[Eremit]

Just flashed the 14.3 and something happens to the Offroad mode. Whatever I write in 7.1, it's activated on startup.

.....

Anyway the Switched on offroad mode really need a fix. It's to unsafe for the city. You might forget that it's unleashed :wink:

How do you conclude that offroad mode is activated? You should see a blinking assist symbol, not so easy to forget

Just flashed the 14.3 and something happens to the Offroad mode. Whatever I write in 7.1, it's activated on startup.

.....

Anyway the Switched on offroad mode really need a fix. It's to unsafe for the city. You might forget that it's unleashed :wink:

How do you conclude that offroad mode is activated? You should see a blinking assist symbol, not so easy to forget

Believe it or not, but I don't have the eyes glued to the display. It took me a lot of days to realize, that Odometer is still zero after all that rides...
Just want to have it like it was on 0.12. Tried to install that cygwin/gcc/eclipse stuff, but right now, I'm stuck in "no gcc sdcc g++ in Path", where I'm sure that at least g++ and gcc are in the Path...

Or put it different: Offroad Mode is the legal - on street - mode. When I go off street, it's my explicit decision. If I'm on the street, I want a PowerUp to be legal from the first second until I decide otherwise.

 

[jbalat]

And I was thinking more about the idea of keeping gears engaged, by using a min current value while ebike wheel is moving.

I think just before the speed and temperature limiter, we can impose a min current value if it is less than that min value. The min value can be something like 2 ADC units that is 0.3 amps. And we would impose this min value after checking that wheel speed > 5km/h --- all this code should be quick to do...

Any luck with this casainho ?
I'm enjoying the new setting with less lag. No side effects from what I can see after riding to work and back.

 

[maximusdm]

I managed to fix my engine interrupts issue. I did a reflash of the LCD and does not happen. So no hardware issue.
However i noticed other problems visible also with reset to defaults:
- now odo meter is always reset after power off
- battery cut off voltage is 0, i had to put it back to 54.2v
- number of assist levels is 0 ...set it back to 5.

I think there is a problem with the EPROM in the soft. I gets dirty and cannot be fixed reset to defaults at least not complete.

I also did a write of 0 in the DATA MEMORY tab from address XXX to YYY before writing the soft. Is this the standard way to clean the memory so we avoid funny behavior?