the confusing bit to me is it seems to have triggered with a value of 74.14c . which is below the 80c throttling start, and the 100c cutoff. it just cut out.
I was riding a newer lower / torquier gear ratio, and going full throttle on flatland for a few mins when it happened. so I thought maybe it was a real issue. but motors didn’t seem hot. and the temp in the fault message isn’t beyond the thresholds.
so maybe a quick spurious value if the value gets updated between the check and the fault message being printed. that would speak to the noise idea that @Pedrodemio mentioned…
Not running temp sensors can be helpful and harmful. If you are having issues with noise causing nuisance faults as @Pedrodemio mentioned then it seems the only option. I, for one, would exhaust all options before running with no temp sensor. Reason being, I recently got a similar fault on one motor. When I did the “feel test” I nearly singed my fingers. There was an internal short in the motor as you can see the glowing wire in this video. Just something to be cautious of if running blind. Wouldn’t be a bad idea to periodically check your temps by feel during stops along your ride. This could save you from a full meltdown. Good luck
The following faults were registered since start:
Fault : FAULT_CODE_OVER_TEMP_MOTOR
Current : 19.6
Current filtered : 18.8
Voltage : 33.71
Duty : 0.950
RPM : 35618.4
Tacho : 5231903
Cycles running : 28798
TIM duty : 7980
TIM val samp : 2
TIM current samp : 4200
TIM top : 8400
Comm step : 0
Temperature : 70.21
I’m running metr now. i was able to see that motor temps at the time were around 70 - 75 . on the motor that triggered the issue. about 5 degrees less on the other one. so not into the 80c cutoff start nor at the 100C throw alert. but definitely at the higher end of my whole ride.
definitely seems like some glitchy reading / fault. hmm.
The following faults were registered since start:
Fault : FAULT_CODE_OVER_TEMP_MOTOR
Current : 32.2
Current filtered : 31.0
Voltage : 32.57
Duty : 0.930
RPM : 33632.9
Tacho : 12043889
Cycles running : 101383
TIM duty : 7815
TIM val samp : 2
TIM current samp : 4200
TIM top : 8400
Comm step : 0
Temperature : 71.60
This is happening on my primary motor/focbox.
This primary motor is about to be replaced. it’s rubbing a bit. It has the same problem my other motor did.
Today observing Metr while riding temperatures were higher. and higher by about 5°C on the primary.
they were approaching and brushing up 80°C . when this happened I got a stuttering which I presume is the current throttling from motor temp cutoff start. It’s very stuttered though, and not at all smooth the way the low voltage current cutoff works. IDK if that’s right.
so… temps were higher, but again never looked high enough to jump to the 100°C required throw the fault that did throw once. so still seems like a bug.
Ugh I was wrong. The motor I was replacing is my secondary. The primary is the one throwing the faults.
And on the bench with no load it stutters when approaching high duty cycle. The primary motor does not.
The motor temps do oscillate a lot as the motor spins. On both motors. Perhaps + or - 5 deg. Not enough to be in throttling zone. As measured by Vesc tool real-time data. But only the primary is having issues.
I noticed my PPM mapping only went to 99.x% not 100%. adjusted it a little. and noticed that the stuttering goes away at 100% throttle but anything just under and it stutters. with the duty cycle jumping around.
So, initially I believe i observed the stuttering while riding. I believed it was related to motor temperature current throttling, since I’d also had the fault code randomly. So I tried to reproduce on the bench. with no load, no wheels attached, the motor exhibits an obvious stuttering.
whichever motor is connected to primary vesc. the secondary controlled via CAN does not stutter, and other VESC
in BLDC or FOC sensored or sensorless mode.
not when PPM signal reaches 100%. only when it’s lower.
I did not try moving PPM input to the other focbox yet. [bit more intrusive in my current glued up setup. ]
I thought maybe it was related to min current, which both my focboxes have set to 1A, so I set them to the default of 0.1 A. it didn’t change things. so I changed it back.
I did run with belts on to 8in pneumatic wheels. and the stuttering was no longer noticeable. so I’m wondering if this was all a red herring, and i’m not really tracking with this stuttering whatevever the issue is I felt on the road. .
Ok, I did all the ungluing required to move the receiver over to my second focbox. and the stuttering traveled with it. so I think this bench test is just a red herring. and I’m seeing something that’s a side effect of running with no load.
I probably still have unexplained random triggering of motor over temp faults.
Oh, this is probably what you meant. I assume the idea would be to twist the motor phase wires together and separately twist the sensor wires.
seen any pictures of how people have implemented this?
would it do anything on the sensor wires? for that mater how does it help on the phase wires? I’m think of wire twisting to reduce noise being related to running the same signal over two wires twisted together. none of these wires have the same signal.
I’m down to try it. wish I’d understood it before I did my motor replacement.
You could just unplug the temp wire of that motor and use the one it is working right to tlet you know the value…both motors should work the same way…So you will be playing preety safe…I am actually using one motor temp because the other one failed, so I just twisted the Vesc-Tool to ignore the temp on the fucked up motor…Everything it is running great…
Got this fault again. It’s definitely happening when my temperatures are up near the thresholds.
This time I caught it all on metr.
Metr records in faults page that the fault was at 14:39:30 (PST)
things to observe in the charts:
yes noise in the temperature readings, when running full throttle every where you see 95% duty cycle in the charts.
14:39:30.486: duty cycle starts drop from 95%. ppm still high presumed temp throttling throttling. though temp is only 75c
14:39:30.870: we do see a temperature read by metr at 92c !! (moment later. ) so maybe it did spike to 100C to trigger the fault? also this wildly fluctuating temp is clearly noise. it’s also very large jump compared to anything else in the charts.
odd thing still being the temp in the fault code is lower than the threshold start 80c, and fault code trigger of 100c, and the highest metr recorded value of 92c.
I gonna guess: bug in vesc code that it’s not printing the actual temp measurement that triggered i the fault.
And, I’m clearly getting sketchy noise that the hardware filtering and software filtering of the vesc is not immune to. Part of me doesn’t see any reason not to have larger window on the low pass filter in the vesc code. a large spike across 400ms seems unlikely in the real world.
Next run at this I will try to do something to physical to shield the noise, such as twisting allt he phase wires to gether or separately shielding the sensor wires or something. I’d have to learn better there.
@Pedrodemio I’m quite sure you’re right now bout the injected noise.
Fault : FAULT_CODE_OVER_TEMP_MOTOR
Current : 21.8
Current filtered : 19.5
Voltage : 34.44
Duty : 0.950
RPM : 36554.7
Tacho : 1647371
Cycles running : 184274
TIM duty : 7980
TIM val samp : 2
TIM current samp : 4200
TIM top : 8400
Comm step : 0
Temperature : 74.90
I haven’t had any answer on vedder forum apart from the initials reply
Maybe this is something to be looked on the new branch from @DerelictRobot , it sure is dangerous if you have no idea it will happen and are under heavy acceleration or braking
Something that is currently literally just a fork of the VESC-TOOL branch and nothing to write home about as the work that has been done hasn’t been published yet. Needs more than a few days/weeks. But one of the goals is to try to get some feedback and data on issues liek this and/or 3rd party hardware.
Currently in the process of testing the new firmware along with everyone else.
I’m considering 4.0+ to be unstable/unknown for now.
Well damn. that was a read. with a trampa slog in the middle.
Gist of OpenRoad ( @DerelictRobot’s branch ) as i understood it. Fork vesc-tool / bldc firmware try and make an ecosystem that manages releases. identifying stable releases from community testing and keeping them changing slowly and carefully. manage dev releases so that community can test new changes.
if we consider this not dealing with noise in temp sensors a safety issue which it kinda is, the fault at 50kph could easily taken me down. I see how the OpenRoad’s focus on stability would sort of connect it to this issue.
but there’s no new process with openroad yet, so a fork is a fork.
Do you know someone that wants to hack on a fix? we can do that on any fork of bldc and submit it to vedder and openroad assuming one is found. Making the issue clear to vedder is still probably a good way to find someone who wants to fix it and has the skills. ( as hard as that may be. )
But one of the goals is to try to get some feedback and data on issues liek this and/or 3rd party hardware.
with a trampa slog in the middle.