search

emmebrusa / TSDZ2-Smart-EBike-1

TSDZ2 Open Source Firmware adapted to VLCD5-VLCD6-XH18 displays
GNU General Public License v3.0
133 stars 35 forks source link

Motor stops working randomly, needs to be rebooted to continue #28

Open tiltec opened 2 years ago

tiltec commented 2 years ago

My TSDZ2 with OSF v20.1C.2 occasionally stops working. Display is frozen and I need to turn it off and on to continue.

I found one other reference to this here: https://github.com/emmebrusa/TSDZ2-Smart-EBike-1/issues/16#issuecomment-955170568

This is more of a minor annoyance, but I wonder if it happens for other people too or if a faulty cabling or controller could be the cause.

Almo73 commented 2 years ago

I have experienced the same just very occasionally BUT I am running v20.1c.1 so the issue isn't exclusive to v20.1c.2

emmebrusa commented 1 year ago

Yes, it is possible, when there is an unmanageable problem, I prefer to stop the motor and switch off safely.

From the manual: Attention, there are errors that disable assistance, but they cannot be signaled with a code on the display. Example: interruption of communication between motor and display, or problems in the execution of the program. In such cases, turn off the display and turn it on again.

If the problem is frequent, check the wiring, the display connectors and separate the display cable from the battery cables.

Doug-L commented 1 year ago

Firstly - Thanks for the OSF, only providing feedback in the hope it assists I am aware of three bikes using the firmware. All three bikes were previously running V20.1B with no issues for approx 18 months. All three bikes since updated to V20.1C.2 and V20.1C.2-update-1 have intermittent issues with loss of assistance. In all cases the speed display is frozen and assistance ceases. I think the hardware potential causes such as poor connections to display can probably be dismissed as all three bikes are effected. Unless additional safety checks have been added to the communications checking it would appear that the issue is more likely software stuck in a tight loop or similar. Always recovers immediately on power off - on from display. I have been unable to identify any common causal factor, it appears to be random or not related to riding style or conditions. I have not changed settings to see if its only related to one specific mode of operation (I use torque mode, 15,30,45,80) and almost always on setting 1 (15). I may try power mode for a while and see if same result.

emmebrusa commented 1 year ago

It is a communication error between the controller and the display. Strange that it never happens to some and to others often. I have been suggested a solution by lcha78. I have already made the modification together with others, but unfortunately in this period I cannot try. If you want to try it the version is this: https://github.com/emmebrusa/TSDZ2-Smart-EBike-0/archive/refs/heads/master.zip Let me know if it works.

Doug-L commented 1 year ago

Thanks after I sent notes I noticed the suggested change. Have just installed and will let you know how I go. Will take a few days to be confident as it only happens approx at 80k intervals. If it is a comms error It could be related to install method. IE if comms and power close together more likely to get error. That could explain why some get it and others not. Thanks for taking the time to answer. Regards Doug. L.

On Mon, 10 Oct 2022, 17:04 emmebrusa, @.***> wrote:

It is a communication error between the controller and the display. Strange that it never happens to some and to others often. I have been suggested a solution by lcha78. I have already made the modification together with others, but unfortunately in this period I cannot try. If you want to try it the version is this:

https://github.com/emmebrusa/TSDZ2-Smart-EBike-0/archive/refs/heads/master.zip http://url

— Reply to this email directly, view it on GitHub https://github.com/emmebrusa/TSDZ2-Smart-EBike-1/issues/28#issuecomment-1272821415, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3QVS5JEIY4RROYE6K2IKETWCOWWZANCNFSM53RZBOXQ . You are receiving this because you commented.Message ID: @.***>

Doug-L commented 1 year ago

I have made the changes (merged the revised interrupt code into the version C update) and have so far had good results. I have ridden 90km today on two separate bikes and neither has had a cutout issue. This is by no means conclusive but I would certainly have previously expected one and possibly two cutouts in that distance, so a good omen I believe.

Secondly, and more interestingly both bikes have always had the following very minor issue.

When ridding I occasionally see my speed display drop significantly for a second or two at most, before returning to normal, no other bad behavior noted at the time. Both bikes have always done this including on previous firmware versions. I have always put it down to dodgy wheel sensor but trial and error has showed no amount of wheel sensor adjustment would prevent it from occurring.

Since the change to the receive interrupt suggested by lcha78 I have not seen this happen. I can offer no feasible explanation as to why a read interrupt could effect speed which I would expect to be in the write data but this is almost certainly the case. I would expect to see this speed dip phenomena 2 -3 times per 30km. So the chances of not seeing it in 90km is very low. Maybe this issue has gone under the radar as most people may attribute this to a dodgy wheel sensor as I did.

In short -