stancecoke wrote: ↑Dec 03 2019 9:35am
Wow, OK. I just looked at the code, I still don't understand, why casainho doesn't use a PI control for the currents.
And the whole code seems to be rewritten in the recent master repo of casainho...
It is obvious, that the battery current target is not reset in each loop run in the ebike_app.c. But this shouldn't matter, as the phase current is always higher than the battery current.
Thanks for the tips, I tried them out today with mixed results.
Unfortunately I don't really understand the motor control stuff but I might have narrowed down the overall problem to something to do with the cadence. I sent an error code to the display whenever ui8_pas_cadence_rpm was zero and it didn't display until the end of the motor overrun. It seems the higher the cadence, the longer it dwells for. So because of that then your first suggestion at line 685 didn't work. I'd also tried similar changes before and couldn't get any improvement. Do you think would reducing the PWM duty cycle ramp down value would help, is that what it's meant for? I have previously tried reducing that but it didn't appear to help.
Your second suggestion seemed to help but caused hard cut-offs and clicking from the motor. Is there any way to smooth that? I'll need to test it again to be sure 100% sure it was stopping the overrun, I've been experimenting so much this afternoon I've confused myself as well as worn circles into the lawn.
I'd like to do the same error code display with ui16_pas_pwm_cycles_ticks to see how responsive it is.
Interestingly, when operating the brakes the cut-off doesn't seem so bad. I played around adding this to ebike_app.c (around line 334), after ENABLE_BRAKE_SENSOR.
Code: Select all
if (ui8_torque_sensor < TORQUE_SENSOR_THRESHOLD_LOW)
{
ui8_brake_is_set = 1;
else
{
ui8_brake_is_set = 0;
}
I found it was too sensitive and cut in and out a lot, perhaps reducing the threshold could help but I imagine this varies for every motor. It was impossible to pedal lightly and receive minimal constant assist.
Finally, I see in torque_sensor_read() in ebike_app.c there is a check for moving without pedalling to filter the ui8_torque_sensor to zero, but since it also tests for (ui8_pas_cadence_rpm == 0) I suspect it's going to suffer from the overrun lag too.
Code: Select all
// next state machine is used to filter out the torque sensor signal
// when user is resting on the pedals
switch(ui8_tstr_state_machine)
{
// ebike is stopped
case STATE_NO_PEDALLING:
if((ui8_torque_sensor_raw > 0)&&
(ui16_wheel_speed_x10))
{
ui8_tstr_state_machine = STATE_PEDALLING;
}
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;
}
}
. Thanks again to Mbrusa for his work
, the user from here Ashambro has also tested it and displays:
, who can help develop these displays?
)