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

It used to be a feature in the motor firmware for debugging. When one of the E-brakes is activated during powerup of the motor firmware, it will not power the motor. You can single step trough the motor firmware for debugging with that.

I assume the display controls it's own backlight and also sends a command to the motor controller that turns the light output on.
I have no idea if this part of the firmware is also disabled when it detects a brake situation during bootup.
 
daenny said:
Minatauro said:
Hi,
I just swapped out a broken torque sensor for a brand new one, however, there is no assistance from the motor now when peddling. The vlcd5 is fine and has no error codes. I tried the walk assist to test the motor and that is not working. If the display is working does that mean the controller is ok? The torque sensor is new and the wires seem to be ok on it. I can't figure out why it's not giving assistance. Had anyone experienced this before?

I am experiencing something similar. I am on beta 0.20 from buba's Google Drive. I was running it for about 2000km without any problems.
Since two days, the display starts up correctly, but sometimes the lights do not come on (I have the setting that the lights should be on after start). When this is the case, also the motor does not start at all. Voltage, cadence and speed readings are working. I can change the assist levels. But when I switch the lights, only the display light switches, and no motor assist whatsoever, also no walk-assist.

I do not have e-brakes, but today I saw once that the e-brake sign was shortly on. Could that be the reason?
In other cases, the e-brake sign was not on at all, and the motor had the same behaviour.
Sometimes, after a while the lights come on and then the motor also works as expected for the whole trip until I shut it down again.

A couple of questions:
If, for some reason the e-brake pin is giving the wrong reading during bootup, could this lead to the described behaviour?
Could we add a function to disable the ebrakes completely in the software?
Is there any other thing which could prevent the motor to give assistance?

Another theory is that there is something in the code, i.e. could it be that there is a buffer overflow or similar? I will re-flash the bike this weekend to check if that is the case.
That issue of no lights and no motor assistance should not be related to brake sensor. Still, yes, it is on the list since long time ago to be able to disable some sensors on the display and keep the system work, mainly because sensors can fail while we are riding far from home.

I think no lights and no motor assistance are really connected due to how the hardware works. I am being slowly working again on the motor controller and I will revise this, I think there should be a way to solve this.

I would say that maybe this issue happens to you because the ambient temperature is now colder than before??
 
In v0.19 the brake sensor behaviour seems to pause the motor, rather than fully reset all operations. When the brake is applied in ebike_app.c (around line 316) what other parameters could be (re)set to ensure this?

I've tried setting ui8_g_duty_cycle = 0 or decrementing it, but get a hard motor shut off when otherwise the brake operation is quite smooth.

Code:
 // let's force our target current to 0 if brake is set or if there are errors
  if(ui8_m_brake_is_set || ui8_system_state != NO_ERROR) { ui8_m_adc_battery_target_current = 0; }
 
famichiki said:
In v0.19 the brake sensor behaviour seems to pause the motor, rather than fully reset all operations. When the brake is applied in ebike_app.c (around line 316) what other parameters could be (re)set to ensure this?

I've tried setting ui8_g_duty_cycle = 0 or decrementing it, but get a hard motor shut off when otherwise the brake operation is quite smooth.

Code:
 // let's force our target current to 0 if brake is set or if there are errors
  if(ui8_m_brake_is_set || ui8_system_state != NO_ERROR) { ui8_m_adc_battery_target_current = 0; }
What are you trying to achieve??
 
casainho said:
What are you trying to achieve??

To fix the motor overrun and strange kick of power sometimes after stopping pedalling. Right now I need to wait a few seconds after stopping pedalling to change gear smoothly. However momentary braking cuts power instantly and smoothly. The problem is that after releasing the brake the overrun can restart, and also can still get that strange kick. So when I grab the brake I want to totally forget whatever other calculations are happening and reset the motor.
 
famichiki said:
casainho said:
What are you trying to achieve??

To fix the motor overrun and strange kick of power sometimes after stopping pedalling. Right now I need to wait a few seconds after stopping pedalling to change gear smoothly. However momentary braking cuts power instantly and smoothly. The problem is that after releasing the brake the overrun can restart, and also can still get that strange kick. So when I grab the brake I want to totally forget whatever other calculations are happening and reset the motor.
Good.

