Weird noise in my motor, what could have caused it?

After 5 months of waiting for parts I can finally build my board. The problem is that there is some kind of weird noise inside of one of my motors. It only appears on one motor, and if I swap the phase wires the motor appears on the other side. The noise goes away if I brake 100%, or sometimes for a short while if I don’t (you can hear it in de video).

This is the noise I’m talking about:

Here are some of the configurations I got, I think the issue lies at connector 2:

576-1024

498-1024

498-1024

498-1024

Let’s go over every component any try to eliminate as much components as possible:

  • Motors: If I swap the phase wires the issue appears on the other motor. As the motors stay the same but the issue does not the motors are eliminated.
  • Remote: I fail to see how a remote could cause one motor to make a weird noise no matter what position the joystick is in.
  • Sensor wires: I tried to run it sensorless, but I got the same issue.
  • PPM: I’m using UART, and changing to PPM does not change the symptoms.
  • Battery: What the hell does the battery have to do with motor noise?
  • Board: ^ s/battery/board

This leaves the Unity as the only probable cause of this issue.

This all would not have been so bad (shit happens) if there was any support from Enertion whatsoever. First of I turned to the forum, as you guys are awesome. I want to thank anyone who tried to help me, I really appreciate it!

The other forum:

https://forum./t/noob-question-thread-ask-your-questions-here/126/1524

https://forum./t/haya-hb83-33-short-board-progress/244/49

I also tagged most of the Enertion guys directly, no response.

I also send a support request 4 (!) days ago, but I have yet to receive a response which is not automated.

498-1024

498-1024

498-1024

I don’t think urgent means there what it means here… I am protected by European law, but I don’t feel like going that route. I would much more like to go the route of actually solving the issue. I’ll tag them again: @carl.1, @CarlCollins, @adrianenertion, @barajabali or @Deodand. Can anyone tell me what the hell is going on, because I’m so close to throwing in the towel. I just want to ride :(. My support ticket is #82023.

Thanks.

One hack around this that may help is to make the observer gain, Flux linkage measurements, etc match eachother. Start with observer gain and make the problem side of the unity match the value of the good one. See if it goes away and report back please!

2 Likes

Do you mean copying all values from motor 1 to motor 2? From this image?

Yes but it depends on which motor side (1 or 2) you think is good. So when you switched the phase wires and the other motor had issues, that side of the unity is most likely the offender. Copy good side values to bad if that makes sense.

1 Like

I’ll try that, one more question. Does it make sense to do the calibration once, write down the measurements for motor 1, swap the wires, calibrate again and replace the measurements for motor 2 with the written down values? I think it could improve the accuracy of the values as you would be using two “good” measurements, just both measured with motor 1.

I’ll answer your question with another question.

If you swap motors and get different results on the same side of the unity using “identical” motors, would that make you any more comfortable?

The results should be very very similar. Try it for science.

I.e.

Motor 1 on Unity Left (L) values =/ motor 1 on Unity Right ®.

Motor 1 on Unity L = Motor 2 on Unity L

1 Like

I tried it, but it didn’t seem to do much. What I did notice is that the observer gain was about 450 for motor 2, which is way higher than motor 1.

Ok just for clarification, you tried that on unity left or right side?

I tried what you initially said. Just copy over the values from focbox motor 1 to focbox motor 2

You copied the values over and reran motor detection?

No, I just saved them. Motor detection would override the values right?

1 Like

Yes, exactly. How did the observer gain value change to 450 then?

Sorry if I missed something obvious

1 Like

I ran motor detection again before overriding the values. I didn’t mention that. This was because I was not completely sure I didn’t change anything in the wiring after the last change. That’s when the high value appeared.

Ahh that makes sense now. How did the resistance, inductance, and Flux linkage measurements look?

Mostly the same iirc. Maybe a 5% difference for most values.

I also noticed something else, which is what I suspected earlier. The “wrong” motor actually wiggles a bit when it’s making that noise.

Interesting. I’d guess that’s from not processing the input signal smoothly.

I had a bad Flux linkage mismatch that caused a similar issue but yours look much more normal at around 4 mWb.

I had one at 4 and one at 33 but it responded very similarly to what you’re describing.

1 Like

A new measurement made, this is straight from detection. The observer gain is now way less than before. I also noticed that on the focbox had a green led on it, which seems to be responding to the noise. If there is a noise the light becomes less bright, when it stops it becomes normal again. I think this is the signal light. Sorry for the shitty screenshots, I have to borrow a laptop from someone else as mine all run Linux…

57

if the green light is changing intensity, that mean it is receiving a signal from the remote. Is it possible to use a ppm only remote? In my experience with the photon, well it never left the bench.

1 Like

I don’t have a ppm remote, any recommendations for a cheap one for testing? Or is it possible to test it with an Arduino or something? It did also happen when the remote was not properly set up yet, so I really doubt this is the cause of the issues.

Another reason why I don’t think that’s the issue is because I read trough the source code of a VESC UART library, and it only references the joystick position to change the speed. As you can see in the second video I change the joystick position a lot, but the issue stays the same. This would eliminate that as the culprit.