Massive EMI issues

[OM222O]

Hello everyone
I'm working on a robotics project and I was having some really odd issues. Basically I have 2 DC motors that drive the robot and they are equipped with rotary encoder. I already had a 10A H bridge as well, so I decided to use two arduinos, dedicated to motion control for each wheel.




I was only testing my code on the right side arduino and everything seemed fine but when I uploaded the code to the left one, nothing worked. arduino kept getting reset and go crazy, it would lose steps and position control was dodgy. I tried literally everything you can think of:
- Swapped the motors around
- Swapped which arduino was controlling which motor
- Swapped the H bridge that was controlling the motor
- Swapped the arduinos all together!

but the only thing that seemed to actually help was wrapping aluminum foil around the cables.
I have used this exact motors and an arduino before and never had EMI issues (mind you at lower power levels. they're rated for 12v but in this case I must use a 4s battery pack , hence 16V input, for which I'm currently using a wall adapter during the testing phase).

I'm not sure where the source of the EMI is however, the motor windings? the wires that run next to each other? (the motor comes with a 6 pin header, 2 for motor, 2 for encoder phases and 2 for 5v and GND for encoders) I have wrapped the pairs separately in aluminum foil and then wrapped another layer of aluminum foil over all of those as well, which has mostly solved the issues. no more weird rests, no more going crazy, but the left motor still loses position sometimes so I'm assuming I didn't do a great job with wrapping it.

Now to the main questions:
1) Is there a way to reduce the EMI? A ceramic capacitor soldered right at the motor terminals? perhaps some back to back zener diodes rated at let's say 20V?
2) Is there a better way to wrap the wires? does some sort of emi wrapping strip exist? the kitchen foil seems too stiff or perhaps my method isn't correct?
3) Does adding a capacitor to the arduino power lines stop the potential reset issues?

Some extra information:
The wheels are DFRobot KIT0085
The H bridge is the MDD10 A
Arduinos are nano, purchased very recently (comes with the new bootloader)

[Andreas]

Hello,

2) the main problem is that aluminium oxidizes and so gives no good contact between the layers. Assuming the EMI source is the motor and leaves the motor housing by the wires you might want to short it back to the motor housing before it spreads over your whole cirquit. So with a better conducting material you might have luck by contacting the shield back to the motor housing (and or to the metal plate below the PCBs). Yes there are EMI-Shields for this purpose but they are not cheap.

1) a 10-100nF capacitor across the terminals might help somewhat. But it is also possible that the H-bridge cannot handle capacitive loads. You need a path back to the motor housing. So additional to the 10-100nF across the pins you need 2 * 1-10 nF from the pins to the motor housing to prevent the EMI getting from the motor to the motor supply lines. Another possibility to prevent leaving the EMI from the motor housing would be adding some inductivity 10-470uH or EMI-Ferrites into the supply lines close to the motor pins.

3) This will most probably not help as there are already some capacitors. What I would try is a 1-10nF capacitor between reset and ground pin of the processor (shortest possible connection).

with best regards

Andreas

[floobydust]

Where is the robot chassis ground connection? It should have continuity only to DC(-).

[OM222O]

The chassis is not grounded, The only ground connection to the motor is for the encoder signals. Does grounding the motor housing reduce the noise? if so I can easily do it because the power distribution board has a lot of empty grounds.

Correction:
I checked with a DMM and the entire chassis as well as the motor housings are grounded. I think this is because I used brass inserts and the H bridge has exposed ground pads. Now I'm wondering if this could be a ground loop problem? That seems unlikely however, since adding foil around the cables shouldn't have fixed the issue if it was a ground loop problem?

[OM222O]

Hello,

2) the main problem is that aluminium oxidizes and so gives no good contact between the layers. Assuming the EMI source is the motor and leaves the motor housing by the wires you might want to short it back to the motor housing before it spreads over your whole cirquit. So with a better conducting material you might have luck by contacting the shield back to the motor housing (and or to the metal plate below the PCBs). Yes there are EMI-Shields for this purpose but they are not cheap.

