Go Down

Topic: Strong source of EM interference? (Read 1 time) previous topic - next topic

far_1

I'm having trouble with my electronics behaving strangely around EM sources, so in an attempt to make shielding i'd like to have a reliable source of strong EM interference.

To my knowledge, ballasts produce lot's of EM interference. Maybe a high voltage transformer or coil?
Somewhere around 60Hz noise would suffice and as high voltage as safely possible.

Grumpy_Mike

#1
Aug 22, 2015, 07:32 pm Last Edit: Aug 22, 2015, 07:32 pm by Grumpy_Mike
What we did back in the 60s to test equipment for RF immunity was to have a half horsepower motor with one wire connected to the mains. Then a hole was drilled in the plug so that the other mains connector could be contacted by pushing a round file in the hole. Then the other wire from the motor was stroked up and down the file causing sparks. We reckoned that if the circuit could survive that it would survive most things. The file did have a wooden handle and you kept your fingers away.

Quote
so in an attempt to make shielding
In my experience shielding seldom works and you are best to look for a cure with adequate decoupling in the circuit.

far_1

Seems a good idea. But i also agree with your last point. I did try to put some rudimentary shielding, but without any significant effect.
The situation is that i have a I2C sensor connected to the arduino, and each time i try to read it, while being exposed to the EM field...the whole system freezes. I've tried making the wires short, but still.
I had issues on different project before, where high EM fields caused resets.

I really have no clue why does it happen only when reading the sensor. I know for certain that EM fields in the range of 60Hz cause this, not sure about others. By decoupling you mean a classic low/high pass filter? Should i be putting it on the I2C bus lines?

jack wp

#3
Aug 22, 2015, 11:21 pm Last Edit: Aug 22, 2015, 11:33 pm by jack wp
Do you have resistors on the I2c wires? what value?

You may try some different value resistors (lower / higher). that may help.

Are the I2C device, and the Arduino using the same power supply? Add extra caps to the power supply rails may help.

How long is your I2C wires?

No, don't put the caps on the I2C bus.

What EM fields are causing the reset? radio transmitters, motors, etc.?

Grumpy_Mike

#4
Aug 22, 2015, 11:37 pm Last Edit: Aug 22, 2015, 11:37 pm by Grumpy_Mike
It is the lower values of I2C pull up resistor that might help.

Quote
By decoupling you mean a classic low/high pass filter?
No, put decoupling capacitors on the chips, do not add any capacitors to the two I2C lines, they will only degrade performance or stop it working.

For decoupling read this:-
http://www.thebox.myzen.co.uk/Tutorial/De-coupling.html

Paul__B

The first step in the process, is to ensure all connections are run in pairs; that you do not separate the two wires to any part of the circuit.

This includes wiring to sensors, wiring to actuators or indicators, and power wiring.  You should be using twin or possibly multi-core cable - four core for I2C.

This also implies that there are no ground "loops".

And you should have power bypass capacitors at the microprocessor if not already included.

Sensors should return to ground rather than Vcc.

far_1

#6
Aug 23, 2015, 02:31 am Last Edit: Aug 23, 2015, 02:35 am by far_1
The sensor and arduino use the same power source (battery). I did try USB but without any noticeable difference. I do however remember differences if i powered it trough my laptop or desktop USB.

As for cables, i don't know how could i have forgotten to mention, but yes i do have a 1,2m long UTP (unshielded, twisted pair) cable connecting a button with a pulled up digital input.
The main sensor was first connected trough a 80cm cable which caused immediate problems. I eventually moved the sensor directly on an arduino shield, so we're talking a few cm of wire.

The EM source is a spark gas igniter.

I wasn't paying attention back then, but a different sensor with different pullup resistors on the I2C did not cause issues despite the same setup (button cable, power, etc). Might really be worth a look.

I find it quite peculiar that unless i start reading from the sensor, everything works, even at close proximity to the EM source and no shielding on the rest of the components.

