Motor ¨startup¨ delay/lag at medium/high pedal cadence

[v-s-c-o-p-e]

I checked the code and i think i found the problem for the lag.
Reproduce ->
pedalling -> then stop pedalling -> then pedalling again -> lag.... -> motor kicks in

i checked the code and i think i found the problem in: torque_sensor_read

if STATE_NO_PEDALLING and torque sensor > 0 the wheelspeed must also be checked,
so i should not do the 2 seconds STATE_STARTUP_PEDALLING when allready at speed.
when wheelspeed > X kmh instant change to STATE_PEDALLING
2 seconds lag is really too much.

hope you understand what i mean.

i marked the code changes in bold below

void torque_sensor_read (void)
{
// map value from 0 up to 255
// map value from 0 up to 255
ui8_torque_sensor_raw = (uint8_t) (map (
UI8_ADC_TORQUE_SENSOR,
(uint8_t) ui8_adc_torque_sensor_min_value,
(uint8_t) ui8_adc_torque_sensor_max_value,
(uint8_t) 0,
(uint8_t) 255));

switch (ui8_tstr_state_machine)
{
// ebike is stopped, wait for throttle signal
case STATE_NO_PEDALLING:
if ((ui8_torque_sensor_raw > 0) &&
(!brake_is_set()))
{
if(ui16_wheel_speed_x10 > 10){
ui8_tstr_state_machine = STATE_PEDALLING;
} else {
ui8_tstr_state_machine = STATE_STARTUP_PEDALLING;
}
break;

// now count 2 seconds
case STATE_STARTUP_PEDALLING:
if (ui8_rtst_counter++ > 20) // 2 seconds
{
  ui8_rtst_counter = 0;
  ui8_tstr_state_machine = STATE_PEDALLING;
}

// ebike is not moving, let's return to begin
if (ui16_wheel_speed_x10 == 0)
{
  ui8_rtst_counter = 0;
  ui8_tstr_state_machine = 0;
}
break;

// wait on this state and reset when ebike stops
case STATE_PEDALLING:
if ((ui16_wheel_speed_x10 == 0) && (ui8_torque_sensor_raw == 0))
{
  ui8_tstr_state_machine = STATE_NO_PEDALLING;
}
break;

default:
break;

}

// bike is moving but user doesn't pedal, disable torque sensor signal because user can be resting the feet on the pedals
if ((ui8_tstr_state_machine == STATE_PEDALLING) && (ui8_pas_cadence_rpm == 0))
{
ui8_torque_sensor = 0;
}
else
{
ui8_torque_sensor = ui8_torque_sensor_raw;
}
}

[v-s-c-o-p-e]

checked the code again maybe the problem is in this piece of code
how many rotations does it need to calc the _ui8_pas_cadence_rpm ?
maybe thats why it lags..

_ui8_pas_cadence_rpm = ui8_pas_cadence_rpm;
if (configuration_variables.ui8_motor_assistance_startup_without_pedal_rotation)
{
if (ui8_pas_cadence_rpm < 10) { _ui8_pas_cadence_rpm = 10; }
}
else
{
if(ui16_wheel_speed_x10 < 10){
if (ui8_pas_cadence_rpm < 10) { _ui8_pas_cadence_rpm = 0; }
}
}

[ncvanleeuwen]

Thanks! Maybe it's best if you start with a clear description of the problem first. This way it will be easier to fix and verify if it's fixed too. I'll look into this when the changes from the improve_power branch are merged into master.

[jbalat]

It must be the 2 second lag. As I mentioned in the post there is hardly any lag when you begin to peddle from stop which means the cadence measurement is almost instant.
Need to ask why this lag is in the code at all, is it safety ? Can we remove it or does it need to stay there and be reduced ?

[ncvanleeuwen]

Thanks. I think we can remove this. Measurement isn't the problem and it's plenty fast enough. From a safety point of view I think something like this is only needed from a stop. The bug could be related to the boost feature.

[casainho]

Since I remember, that lag/delay works as a hysteresis and I think is needed (that is why I implemented like that). If we stop pedaling, makes sense that at least we stop for at least a minimum amount of time - if 2 seconds is to much, I think we can reduce maybe for 1 second.

See here about hysteresis:

• https://en.wikipedia.org/wiki/Hysteresis
• https://blog.wika.com/knowhow/switching-function-hysteresis-pressure-switch/

[v-s-c-o-p-e]

casainho. i will try to compile the code by myself and see what different STATE_STARTUP_PEDALLING timings will change and report back. however i cant find a location where can i download the 0.12 src files...
cheers
vscope

[v-s-c-o-p-e]

i reviewed the torque_sensor_read() again.
i dont understand what STATE_STARTUP_PEDALLING does except that it is dangerous cause if doesnt set the torque sensor to 0 if cadence == 0

[jbalat]

// now count 2 seconds
case STATE_STARTUP_PEDALLING:
if (ui8_rtst_counter++ > 20) // 2 seconds

I'm worried about removing lines of code without e-brakes.
But maybe we can reduce the 2 seconds to 0.2 seconds.
While you are riding stop pedaling for 3 seconds and start pedaling again, there is a delay.

EDIT 16/10
Tried reducing this and this has no effect

[v-s-c-o-p-e]

the problem is that torque_sensor_read will return
ui8_torque_sensor = ui8_torque_sensor_raw; (see end of function)
in state STATE_STARTUP_PEDALLING even if cadence = 0
i doenst do anything else.
thats not a security feature but a flaw...

in every state torque sensor is set to ui8_torque_sensor_raw

i think i would make sense to have the security logic in the torque_sensor_read () function and use only ui8_torque_sensor in the ebike_control_motor function.
at the moment its quit a mess...

i did some changes yesterday.
i will try to upload them all

ui8_state_machine is never used for power reasons...
except in uart...

[ncvanleeuwen]

Thanks! I appreciate your help! I agree that it's quite a mess. We should also pass variables to functions instead of having all global variables which can become confusing. See the improve_power branch where I already did some organizing of the code.

[v-s-c-o-p-e]

i would remove all that extra code from torque_sensor_read and cadence read and have one gloabal security function called at the the end of ebike_control_motor before motor_set_pwm_duty_cycle_target . this checks like brake set, speed, cadence checks torque sensor.
if security features are not met. motor power stops -> a new motorstop function is called (resets all values)

at the moment these security checks are all over the place.
brake_is_set is called several times. cadence = 0 several times.
that makes the code only bigger slower unreadable and unpredictable.

if you want i can go over it when 0.14 is released.

[ncvanleeuwen]

Sure! Let's do this together when 0.14 is released which also includes some restructuring.

Keep in mind that we need to test this thoroughly and we should ask beta testers when possible, especially for these kind of security changes.

At this moment I focus on stabilizing and restructuring the firmware instead of new features. There are still quite a few bugs...

[v-s-c-o-p-e]

good plan.

[pawpie]

I'm so excited for this bug to be fixed/minimized. Due to my riding style, it's almost made me switch to the original + LCD3.

[casainho]

casainho wrote: ↑Thu Oct 25, 2018 3:26 am
Help to debug lag issue
See about this issue here: https://github.com/OpenSource-EBike-fir ... e/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?

[casainho]

jbalat wrote: ↑
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]

casainho wrote: ↑

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:
CODE: SELECT ALL

// *************************************************************************** //
// 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!!

[jbalat]

I have been testing the new inverse ramp value of 25 and the lag is now greatly reduced. While this approach works I propose that we can apply a small amount of power at all times (say 20w) while the wheel speed is greater than zero. This will not only prevent lag since the motor will already be at speed when you start pedalling again but it should reduce backlash noise in the gears too.

Whether we can use this to automatically assist the bike for walk mode is something that can also be investigated.

[casainho]

Solved on 0.16.