Error MOTOR_BLOCKED

[DavidKroeter84]

Hello everybody! Great community work, super impressed by the firmware so far! 🥇

I'm opening this issue due to lack of support in previous forks that casainho maintained. Assuming this is the only active community for the TSDZ2 OSF.

I'm currently on an ancient version of the OSF (0.6.4) on my cargo bike in combination with the 850C display. So far, I did not see the need of an upgrade as everything worked just fine. Never change a running system :-)

Recently, the error MOTOR_BLOCKED shows up regularly in random situations (with and without torque on the pedals, different speeds etc.). So I really don't see a pattern to trace down the root cause.

I investigated the source code and found the following section where the error is set/cleared: https://github.com/OpenSourceEBike/TSDZ2-Smart-EBike/blob/264e04089b7dbeeb487038d40920737d3243a62e/src/ebike_app.c#L1442

One thing I find really strange is that the error never gets cleared when I see the problem ( --> there might be an additional bug in the sw, maybe as ui8_motor_blocked_reset_counter does not get initialised to 0 in the declaration line.).

Questions/thoughts:

• In the condition if ((ui16_g_adc_motor_current_filtered > MOTOR_BLOCKED_MOTOR_CURRENT_THRESHOLD_X5) && (ui16_motor_get_motor_speed_erps() < MOTOR_BLOCKED_ERPS_THRESHOLD)), my assumption is that ui16_motor_get_motor_speed_erps() returns 0 due to some other error which causes the error to be set after a while when there is a certain amount of current in the system.
• I checked where the motor speed gets calculated and found out that this software version only calculates the speed once during the 360degrees motor rotation cycle when a certain state of the hall sensors is reached (https://github.com/OpenSourceEBike/TSDZ2-Smart-EBike/blob/264e04089b7dbeeb487038d40920737d3243a62e/src/motor.c#L522).
• Could that indicate that I have an actual problem with my hall sensors? The motor itself actually runs smoothly before the error occurs. I already thought about disabling the error completely by commenting out some lines. :
• The latest versions in this repo calculate the speed differently in the motor_controller_void()function (https://github.com/emmebrusa/TSDZ2-Smart-EBike-1/blob/cb8b0321e2931d206b54e83773fb469b06325235/src/controller/motor.c#L361)

@emmebrusa : Do you remember why you did this change and do you see a chance that updating to the latest SW solves my problem? If so, I would have to consider buying an 860C or using the vlcd5 stock display as my 850C won't support the latest versions any longer. Actually I would have hoped to tackle the problem by updating to casainhos 1.1.2, however the suspicious lines are still the same there.

Another question: The two forks ran apart pretty early a few years ago. Did you try to catch changes that casainho implemented since then? Hard to judge without experimenting which repo actually offers the better performance...

Looking forward to answers helping to find a solution to my problem!

[dzid26]

I don't know why the error doesn't get cleared, but your guess with hal sensor issue seem reasonable. You could check connections for the rust.

The latest versions in this repo calculate the speed differently

You mean the DOUBLE_PWM_CYCLES_SECOND ? That's because the calculation is now done every second counter tick.

calculates the speed once during the 360degrees motor rotation

FYI, 360degrees represents electrical AC waveform rotation. Motor rotation will be 1/8 of that (based on number of motor poles pairs).

I would update to newer Casaihno's first. It will have more commonalities with this software.

[DavidKroeter84]

Thanks, @dzid26 for your answer!

FYI, 360degrees represents electrical AC waveworm rotation. Motor rotation 8x slower per number of motor poles.

God, what a beginner mistake :-) have totally not considered the pole pair number in my post. Thanks for pointing that out, it was a while since I dealt with pmsm control.

Alright, then I will test 1.1.2 with some manual adaptions.

A last question out of interest: is the software fully reliant on the hall sensors or will it eventually shift over to back-emf angle estimation towards higher speeds?

[dzid26]

A last question out of interest: is the software fully reliant on the hall sensors or will it eventually shift over to back-emf angle estimation towards higher speeds?

Battery voltage limits the max speed (at least if we speak about 48V motor type), not hal reading frequency - as far as know.

However, this software does also support field weakening. But of course at speeds above base speed, the torque becomes small naturally.