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

I made a release for the min current feature from my branch for beta testing. This was already code reviewed.
=> 0.14.4.beta1.zip
I also made release for reaching easier the maximum assisted power level, better responsiveness.
=> 0.14.4.beta2.zip
 

Attachments

  • 0.14.4.beta1.zip
    51 KB · Views: 55
  • 0.14.4.beta2.zip
    51.1 KB · Views: 51
EndlessCadence said:
@everyone

We're busy with preparing a few improvements:
  • Cadence low pass filter (LCD3)
  • Improved battery voltage reading and SOC (LCD3)
  • Improved speed reading (especially useful for low speeds / startup)

Next to this I'm implementing and testing walk assist!

Cheers! Thanks for your efforts!
 
EndlessCadence said:
@everyone
We're busy with preparing a few improvements:
  • Cadence low pass filter (LCD3)
  • Improved battery voltage reading and SOC (LCD3)
  • Improved speed reading (especially useful for low speeds / startup)
Next to this I'm implementing and testing walk assist!

Awesome EC :)
 
maximusdm said:
I made a release for the min current feature from my branch for beta testing. This was already code reviewed.
=> 0.14.4.beta1.zip
I also made release for reaching easier the maximum assisted power level, better responsiveness.
=> 0.14.4.beta2.zip
Cool I have copied out the latest ebike_app.c and .h files from both pull requests and will compile and flash in eclipse. That way I don't have to redo all my settings again. I'm not sure what lcd hex I am using ??
 
EndlessCadence said:
@everyone

We're busy with preparing a few improvements:
  • Cadence low pass filter (LCD3)
  • Improved battery voltage reading and SOC (LCD3)
  • Improved speed reading (especially useful for low speeds / startup)

Next to this I'm implementing and testing walk assist!
Tomorrow I will go to mountains with girlfriend and I just flashed both of our ebikes with the code on branch for the walk assist: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/tree/14-walk-assist-mode

I must say it seems to work well on a flat surface. On hills it may take some time to build up the motor current (as seen on LCD3). Although it is setup now 4km/h as walk speed, for hills I still think is to much as I can´t walk at 4km/h there... well, I will discover tomorrow :)
 
casainho said:
Tomorrow I will go to mountains with girlfriend and I just flashed both of our ebikes with the code on branch for the walk assist: https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/tree/14-walk-assist-mode

I must say it seems to work well on a flat surface. On hills it may take some time to build up the motor current (as seen on LCD3). Although it is setup now 4km/h as walk speed, for hills I still think is to much as I can´t walk at 4km/h there... well, I will discover tomorrow :)
Great! Please let me know if you have any feedback. Keep in mind that it's not finished yet and quite rough sometimes.

The wheel speed sensor is a bit hard to work with because of the very low sample rate at low speeds. Tomorrow I'll try to experiment with a hybrid version of the controller which uses wheel speed AND motor ERPS. But I have to say I'm already really proud of the PI controller performance :D
 
EndlessCadence said:
The wheel speed sensor is a bit hard to work with because of the very low sample rate at low speeds. Tomorrow I'll try to experiment with a hybrid version of the controller which uses wheel speed AND motor ERPS. But I have to say I'm already really proud of the PI controller performance :D
Yes, motor ERPS value change at fast rate like at least 50 per second while wheel speed sensor a values like 0.5 times per second... so ERPS is 100x faster.

But if we would know the gear ratio the user has on bicycle gears, we could direct relate motor ERPS to ebike wheel speed.... I think we can!! We just need to look at ERPS value at a specific wheel speed and them we calc the ratio!! We can assume user did not change gears from last time wheel did rotate, we can store the gear ratio on EEPROM to keep of power on/off cycles.

Knowing the ratio, we can them ramp up ERPS value from 0 startup up to desired value in say 1 second or 2.

Seems complex and it should because of limitations of very low wheel speed but I think we can do it :)
 
maximusdm said:
I made a release for the min current feature from my branch for beta testing. This was already code reviewed.
=> 0.14.4.beta1.zip
I also made release for reaching easier the maximum assisted power level, better responsiveness.
=> 0.14.4.beta2.zip

Hi Maximus I have tested both versions, I know I said I would compile myself but I ended up using the hex files above just so I was starting fresh
beta1.
There is still lag there, I could not feel any difference from the original version. There was no evidence that any extra amps was at work while wheel speed is greater than zero, Amp readout would fall to zero in the display.. should I be able to see any amps on the display if it was working ?
UPDATE: I think "wheel_speed" should be "ui16_wheel_speed_x10"
After changing this and setting minimum current a little higher. I would get some current but it would cut out about 2 seconds after I stopped peddaling
it may be this
Code:
 // if ui8_startup_enable == 0, put duty_cycle at 0
  if (ui8_adc_battery_target_current && ui8_startup_enable && (!brake_is_set()))