Would be great if after you can share with us your discoveries so I can improve next firmware version.
 
famichiki said:
casainho said:
What are you trying to achieve??

To fix the motor overrun and strange kick of power sometimes after stopping pedalling. Right now I need to wait a few seconds after stopping pedalling to change gear smoothly. However momentary braking cuts power instantly and smoothly. The problem is that after releasing the brake the overrun can restart, and also can still get that strange kick. So when I grab the brake I want to totally forget whatever other calculations are happening and reset the motor.

Which firmware? Do you have boost assist on? Is this occuring and the 10? seconds after starting riding?
 
I really don't have much knowledge of this code or embedded processors so am struggling to figure things out.

I only have the VLCD5 display, and have tried Marcoq's and Ackmaniac's forks and Demion's branch. All are based on v0.19 and all have some issues present. It happens with or without boost assist. Stancecoke gave me some suggestions in the VLCD5 thread but that either didn't improve things or caused a hard cut out and loud click which felt like it may damage the motor.

https://endless-sphere.com/forums/viewtopic.php?f=30&t=98281&start=550#p1514160

The overrun can be quite long, I can count the seconds out... one one-thousand, two one-thousand... Then the kick of power will sometimes suddenly come after the motor has stopped running. I can't remember if I mentioned it in this thread, but sometimes the motor never cuts and it continues propelling the bicycle until the main power is forcefully cut off. There are a few others in the VLCD5 thread with the same problem.

The brake works very quickly due to being on an interrupt and cuts the power so smoothly. I wish the PAS detection worked the same way. But if the motor is in an overrun state, if you quickly apply and release the brake the motor will return to the overrun. Braking should reset and shutdown everything until pedalling is detected again.

I know development is focused on 0.20 now but if anyone could provide some assistance I'd really appreciate it. I'd like to do a quick workaround of tapping the brake to kill the overrun and reset the motor.

So, how to stop the motor from resuming where it left off before the brake was applied?

I think this what happens when applying the brake...