1) a 10-100nF capacitor across the terminals might help somewhat. But it is also possible that the H-bridge cannot handle capacitive loads. You need a path back to the motor housing. So additional to the 10-100nF across the pins you need 2 * 1-10 nF from the pins to the motor housing to prevent the EMI getting from the motor to the motor supply lines. Another possibility to prevent leaving the EMI from the motor housing would be adding some inductivity 10-470uH or EMI-Ferrites into the supply lines close to the motor pins.

3) This will most probably not help as there are already some capacitors. What I would try is a 1-10nF capacitor between reset and ground pin of the processor (shortest possible connection).

with best regards

Andreas

Thanks for your answer! How can I connect the shield back to the housing? It's not possible to solder to the aluminum foil.

I will try adding some capacitors but unfrotunetly all I currently have are small SMD ones so can't test untill I get new parts.

Unfortunately the wires are really close together and I can't use ferrite beads around them. Where can I find the shileding materials you mentioned? I also have some "space blankets" which are metal coated mylar. from what I see most insulation materials are the same thing. can I use that instead?

[floobydust]

[...] I checked with a DMM and the entire chassis as well as the motor housings are grounded. I think this is because I used brass inserts and the H bridge has exposed ground pads. Now I'm wondering if this could be a ground loop problem? That seems unlikely however, since adding foil around the cables shouldn't have fixed the issue if it was a ground loop problem?

As long as there is at least one reasonable chassis ground. A ground loop I would not worry about. The Arduino board needs its ground pour also going to a spacer bolt, I'd scrape off some solder mask on the top board or maybe a lockwasher does it.

There's many things that can cause your robot's problems, including firmware, you just have to go through the checklist.

Where is Arduino Nano power coming from? They won't take 16-19VDC input. Their header's soldering is not the best, I would redo that assuming a female connector is there. What are the two boards, I know nothing about the H-bridge board underneath and the IC used.

You can try lower your PWM carrier frequency, what is it? Ensure your PWM software or the H-bridge driver has some deadtime (no overlap). EMI would be terribly high otherwise.

The Hall sensor's wiring can pick up EMI from the motor wires, which are in the same harness and really close.
I see the two 2.2k pullup resistors R3,R4 on one channel M2 but not the other M1? If you are using interrupts to deal with the encoders, the CPU can overrun with spurious interrupts due to EMI.

I would toss the tinfoil, and if you don't have a lot of time get some ferrite clamp-on cores and it's possibly the motor pair or the encoder quad (wires) in the harness I would experiment with using a core.

[Vovk_Z]

May be the problem is ground connected? (I mean somewere is "parasitic" ground connection, where it is not supposed by you).

[amyk]

Brushed DC motors generate plenty of EMI, especially if they're being run at higher voltages, due to the commutator sparking.

[OM222O]

As long as there is at least one reasonable chassis ground. A ground loop I would not worry about. The Arduino board needs its ground pour also going to a spacer bolt, I'd scrape off some solder mask on the top board or maybe a lockwasher does it.

There's many things that can cause your robot's problems, including firmware, you just have to go through the checklist.

Where is Arduino Nano power coming from? They won't take 16-19VDC input. Their header's soldering is not the best, I would redo that assuming a female connector is there. What are the two boards, I know nothing about the H-bridge board underneath and the IC used.

You can try lower your PWM carrier frequency, what is it? Ensure your PWM software or the H-bridge driver has some deadtime (no overlap). EMI would be terribly high otherwise.

The Hall sensor's wiring can pick up EMI from the motor wires, which are in the same harness and really close.
I see the two 2.2k pullup resistors R3,R4 on one channel M2 but not the other M1? If you are using interrupts to deal with the encoders, the CPU can overrun with spurious interrupts due to EMI.

I would toss the tinfoil, and if you don't have a lot of time get some ferrite clamp-on cores and it's possibly the motor pair or the encoder quad (wires) in the harness I would experiment with using a core.

I have checked each individual part, step by step and like I said, nothing helped the problem except the foil. if the code was the issue, then I'm not sure why it'd work with the foil but not without it?

