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

casainho said:
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 ;

Unfortunately when I use this I get 0.8 amps which is too much !!! (lucky I can set level0 to stop :)
Code:
#define MIN_ADC_BATTERY_CURRENT         1 //1 unit = 0.625 amp


If I assign a decimal value I guess it rounds it to zero and I dont get anything... I assume this needs to be an integer to work ?
 
jbalat said:
casainho said:
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 ;

Unfortunately when I use this I get 0.8 amps which is too much !!! (lucky I can set level0 to stop :)
Code:
#define MIN_ADC_BATTERY_CURRENT         1 //1 unit = 0.625 amp


If I assign a decimal value I guess it rounds it to zero and I dont get anything... I assume this needs to be an integer to work ?
When you say it is to much, what happens for you to say being to much??

Maybes we can reduce to half of that current but that will give some work, time...
 
Yes I can't stop the wheel spinning with the back brake. Too powerful

Can we add power instead of current, it will then be independent of voltage and has better resolution as an integer
 
jbalat said:
Yes I can't stop the wheel spinning with the back brake. Too powerful
And can you validate the 25W on the LCD3 (36V * 0.65A) 25Watts? I was not expecting that 25W could be that powerful....

Well, maybe for now the fast way is to impose a min duty-cycle value, I think this will work (remove the add min adc battery current value code line). I set to 10 but I don know if is a big or small value, you will need to try:

Code:
  if (ui8_adc_battery_target_current && ui8_startup_enable && (!brake_is_set()))
  {
    motor_set_pwm_duty_cycle_target (255);
  }
  else if (ui16_wheel_speed_x10 && ui8_startup_enable && (!brake_is_set()))
  {
    motor_set_pwm_duty_cycle_target (10);
  }
  else
  {
    motor_set_pwm_duty_cycle_target (0);
  }


jbalat said:
Can we add power instead of current, it will then be independent of voltage and has better resolution as an integer
Yes, power -- but first try and report then if we think it will work, we should implement the power. For a 36V battery (as yours) or 52V battery (as mine), is a difference in power of 44%. Even for walk assist mode, we should set power and not current.
 
vscope said:
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.
On hills as I am being doing, I do not use assist level, I just keep assist level at 3 that gives me a good torque sensor/human power sensitivity and I just quick limit motor power using the UP and DOWN buttons, that increases or decreases the motor power assistance I get. For walk assist mode, I think I don´t need to quick change the power (original firmware uses 300W and I think should be a good value) BUT I think we should quick change (increment/decrement the wheel speed) -- if rider is riding on the same type of difficult/hill, he will not need to change the speed value as it stays in memory.

Maybe we could have assist level working not as fixed values but just a value that is incremented/decremented...... (???) Does any one ever thought on this? -- when we have implemented assist level as being a ratio of human pedal power, maybe will be clear if this makes sense or not.
 
Hi all,

I've bought myself a tsdz2 and have the STLink. I'm about to flash the LCD3 but I don't have the little connector to join onto the mainboard on the LCD3. Is that supposed to come with the LCD3?

On the wiki it looks like there is a type of right-angle connector that the other end of the pins plug into?
 
BrisneyLand said:
Hi all,

I've bought myself a tsdz2 and have the STLink. I'm about to flash the LCD3 but I don't have the little connector to join onto the mainboard on the LCD3. Is that supposed to come with the LCD3?

On the wiki it looks like there is a type of right-angle connector that the other end of the pins plug into?
Nope its something you need to make up yourself or you can just solder direct to the board and use an external plug so you dont need to keep opening up the lcd3 everytime to reflash
 
casainho said:
Code:
  if (ui8_adc_battery_target_current && ui8_startup_enable && (!brake_is_set()))
  {
    motor_set_pwm_duty_cycle_target (255);
  }
  else if (ui16_wheel_speed_x10 && ui8_startup_enable && (!brake_is_set()))
  {
    motor_set_pwm_duty_cycle_target (10);
  }
  else
  {
    motor_set_pwm_duty_cycle_target (0);
  }

Thanks Casainho, that code worked, a value of 10 was just right, I tried 20 but it would make the bike move after you try to push it around. Even the value of 10 would cause the chain to move a little and sometimes make some noise because maybe it was too low. Also trying to push the bike back becomes impossible since the motor cuts in when it detects speed :)

In terms of reducing the lag, it did do that to some degree but not quite as good as just changing the inverse ramp from 75 to 25.