brake.c
brake is set = 1
Code:
BitStatus brake_is_set(void)
{
  if (GPIO_ReadInputPin(BRAKE__PORT, BRAKE__PIN) == 0)
    return 1;
...

Code:
void EXTI_PORTC_IRQHandler(void) __interrupt(EXTI_PORTC_IRQHANDLER)
{
  if (brake_is_set())
  {
    motor_controller_set_state (MOTOR_CONTROLLER_STATE_BRAKE);
...

motor.c
ui8_m_duty_cycle_target = 0;
Code:
void motor_set_pwm_duty_cycle_target (uint8_t ui8_value)
{
  if (ui8_value > PWM_DUTY_CYCLE_MAX) { ui8_value = PWM_DUTY_CYCLE_MAX; }

  // if brake is active, keep duty_cycle target at 0
  if (ui8_motor_controller_state & MOTOR_CONTROLLER_STATE_BRAKE) { ui8_value = 0; }

  ui8_m_duty_cycle_target = ui8_value;
}

ebike_app.c
ui8_m_adc_battery_target_current = 0
Code:
if(ui8_m_brake_is_set || ui8_system_state != NO_ERROR) { ui8_m_adc_battery_target_current = 0; }

Is this all that happens?

There must be something else going on that immediately sets ui8_m_duty_cycle_target and/or ui8_m_adc_battery_target_current back to their previous state after the brake is released, but what?
 
famichiki said:
Is this all that happens?

There must be something else going on that immediately sets ui8_m_duty_cycle_target and/or ui8_m_adc_battery_target_current back to their previous state after the brake is released, but what?
I think you did understand the code. I hope you get the issue.
 
casainho said:
That issue of no lights and no motor assistance should not be related to brake sensor. Still, yes, it is on the list since long time ago to be able to disable some sensors on the display and keep the system work, mainly because sensors can fail while we are riding far from home.

I think no lights and no motor assistance are really connected due to how the hardware works. I am being slowly working again on the motor controller and I will revise this, I think there should be a way to solve this.

I would say that maybe this issue happens to you because the ambient temperature is now colder than before??

It is indeed much colder now and my bike is outside in the shed. But I tried again today where it is quite mild (10 degrees Celsius) and still in did not start.
Is there anything that I can try to eliminate certain issues? I use the bike for my daily commute to work and not having a motor support is not the worst, but I really need the lights. I will reflash this weekend just to be sure.
 
mctubster said:
Which firmware? Do you have boost assist on? Is this occuring and the 10? seconds after starting riding?

Just wondering why you are asking those specifics, is there a known similar problem with boost enabled?
 
daenny said:
It is indeed much colder now and my bike is outside in the shed. But I tried again today where it is quite mild (10 degrees Celsius) and still in did not start.
Is there anything that I can try to eliminate certain issues? I use the bike for my daily commute to work and not having a motor support is not the worst, but I really need the lights. I will reflash this weekend just to be sure.

I just did a reset to factory defaults and reconfigured everything to the same way as before (except the odometer). It seems to work now again. I turn the bike on and almost immediately the light turns on and the motor support is working. I will see how it holds up.
I was looking through the advanced technical data, the torque reading is now 135 idle up to 240 under load. I thought that previously it was much lower... What are reasonable readings for the torque sensor?
Could that also explain the bike not starting, i.e. that the torque sensor is slightly damaged or giving bad readings, leading the bike not being able to calibrate or something?
Maybe the torque sensor is also sensitive to cold? Does anyone have a similar experiences?

EDIT: I was too quick :(.. Now it did start up, but again with 10-20 seconds wait...
 
I am being working on the next firmware version, both on motor and on display. The main new feature will be the torque sensor full calibration and here is my torque sensor values (X axis shows kilograms weight on the left and right pedals and Y axis the torque sensor ADC value).

We can see it is not linear and even worst, from time to time, I think we will need to recalibrate the torque sensor because it gets worst/gets less sensitive. We will be able to input on the display, the delta measured values of torque sensor ADC and kilograms weight.

Screenshot-from-2019-12-21-21-22-34.png


And to make all this, the configurations data that flows from display to motor controller will increase a lot, so, I had rewrite a new communication protocol. Now, the display asks for the motor controller firmware version at startup and only works if is the expected version. Also, the configurations are then sent from the display and the motor will not work until receive them.

Screenshot-from-2019-12-21-21-21-52.png


The new communication protocol is working well and the next step I will do is to add the torque sensor calibration configuration menu. I really expect to have this new version of firmware on the next Friday day 28. And this is only for 850C display for now, as we have currently some issues with the code of SW102 and that should be solved as soon as the geeksvile developer is available again to work at it.
 
casainho said:
I am being working on the next firmware version, both on motor and on display. The main new feature will be the torque sensor full calibration and here is my torque sensor values (X axis shows kilograms weight on the left and right pedals and Y axis the torque sensor ADC value).

We can see it is not linear and even worst, from time to time, I think we will need to recalibrate the torque sensor because it gets worst/gets less sensitive. We will be able to input on the display, the delta measured values of torque sensor ADC and kilograms weight.

Screenshot-from-2019-12-21-21-22-34.png


And to make all this, the configurations data that flows from display to motor controller will increase a lot, so, I had rewrite a new communication protocol. Now, the display asks for the motor controller firmware version at startup and only works if is the expected version. Also, the configurations are then sent from the display and the motor will not work until receive them.

Screenshot-from-2019-12-21-21-21-52.png


The new communication protocol is working well and the next step I will do is to add the torque sensor calibration configuration menu. I really expect to have this new version of firmware on the next Friday day 28. And this is only for 850C display for now, as we have currently some issues with the code of SW102 and that should be solved as soon as the geeksvile developer is available again to work at it.

Thank you so much for your efforts to improve osf :bigthumb:
 
casainho said:
I am being working on the next firmware version, both on motor and on display. The main new feature will be the torque sensor full calibration and here is my torque sensor values (X axis shows kilograms weight on the left and right pedals and Y axis the torque sensor ADC value).

We can see it is not linear and even worst, from time to time, I think we will need to recalibrate the torque sensor because it gets worst/gets less sensitive. We will be able to input on the display, the delta measured values of torque sensor ADC and kilograms weight.

Good stuff casainho. I will stay tuned for the development, even if I admit that current v0.20 with LCD3 is really good and hard to beat.

I have just one question: there is a lot of effort in modeling the non linearity of the torque sensor and obviously we lose a lot of "resolution" after the first linear segment because we need a lot more kg on the pedal, compared with the 1st linear segment, to increase 1 unit in the torque sensor.
I see from your chart that you have about 20 kg each pedal available in the first linear segment (same as mine from my summer readings), I do not have numbers on top of my head but what is the force we average put on the pedals going uphill on a proper low gear? Are we most of the time in the 1st linear part or in the 2nd?

Thanks and.. Merry Christmas to everyone in the forum!!
 
In v0.20 what is the difference in how advanced cadence mode works vs standard mode and why is calibration required?
 
thineight said:
I have just one question: there is a lot of effort in modeling the non linearity of the torque sensor and obviously we lose a lot of "resolution" after the first linear segment because we need a lot more kg on the pedal, compared with the 1st linear segment, to increase 1 unit in the torque sensor.
I see from your chart that you have about 20 kg each pedal available in the first linear segment (same as mine from my summer readings), I do not have numbers on top of my head but what is the force we average put on the pedals going uphill on a proper low gear? Are we most of the time in the 1st linear part or in the 2nd?

Thanks and.. Merry Christmas to everyone in the forum!!

If you work backwards using math and are reasonably fit, say you are outputting 200W at 80RPM = 23.87Nm of torque. Using .17m lever length that gives you 14.32KG of pedal force (on average, ie across both pedals.)

So I would say you are generally operating below 20KG unless you are standing on the pedals, which you only do for low RPM high torque and not for high power. So the sensor assuming calibration for the lower range 0-20KG is pretty good unless you are standing on the pedals so to speak.

Cheers
 
mctubster said:
If you work backwards using math and are reasonably fit, say you are outputting 200W at 80RPM = 23.87Nm of torque. Using .17m lever length that gives you 14.32KG of pedal force (on average, ie across both pedals.)

So I would say you are generally operating below 20KG unless you are standing on the pedals, which you only do for low RPM high torque and not for high power. So the sensor assuming calibration for the lower range 0-20KG is pretty good unless you are standing on the pedals so to speak.
We can see on the graphs that a value after 10kgs, the torque sensor measures half the value, so, it is very no linear almost at start.

I can do 200 watts on average but about 400 if I press the pedals on a climb for some minutes, even without standing on the pedals. And the peak peak values measured are about 1.4x times more than the average, so yes, I am on the no linear part almost always.

thineight said:
Good stuff casainho. I will stay tuned for the development, even if I admit that current v0.20 with LCD3 is really good and hard to beat.
My idea to to merge the v0.20 good features over the time.

There are things I don't like, like the emtb, because it masks this no linearity of the torque sensor.
With torque sensor full calibration, the output of the sensor are linear kgs/pounds (also correct calculation of human power!!), then, on top of that, the emtb can be added all will be more predictably and easy to understand the values, also the emtb curve points being setup directly on the display.
 
famichiki said:
In v0.20 what is the difference in how advanced cadence mode works vs standard mode and why is calibration required?

If I remember correctly v0.20 counts also the moment when the magnets goes far from the sensor (valleys), not only when it approaches (peaks) like the std mode. In such way you practically double the resolution of the PAS.
Not sure why the calibration is needed, I assume to properly determine the "best distance" between the readings, because I assume they are not just half the peaks distance.
Hope it's clear enough.
 
I'm checking my torque sensor on the VLCD5 and sending ui16_pedal_torque_x10 to the display as an error code. The display is working fine, but is that the correct value to do the wiki calibration procedure? In the VLCD5 thread it was suggested I should use x10/4.

https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/How-to-calibrate-the-torque-sensor

Below are the results from a quick test. :shock:

Code:
0kg    14
10kg   35
20kg   90

If I am reading the torque value correctly, should I contact the supplier for a warranty claim or is it usually possible to correct these extreme readings with calibration? The motor is a few months old and never seemed to work correctly.
 
Back
Top