and this
Code:
// start when we press the pedals
  ui8_startup_enable = configuration_variables.ui8_power_regular_state_div25 && ui8_torque_sensor ? 1 : 0;
it may be resetting its state after you stop pedalling here
Code:
 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()))
    {
      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;
    }
hmmm... confusing

beta2.
Haha that was fun. When you start peddling it gives you a massive boost, but the fun part (and scary) is that it would run on for about 2 seconds despite I had stopped pedaling. Reminded me of my old PAS bike. Anyway the lag was still there also and temperature was not working it only displayed zero. Lucky for that 2 second cutout, this could have ended differently since I don’t have ebrakes. Hey EC, did you end up making that change where power cuts out at Assist level 0 ?

What does work
So far the only fix is to change the inverse ramp value from 75 to 25. That actually works really well !!

Please Try again...
Thanks for having a go, much appreciated. :)
Please try again with beta 1, its like any amps you add gets knocked back down to zero again, just need to understand the logic ???
 
casainho said:
Tomorrow I will go to mountains with girlfriend and I just flashed ....

Enjoy !!!
So jealous I would love to do some bike packing one day, maybe I can join you guys in Portugal ???

I have been inspired by this guy Iohan, but have to do this on an ebike !! not sure exactly how I would charge every day but...
https://www.youtube.com/watch?v=lIbcBZubsUY
 
jbalat said:
beta2.
Haha that was fun. When you start peddling it gives you a massive boost, but the fun part (and scary) is that it would run on for about 2 seconds despite I had stopped pedaling. Reminded me of my old PAS bike.

whow, that was the same experience i had with the "official" 0.14.3 version i reported about!
A massive boost, have not to pedal hard to keep going and a delay after i stopped pedaling...

Have to try some different releases on this weekend and try again the 0.14.3....
 
Hi Jbalat,

Thank you for the valuable testing.

For beta1: Please make sure that you always get the latest code. I made the changes at work in a simple editor because I do not have the dev environment. I fixed the problem in the evening when I made the 2 releases.

For beta2:
I tryed to make configuration for the feature quite easy.
Code:
#define MIN_ADC_TORQUE_UNITS            8 //maximum 30 units
#define MIN_CADENCE_RPM                    25 // standard cadence
I am not happy that I made an other boost version :(. It shoud be a permanent assist. At start it should have a small boost but the power should remain with you as long as you pedal.

I added an aditional check so the new assist is done only if old cadence is not 0. It should stop assisting exactly like before.
Also the assistence is half now.

@beta testers: Keep in mind you do not need to flash the LCD if you have 0.14.3, only the motor. And thanks for help :)
 

Attachments

  • 0.14.4.beta3.zip
    51.1 KB · Views: 35
Would it be possible that when MPH is the selected speed display option to have the odometer and trip to revert to Miles as well please?
 
Today I did a small test with 0.14.4.beta3. I manged to get my cable working and did a quick connector for the LCD.
Code:
#define MIN_ADC_TORQUE_UNITS            4 //maximum 30 units
#define MIN_CADENCE_RPM                    15 // standard cadence
I was able to achive 500w on 500w assist level. The power is delivered with a nice ramp, no hard boost.
The assist stops when you stop pedaling.

It still needs some good testing for finding the best values, but is a good start.

PS: Do not use power levels like 2000w or it will get violent :). Use assistance levels proper for your motor. I use 150-300-450-600-750.
 
Maximus, power levels are now more logical for sure but I did get some run on and not much reduction of lag that I could tell.
I tried beta1 again but the extra power is still reset after you stop pedalling. I guess if it was working you should just push the bike and it would cut in
 
jbalat said:
Maximus, power levels are now more logical for sure but I did get some run on and not much reduction of lag that I could tell.
I tried beta1 again but the extra power is still reset after you stop pedalling. I guess if it was working you should just push the bike and it would cut in

if (ui8_adc_battery_target_current && ui8_startup_enable && (!brake_is_set()))
{
motor_set_pwm_duty_cycle_target (255);
}
else
{
motor_set_pwm_duty_cycle_target (0);
}

I would say that even if adding min adc current value, ui8_startup_enable may be zero and stops the motor. Maybe the code should keep ui8_startup_enable = 1 also after adding the min arc current value...
 
casainho said:
if (ui8_adc_battery_target_current && ui8_startup_enable && (!brake_is_set()))
{
motor_set_pwm_duty_cycle_target (255);
}
else
{
motor_set_pwm_duty_cycle_target (0);
}

I would say that even if adding min adc current value, ui8_startup_enable may be zero and stops the motor. Maybe the code should keep ui8_startup_enable = 1 also after adding the min arc current value...