I think I have done enough testing to consider this a "FAIL" but if anyone else thinks it still has merit then go ahead and keep trying..(perhaps use a higher pwm and only cuts in above 15km/hr so it doesn't affect pushing the bike) ???

On that note I propose we include the new inverse ramp value of 25 in the next release !!

BTW sometimes my speed sensor gives me weird values like 41km/hr and 64km/hr just pushing the bike around.. Anyone else have this ?
 
jbalat said:
Nope its something you need to make up yourself or you can just solder direct to the board and use an external plug so you dont need to keep opening up the lcd3 everytime to reflash

Thanks jbalat. I don't think my soldering skills are quite up to task to be soldering that small :) I'll have to scavenge through my old PC parts box to see what I can find...
 
jbalat said:
BTW sometimes my speed sensor gives me weird values like 41km/hr and 64km/hr just pushing the bike around.. Anyone else have this ?

Yes, often. When it happens to me it means that the magnet is passing a bit too close to the wheel speed sensor. But I've reverted back to the "stock" firmware and VLCD-5. ( couldn't get 0.14.1 to work, probably needed to clear EEPROM, going to try again at some point... )
 
cj11363 said:
jbalat said:
BTW sometimes my speed sensor gives me weird values like 41km/hr and 64km/hr just pushing the bike around.. Anyone else have this ?

Yes, often. When it happens to me it means that the magnet is passing a bit too close to the wheel speed sensor. But I've reverted back to the "stock" firmware and VLCD-5. ( couldn't get 0.14.1 to work, probably needed to clear EEPROM, going to try again at some point... )
1. I developed an improvement for wheel speed reading -- EndlessCadence should release a new firmware version with that.

2. I developed an improvement for EEPROM writing, now it writes and after verify, if value written is wrong, it keeps trying -- EndlessCadence should release a new firmware version with that.
 
Perhaps it might be useful to add a second magnet to the wheel
This will double the frequency of the rotation reading.
Obviously, the circumference of the correct wheel must be set.
It is an idea that has already been used with the stock firmware
 
vadda said:
Perhaps it might be useful to add a second magnet to the wheel
This will double the frequency of the rotation reading.
Obviously, the circumference of the correct wheel must be set.
It is an idea that has already been used with the stock firmware
That would be another extra part for users to buy, if possible to solve by firmware only, I think we should do it instead.
 
casainho said:
vadda said:
Perhaps it might be useful to add a second magnet to the wheel
This will double the frequency of the rotation reading.
Obviously, the circumference of the correct wheel must be set.
It is an idea that has already been used with the stock firmware
That would be another extra part for users to buy, if possible to solve by firmware only, I think we should do it instead.

With the stock firmware, simply twisting the sensor so that it's another mm or so away from the magnet works for me, which might be the simplest solution :)
 
cj11363 said:
casainho said:
vadda said:
Perhaps it might be useful to add a second magnet to the wheel
This will double the frequency of the rotation reading.
Obviously, the circumference of the correct wheel must be set.
It is an idea that has already been used with the stock firmware
That would be another extra part for users to buy, if possible to solve by firmware only, I think we should do it instead.

With the stock firmware, simply twisting the sensor so that it's another mm or so away from the magnet works for me, which might be the simplest solution :)

Mmmmm.....
Sorry