I'm speculating that when the I2C bus goes low, i.e. send data, the interference somehow gets on the line. I'm also guessing that I2C is directly connected to critical parts of the atmega, thus causing a freeze. I suspect the UTP cable dumps it's charge in the system spmehow.

I'll also put bigger caps near all components.

@Paul

I'm not sure what that technical phrase means...."return to ground rather than Vcc"? Since it's battery powered, all return are common (floating). Not chassis or ground.

Paul__B

I'm not sure what that technical phrase means...."return to ground rather than Vcc"? Since it's battery powered, all return are common (floating). Not chassis or ground.
You seem to have got it right in that respect.  I mean that you use buttons or whatever connected to ground, and you provide the pull-up to Vcc inside the Arduino or main circuit board.  You do not connect buttons or sensors to Vcc and use pull-downs.

Now - speaking of pull-ups - jack wp was a bit vague so that even I do not know just what he meant.  What pull-ups are you using on the I2C lines?  With this problem, you want to use fairly low values, perhaps 1.5k if such are not already built into the I2C sensor (and actually, they should not be as they are again, supposed to be at the Arduino "master" end).

The problem is that the I2C interface is "blocking" - it waits until the expected condition is fulfilled and if it is not fulfilled - due to a glitch on the line which interferes with and scrambles the protocol - well, it just waits forever!

Grumpy_Mike

What decoupling do you have on the sensor?

The key to RFI immunity IS decoupling.

far_1

I think i found the most probable suspect.

I've compared both sensors and what i found is shocking. (no pun intended)  :)

The previous one has 10k pullups, but it has a level converter from 3.3v to arduino native 5v on the I2C lines.
The new one uses 2.2k pullups but the I2C line is pulled up only to 3.3v...which makes me wonder how the hell did it even work, considering it's so close to the logic level. But still...it does work under normal conditions.

Should i McGyver an open loop op amp (since it's the only thing i've got at hand right now) to convert the the signals?

@Mike

There are only two decoupling caps at the power supply, 10uF and 2.2uF. But the sensor has a 5v to 3.3v regulator and a (i believe) tantalum cap after it.


aarg

Perhaps it is time to ask you for a photograph....
  ... with a transistor and a large sum of money to spend ...
Please don't PM me with technical questions. Post them in the forum.

far_1

I'm gonna first try to adjust the levels and then see where it goes from there.

Grumpy_Mike

Quote
Should i McGyver an open loop op amp (since it's the only thing i've got at hand right now) to convert the the signals?
That won't work as the I2C data signal is bidirectional.

What ever else you have as decoupling you need a 0.1uF ceramic capacitor to cope with the high frequencies 10uF and 2.2uF alone will not cut it.

I would also add another ceramic cap on each sensor.

jack wp

#13
Aug 24, 2015, 05:25 pm Last Edit: Aug 24, 2015, 05:41 pm by jack wp
There are some I2C slaves (sensors), that provide pullup resistors (They shouldn't). If you can locate them visually on the sensor board(s), you may be able to cut the trace to them. Then you can add your own pullup resistors to the line.

It may even be helpful, to put two pots on those lines, and adjust to find the best value under such hostile environments ( then maybe, replace with a normal resistor).

Quote from Paul_B:"The problem is that the I2C interface is "blocking""
This may be the case. It depends on the code. The code could have a timeout/or not.

 to test this theory, you can:

1. turn off the EM interference source. Does both slaves work as expected?
2. disconnect one slave. If the code is blocking, then the arduino should stop.

far_1

 :smiley-yell:

Sorry to revive an old thread...but it's a heads up. Just today i inadvertently realized what might have been the cause for my problem back then. As stated, the sensor was running on 3.3V, the Arduino on 5V.....WITH the internal pullu-ps still enabled. So i was pulling up the whole line...and possibly even damaged the poor thing (sensor).

Go Up