The arduinos are powered from USB, currently my laptop and in the final product from a raspberry pi. The H bridge is the MDD10A like I mentioned. I'm not sure about the exact schematics and I don't really want to reverse engineer everything. The PWM frequency is 62.5KHz (by changing the prescalar of timer 0). This is the only setting that would allow for higher than 40KHz frequency which is chosen to quiet down the motor noises and coil whine. I don't have an scope to directly probe the outputs of the H bridge to see if there are dead times or not, but it uses PWM + DIR mode, so there's nothing in my code which can ensure that, I don't think so at least!

When it comes to the wires being too close, I agree. They really should have used separate connectors for power and logic, but there is no feasable way for me to do that myself. as you can see they have a PCB which is directly soldered to the motor terminals and the small 6 pin header is also soldered to it. I do have 2K pullups for each phase of both motors, but since it was easier for layout reasons (the connectors on each side are mirrored) I put the left hand side resistors on the bottom layer.

I am using interrupts and yes before adding the foil, sometimes the count would reset from 10000 to like 68 which I assumed is due to emi, and adding foil seemed to really help fix that.

Do I have to cover the entire distance of the cable with ferrite cores or just one per pair? or maybe one for the whole thing?

[OM222O]

Brushed DC motors generate plenty of EMI, especially if they're being run at higher voltages, due to the commutator sparking.

Is there a way to reduce that? or at least stop it from leaking out?

[madires]

Maybe a monolithic or X2Y EMI filter for the DC motors?

[OM222O]

Maybe a monolithic or X2Y EMI filter for the DC motors?

Would that be helpful at the H bridge end? I'm guessing not but I'm not sure
Also is that the same idea as applying 10nF caps between the grounded chassis and each terminal?

[phil from seattle]

One of the problems with directly connecting to the encoders is those wires are antennas creating path for emi to enter the arduinos.  You could try a low pass RC filter per input - resistor and cap, cheap. Pick a cutoff frequency that is, say, twice your max frequency. Even better would be to use opto isolators and completely isolate your arduinos.

I agree with the ferrite suggestions above. Worth a try. You can never have too much EMI supression.

Shielded wiring is worth investing in. Make sure it's a star grounded configuration.

Eventually, you will need to get your power sorted out and filtered.

[madires]

Would that be helpful at the H bridge end? I'm guessing not but I'm not sure
Also is that the same idea as applying 10nF caps between the grounded chassis and each terminal?

No, they should be placed at the EMI source, i.e. at the DC motor. The idea is similar but they comprise two Y caps and one X cap in one package, and provide better performance.

[OM222O]

Would that be helpful at the H bridge end? I'm guessing not but I'm not sure
Also is that the same idea as applying 10nF caps between the grounded chassis and each terminal?

No, they should be placed at the EMI source, i.e. at the DC motor. The idea is similar but they comprise two Y caps and one X cap in one package, and provide better performance.

As you can see from the motor pictures that's not really possible. I will have a go at using the aluminized mylar + ferrites to see if that'd help. Will try the capacitors to chassis as well.

[da075]

Hello,

2) the main problem is that aluminium oxidizes and so gives no good contact between the layers. Assuming the EMI source is the motor and leaves the motor housing by the wires you might want to short it back to the motor housing before it spreads over your whole cirquit. So with a better conducting material you might have luck by contacting the shield back to the motor housing (and or to the metal plate below the PCBs). Yes there are EMI-Shields for this purpose but they are not cheap.

1) a 10-100nF capacitor across the terminals might help somewhat. But it is also possible that the H-bridge cannot handle capacitive loads. You need a path back to the motor housing. So additional to the 10-100nF across the pins you need 2 * 1-10 nF from the pins to the motor housing to prevent the EMI getting from the motor to the motor supply lines. Another possibility to prevent leaving the EMI from the motor housing would be adding some inductivity 10-470uH or EMI-Ferrites into the supply lines close to the motor pins.

3) This will most probably not help as there are already some capacitors. What I would try is a 1-10nF capacitor between reset and ground pin of the processor (shortest possible connection).

with best regards

Andreas