I think I did not understand :(
 
Battery SOC using Watts/hour counter

I improved the code that previous was reported to count 40% less than theoretical battery value.

My battery pack of 4P14S 52V, 3600mA each cell, has a theoretical battery capacity of 4*3.6*52 = 748,8 Wh. Discharging my battery up to 36V (2.57V each cell), the LCD3 counted 669.4Wh, which is about 80W less (12%). I think that 80W less is a real value due to battery pack resistance, wires resistance and motor controller resistance, including that this cells may hold only the 3600mA in the best conditions.

But I do not plan to discharge my battery pack up to 2.57V each cell but instead to maybe 3.0V (42V for total pack) to preserve a bit the health of the cells so the final value on this case should be lower than the 669.4Wh. To know which battery capacity value to setup on LCD3 for battery SOC using Watts/hour counter, we must first fully discharge our battery pack up to the voltage we want, then we will have the value we are looking for.
 
vadda said:
Perhaps it might be useful to add a second magnet to the wheel
This will double the frequency of the rotation reading.
Having 2 magnets will definitely improve measurements, it's simple statistics. The original soft had the possibility to add more magnets but it was bugged and did not work. If we can add such a feature it would be a good thing.
Regarding the extra cost, I bought a second magnet from Decathlon for 3eur. I do not think it is a problem and the mounting is very easy.

casainho said:
Battery SOC using Watts/hour counter
I improved the code that previous was reported to count 40% less than theoretical battery value.

My battery pack of 5P13S 48V, 3400mA each cell, has a theoretical battery capacity of 5*3.4*48 = 816 Wh.
How low should I go with the voltage to keep the battery health in good condition? Now I use default setting 39v.
 
Rider pedal power show on LCD3

I implemented the code that calculates the rider torque/power/energy (in Watts), applied to the pedals. That value is now shown on LCD3, in odometer field. It also shows the pedal applied force (in Nm).

I can see that my regular value is about 200W of pedal torque/power. Next step I will implement assist levels as a multiplication factor of rider pedal power/torque, for instance, since my regular value is 200W and I like to have motor power assistance of 400W, I will setup an assist level with the factor of 2.0 (200W * 2.0 = 400W).
 
casainho said:
Rider pedal power show on LCD3

I implemented the code that calculates the rider torque/power/energy (in Watts), applied to the pedals. That value is now shown on LCD3, in odometer field. It also shows the pedal applied force (in Nm).

I can see that my regular value is about 200W of pedal torque/power. Next step I will implement assist levels as a multiplication factor of rider pedal power/torque, for instance, since my regular value is 200W and I like to have motor power assistance of 400W, I will setup an assist level with the factor of 2.0 (200W * 2.0 = 400W).

cool feature! will be interesting to see how that feels.

i did some research today on the lag issue.
firmware version 14.3
lag definitely only occurs when boost enabled.

https://drive.google.com/file/d/1C9-BkfBqgeXD1OBJrcdKneBWStuNWU90/view
here in this video i reproduced the lag bug.

it only occurs from time to time, see first attempts.
everything works as expected.
but watch at 0:23 it takes 2 seconds until the motor kicks in.
when you watch closely you can see that the lag occurs only when i start pedaling again immediately after the motor power went to 0.
i reproduced the bug also while checking the debug vars on screen 9
cadence, torque values all are ok but motor is not powering...
so must be a software issue with boost and timing.
will look into the code tonight.
its now easier to find cause it must be related to boost.

cheers

ps: hobbyking has 270wh 6s lipos for 70€ at the moment ;) 150€ for 550wh shipped... 1.5mohm per cell. 10c constant discharge. so theoretically 120A constant @46v and 240A peak ;)
allready bought 2 of those to replace my 3x4s 5200mah setup since 250wh is a little to small...
https://hobbyking.com/de_de/multistar-high-capacity-6s-12000mah-multi-rotor-lipo-pack-1.html
 
casainho said:
Rider pedal power show on LCD3

I implemented the code that calculates the rider torque/power/energy (in Watts), applied to the pedals. That value is now shown on LCD3, in odometer field. It also shows the pedal applied force (in Nm).

I can see that my regular value is about 200W of pedal torque/power. Next step I will implement assist levels as a multiplication factor of rider pedal power/torque, for instance, since my regular value is 200W and I like to have motor power assistance of 400W, I will setup an assist level with the factor of 2.0 (200W * 2.0 = 400W).

Thats so cool, finally the Assist levels will make sense !!

vscope said:
i did some research today on the lag issue.
firmware version 14.3
lag definitely only occurs when boost enabled.
Vscope the lag also occurs without boost but that is not software related its purely due to the engine rpm catching up to your pedals, that is solved by ramping the motor up faster..

I have never used boost so not sure what this software issue is but I really dont know how you could ever program a boost mode using a torque sensor since the boost will need to vary continously based on the amount of pressure you use, and what if you decide to back off while its boosting ? Most complicated piece of code to get right that I could ever imagine!!
 
jbalat said:
Vscope the lag also occurs without boost but that is not software related its purely due to the engine rpm catching up to your pedals, that is solved by ramping the motor up faster..

I have never used boost so not sure what this software issue is but I really dont know how you could ever program a boost mode using a torque sensor since the boost will need to vary continously based on the amount of pressure you use, and what if you decide to back off while its boosting ? Most complicated piece of code to get right that I could ever imagine!!