What sets startup_enable to zero ?
Is it only enabled when torque sensor is >0 ?
Code:
// start when we press the pedals
  ui8_startup_enable = configuration_variables.ui8_power_regular_state_div25 && ui8_torque_sensor ? 1 : 0;
 
jbalat said:
What sets startup_enable to zero ?
Is it only enabled when torque sensor is >0 ?
Code:
// start when we press the pedals
  ui8_startup_enable = configuration_variables.ui8_power_regular_state_div25 && ui8_torque_sensor ? 1 : 0;
Yes, it is 1 if assist level configured on LCD is not 0 and torque sensor signal if > 0.

I would change to (only for the test you are trying to do):
Code:
// start when we press the pedals
  ui8_startup_enable = configuration_variables.ui8_power_regular_state_div25 ;
 
At the moment I have a problem with the min assist code. It gets very fast to max power and remains there as long as I pedal.
Even if I configure very small assist levels for cadence and torque. I think I am missing something just can't figure it out. Any idea is wellcome.

Also the ui8_startup_enable lead sound interesting. Worth testing with it forced to 1.

Thanks,
max.
 
maximusdm said:
At the moment I have a problem with the min assist code. It gets very fast to max power and remains there as long as I pedal.
Even if I configure very small assist levels for cadence and torque. I think I am missing something just can't figure it out. Any idea is wellcome.

Also the ui8_startup_enable lead sound interesting. Worth testing with it forced to 1.
I don know what can be the problem...

WARNING!!!

You should use brakes while development or you can end up in a situation that motor start as soon you power the system, then what you do?? If you stop the code execution for debug (or flash??), the coils will be powered up and current control will not happen as firmware stops and you will burn the motor controllers very fast!!! With brakes, you just keep then pressed at startup and system will not power on while the brakes are pressed:
Code:
int main (void)
{
(...)
  brake_init ();
  while (brake_is_set()) ; // hold here while brake is pressed -- this is a protection for development
 
casainho said:
Tomorrow I will go to mountains with girlfriend and I just flashed ....
My feedback for walk assist, when using on mountains:

1. Ebikes has the disadvantage that are heavier than regular bikes and when pushing them by hand on step hills, it is a BIG disadvantage!!
Walk assist mode reduces that disadvantage because the ebike pushes itself. PLUS, on this mode the ebike push the rider and here is an advantage over regular ebikes because for instance, on mountains, the rider can go very tired to walk and the ebike helps pushing him.

2. The walk assist speed of 6km/h is about law and law does not represent the needs for users on mountains, or users that walk slow because of special needs like kids, older people, etc.

3. On mountains, for instance, users need different speeds at different moments: different speeds because they are tired and can´t walk faster; because they are at a very step hill and should go slow because of safety; because they are going on rear of other rider walking slow, etc. Ideally the speed is changed in a very quick way, maybe like we change assist level.

4. Walk assist speeds need to be very slow, like 2.5km/h. I saw my girlfriend going very slow on walk assist mode at 2.5km/h and being happy with that because it was slow.

I wish we can implement a good walk assist mode and not just the regular 6km/h...

Feedback for EndlessCadence: On my trip of yesterday with my girlfriend on a very step hills, I fount that current implementation: 1. is very slow to start the ebike wheel; 2. very low power of something like 50W or less.

Because of 2., the speed was VERY slow like 2.5km/h but that ended to working well for my girlfriend that was very tired and did prefer to walk at low speed on that very step hills... walk assist was very important for us, thanks!!


jbalat said:
Enjoy !!!
So jealous I would love to do some bike packing one day, maybe I can join you guys in Portugal ???
I just started this year when I got TSDZ2 and with our firmware running. Before I was using an hub motor and so I never did mountains.

Here are some links with sites that includes information for BTT tracks on our montains:

Aldeias Históricas
http://www.aldeiashistoricasdeportugal.com/percursos/grande-rota/

Aldeias do Xisto
https://aldeiasdoxisto.pt

Manteigas (Serra da Estrela)
BTT: http://centrodebtt.cm-manteigas.pt
Pedestre: http://manteigastrilhosverdes.com
 
maybe it would make sense to have up to 9 walk speeds. using up/down buttons when in walk mode sets the walkspeed. 0-9.
 
Would it make sense to have a static RPM of the front 42t cog?

EG:
If you want a faster walk speed, then just put the bike into 9th (11t rear)
If you want a slow walk speed, then put the bike into 1st (32t rear)

Aim to have the speed of 42t-11t gearing at 6km/h... for legal reasons.
 
Just some testing on the inverse ramp factor to reduce lag
[youtube]UXVxzXzJDbc[/youtube]
 
Back
Top