Did you rule out reasons other than EMI? EMI may not be the main culprit. if not, make sure that the AC adapter is capable of delivering what it is rated at. so check the voltage at the output and see if it is dropping when the motors are turning, and see how much current is being drawn. also check if your system vibrates when the motors are running, you might want to ensure that all wiring remains well connected.

[floobydust]

H-bridge MDD10A is rated 20kHz max. and you are running it at 62.5kHz, did you check this is going to work without shoot-through currents generating high level EMI? 

As I mentioned, you can be accidentally generating a lot of EMI in hardware or software and instead of a shielding goose chase, I always start with getting the generated EMI low as possible. I know the foil gives sorta a fix but it's not going to be reliable and there will be drama at higher motor currents. It's just showing there is a relationship between the motor and encoder wiring. The motor wiring is terrible, using low current 22AWG wire and JST connectors running alongside the encoder signals- not a good design to begin with.

Without a scope it's pure guessing if the EMI source is the PWM carrier or the motor brushes or on the power supply. The susceptible EMI receiver may be the encoder and MCU inputs. Without any test equipment, you're going to have to guess and try things.

Capacitors at the motor are best to deal with EMI from the brushes. It's just three say 22nF parts soldered in free air right at the motor's terminals. For ferrite clamp-on cores, put either the two motor wires or the five encoder wires inside and clip together, as a common-mode filter for RF frequencies.  It's just one bead, not along the entire cable run.

[bob91343]

Too many replies, so I only browsed.  However EMI comes in two flavors, conducted and radiated.  And it you have it, the source may be external or internal.

So it needs to be categorized.  If a device is amplifying a signal then its input must be well defined.  Ground is not ground because it's different everywhere and should never be relied upon to conduct signals or power.  All need separate returns.

If the problem is radiated, shielding can help.  A good approach is to run power leads in pairs, hot and return, twisted, and inside a shield that is connected to a frame at one point only.

Sometimes slipping a ferrite core over a cable can make a big difference.  My experience with bypass capacitors has been poor to mixed.

If you have EMI, is it a steady signal or just transient?  You need to learn more about it in order to suppress it.

[OM222O]

H-bridge MDD10A is rated 20kHz max. and you are running it at 62.5kHz, did you check this is going to work without shoot-through currents generating high level EMI? 

As I mentioned, you can be accidentally generating a lot of EMI in hardware or software and instead of a shielding goose chase, I always start with getting the generated EMI low as possible. I know the foil gives sorta a fix but it's not going to be reliable and there will be drama at higher motor currents. It's just showing there is a relationship between the motor and encoder wiring. The motor wiring is terrible, using low current 22AWG wire and JST connectors running alongside the encoder signals- not a good design to begin with.

Without a scope it's pure guessing if the EMI source is the PWM carrier or the motor brushes or on the power supply. The susceptible EMI receiver may be the encoder and MCU inputs. Without any test equipment, you're going to have to guess and try things.

Capacitors at the motor are best to deal with EMI from the brushes. It's just three say 22nF parts soldered in free air right at the motor's terminals. For ferrite clamp-on cores, put either the two motor wires or the five encoder wires inside and clip together, as a common-mode filter for RF frequencies.  It's just one bead, not along the entire cable run.

I should probably RTFM but it never occurred to me that an H bridge has a "maximum frequency", at least not down in the tens of kilohertz range at least. For future iteration I most likely will switch to an H bridge which I designed myself, as well as a teensy 3.6 so I can just use one micro for the entire motion controller. For now reducing the PWM down to 7.8KHz (Arduino has no inbetween, it's either 62.5K or 7.8K because the prescaler is just weird like that), Shielding the power lines in aluminized mylar + using ferrite beads (4 encoder wires separately and one over the shielded power lines for good measure) seems to have stabilized everything and like others mentioned, without proper testing equipment (university is closed due to human malware) I can't really pinpoint the source of the EMI to try and correct for that.

The motor wiring is terrible, using low current 22AWG wire and JST connectors running alongside the encoder signals- not a good design to begin with.

And yes, I definitely agree the design is quiet horrible but unfortunately I really don't have another option as the entire robot was designed based on  these specific motors and wheels which came as a set and for the time being I just have to make things work in a pinch.