look at the video again. it did many attempts very similar, pedal, stop pedal, pedal again, similar pressure and cadence.
you see the powerlevel (Configuration 9/6) on my display.
first tries after starting pedaling again the motor immediately kicks in but look at the video at 0:23
the motor lags for 2 seconds and doesnt give ANY -> 0 power which feels like trying to pedal a tank when at speed...
which in this case means i have to pedal the motor up to cadence 80 without any assistance for 2 seconds....
in real life that means you cant accelerate at all for 2 seconds which can be even dangerous in some situations.

there is definitely a timing problem with boost statuses.
 
Exactly.. so don't use power boost.
Why do you think you need it ???
 
vscope said:
jbalat said:
Vscope the lag also occurs without boost but that is not software related its purely due to the engine rpm catching up to your pedals, that is solved by ramping the motor up faster..

I have never used boost so not sure what this software issue is but I really dont know how you could ever program a boost mode using a torque sensor since the boost will need to vary continously based on the amount of pressure you use, and what if you decide to back off while its boosting ? Most complicated piece of code to get right that I could ever imagine!!

look at the video again. it did many attempts very similar, pedal, stop pedal, pedal again, similar pressure and cadence.
you see the powerlevel (Configuration 9/6) on my display.
first tries after starting pedaling again the motor immediately kicks in but look at the video at 0:23
the motor lags for 2 seconds and doesnt give ANY -> 0 power which feels like trying to pedal a tank when at speed...
which in this case means i have to pedal the motor up to cadence 80 without any assistance for 2 seconds....
in real life that means you cant accelerate at all for 2 seconds which can be even dangerous in some situations.

there is definitely a timing problem with boost statuses.
You are correct, there is that issue with power boost not always working but it is hard to understand why. At least we know it is nothing about brakes because users with brake sensors also has the issue.

If you can help to understand, great!! I think is the only issue with power boost otherwise it works very well and I think it is great, at least from the technical point as it is a bit complex, I love the fade out/transition to regular power :)
 
Boost is a very nice feature for me. For instance when you ride around a corner its nice to have some extra boost to get to speed again. Or when i have to climb a short slope, i stop pedaling for a short amount and then use boost to do the climb without loosing speed. Its not that hard to implement since it only has to add X% to the normal human power calc power amount.
All other logic stays the same. however at the moment the code is quite ugly since torque, brake, cadence values are checked all over the place. this should only be checked at the end ob ebike_motor_control since thats the place where we set the power for the motor... i will wait for 14.4 to be stable and then try to change the code with the help of endlesscadence.
 
casainho said:
You are correct, there is that issue with power boost not always working but it is hard to understand why. At least we know it is nothing about brakes because users with brake sensors also has the issue.

If you can help to understand, great!! I think is the only issue with power boost otherwise it works very well and I think it is great, at least from the technical point as it is a bit complex, I love the fade out/transition to regular power :)

i think the problems lies here:

Code:
        // disable boost if
        if ((ui8_torque_sensor == 0) ||
            (ui8_startup_boost_timer == 0))
        {

and

Code:
        // disable fade if
        if ((ui8_torque_sensor_raw == 0) ||
            (ui8_pas_cadence_rpm == 0) ||
            (ui8_startup_boost_fade_steps == 0))
        {
        {

i think ith should be

Code:
// disable boost if
        if ((ui8_torque_sensor_raw == 0) ||
            (ui8_pas_cadence_rpm == 0) 
        {
        ui8_startup_boost_enable = 0;
        ui8_startup_boost_state_machine = BOOST_STATE_BOOST_DISABLED;
        } else if(ui8_startup_boost_timer== 0) {
        	ui8_startup_boost_state_machine = BOOST_STATE_END_BOOST;
        {

Code:
        // disable fade if
        if ((ui8_torque_sensor_raw == 0) ||
            (ui8_pas_cadence_rpm == 0) ||
            (ui8_startup_boost_fade_steps == 0))
        {

on other thing what does this part of the code do? (torque_sensor_read())

Code:
  // 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;
  }

shouldnt the torque sensor always be set to 0 when no cadence?
some part of the code use ui8_torque_sensor_raw while others use ui8_torque_sensor. argh...

what is ui8_tstr_state_machine = STATE_STARTUP_PEDALLING; for?
it only does ui8_torque_sensor = ui8_torque_sensor_raw for 2 seconds.
the whole torque read function has to be changed.
since its strange at the moment,

like i suggested before.
we should remove all this safety checks in different parts of the code an just have one safety function at the end of ebike_motro_control before putting power to the motor.
this will safe a lot of code and bugs are easier to find.

Endlesscadence please let us do this when 14.4 is published.

cheers
 
Back
Top