MOD-IO I2C random resets and becomes unreachable

[tet88]

Hi,

So we have the following setup:
1 RaspberryPI 2 B
10 MOD-IO (addressed in RaspPI from 0x60 to 0x69 with I2C SMBUS)
3 UEXTx5
1 RPi-UEXT

which are all connected.
From each MOD-IO we use A DigitalIn Port(12VDC) and 3 Relays(24VAC). We use BAUDRATE = 50000 before communicating with the MOD-IOs.

The setup works great until it doesn't. We get random Write/Read errors from MOD-IO while trying to engage with the relays or the DigitalIN.
We get "could not communicate with device errors" and "i2cdetect -y 1" shows one or multiple addresses missing from the list(10 addresses) and the Status Led on the MOD-IO is not blinking anymore.

At one point, after this happens, in some cases trying againg "i2cdetect -y 1" will show up the full list(all 10 addresses) and the MOD-IO board Status LED starts blinking again.

We also use https://github.com/ccontavalli/python-olimex-modio for interacting with the MOD-IO.

Any ideas or advice on what we can do in order to avoid getting the MOD-IO board disconnected?

Thank you!

[kyrk.5]

Is there any load on the relays? How much current is switch by the relays?

Is it working better on lower baudrates?

[tet88]

Yes there is load on the relays:
- 1 Relay is connected to a electrovanne with 370 mA inrush, 210 mA holding
- 1 Relay is connected to a electrovalve with 400mA
- 1 Relay is connected to 2 LEDs(one on NC and one on NO) with 15-20mA each

We haven't tried a lower baud rate but we'll give it a go.

[JohnS]

Probably noise.  Electrical or RFI/EMI.

Try  a fast storage scope to see it.

Use shielding, suppressors, etc.

John

[kyrk.5]

Try the stuff without any kind of load. If the problem solves than some filtering on the Relay is needed. Probably on the switch side, some kind of RC or Varistor or Suppressor.

[tet88]

We've tested the the configuration without load for more than 48 hours and it worked perfectly fine.
But now, when used in a real life scenario it give the errors I mentioned.

@JohnS The configuration is already in production and using fast storage scope is a little bit difficult to do.
@kyrk.5 do you mean something like the image below?

[kyrk.5]

"We've tested the the configuration without load for more than 48 hours and it worked perfectly fine.
But now, when used in a real life scenario it give the errors I mentioned."
Ok looks like the problem is really cause by the load. I guess when the relay contacts are connecting or disconnecting some arc/sparks is generated and that is causing the problem.

Yes I thing something like on the image. I was trying to find some web page where different snubber circuits are presented with some example measurements, but I did not found that page
They are different type of filtering:
- RC filter
- Didoe filter
- Varistor
- Some combination of the previous ones like RC filter + diode

Try different type of filtering, surly you will find one that is solving a problem. You can also verify this with some measurement in the circuit.

[tet88]

So I found the following:
https://www.ia.omron.com/support/faq/answer/36/faq02804/

and the most suitable option seems to be using the varistor across the load (because its powered with 24VAC):


Also, based on the suggestion in the link and other sources I've ordered some varistor for 40VAC and 50VAC max loads:
SIOV-S10K40 and SIOV-S10K50 http://www.datasheets360.com/pdf/8562338783424641623


We're also planning to try the baudrate to 40000 instead of 50000.

[kyrk.5]

"We're also planning to try the baudrate to 40000 instead of 50000."
I think lowering the baudrate will not help so much. When there is an arc during the switch of the relay it might generate some unwanted peaks and possible clk signals (even start or stop) in the I2C bus. I think this does not depend on the baud rate, the unwanted signals will be processed as previous.

My understanding is that the problem is caused by the Relay, that when switching some spark is generated. Hopefully a good chosen varistor will help. This you can measure out, by measuring the supply voltage, ground and I2C lines. How the device is exactly stopped, we do not know. Can be either due to a spike on the power line that is causing some unwanted resets or program code flow (is an AVR they told to be immune to such environments but who know) or maybe the I2C is just stucked somehow (missing or extra clock causing some problem, second start condition on the bus and possible error case in the SW that is not handled?). For the first assumption the baud rate change wont solve anything. For the second it might change the behaviour (fix it completely or just get it more randomly coming), combined with some extra Start and Stop on the I2C might also help.

[JohnS]

I take it that it's not just a relay but also has an appropriate diode?

John

[tet88]

Hi all,

So it would seem that the main problem was caused because we did not have a snubber on the circuitry. We are now testing a combination of snubbers(varistor, RC) for different MOD-IO devices and it seems that the resets are not happening anymore.

Thank you for all your replies!