How do I protect I2C from ESD?

[SlowBro]

Maybe instead I just opto-isolate it? Seems easier. Per this NXP document opto-isolated I2C can go up to 5 kHz with inexpensive parts. I've tested my design down to 100 Hz and while it takes 3 seconds to get a humidity reading that's perfectly tolerable.
 Here's a component with a 3us/2.3 turn on/off time, which should work well within the required 1ms rise time of a 100 Hz signal.

[SlowBro]

Nah, skip opto coupling. It also requires a buffer that would drive costs way up.

3.3V zener/TVS is a lie -- if you get a true 3.3V zener part, it's very leaky under 3.3V, and doesn't clamp any better than a 5V zener/TVS does (peak clamp voltage in the 8-10V range for both cases).  The only thing that can do 3.3V logic signals is a completely different component type, a snapback diode (which is actually a fast SCR structure).

Is this one any good? About leakage, the RPi can do up to 50mA per GPIO and this is 150uA @ 1V. How would I know the leakage at 3.3V?
http://www.onsemi.com/pub/Collateral/1N5333B-D.PDF

[SlowBro]

A higher value series resistor will increase the protection and the higher its peak voltage rating the better.  A 50 or 100 volt resistor is not going to do much for a 1000 volt ESD pulse when it flashes over.  Higher wattage resistors are higher voltage but they make special high voltage resistors also.  I would put series resistors on both sides of the shunt diodes.

Do you have some examples of high voltage resistors? The only way I can think to make it possible to handle a 1000V spike with a series resistor that's not gargantuan is with a 1G ohm (or thereabouts) 1W resistor, and if I do that I'll kill my signal levels (right?). That sounds like overkill in my (untrained and possibly incorrect) opinion.

FYI here is the current design.

[mikeselectricstuff]

I'm going to be using I2C with at least one 1m shielded cable
[/quote]
Don't.  Just don't.
I2C is not designed to go off board or down wires.

[SlowBro]

Don't.  Just don't.
I2C is not designed to go off board or down wires.

Understood, but I had seen plenty of examples where it was usable at 1m. What do you recommend instead?

[T3sl4co1l]

If your expectations are low, the cable shielding is good, and the signal filtering is good, I2C is okay here.

For anything that matters, I2C should stay on board only, or at worst, board-to-board connectors (with lots of ground pins in them).

SPI is better, because the signals never go open circuit (weak pullup).  You still need shielding.

SPI can be sent via RS-422 trivially: just add transmitters and receivers.  This is good enough that a shielded cable may not even be needed (you can get twisted pair ribbon cable, or all-weather CAT5 more likely here), though it's still better of course.

Most '422 devices include beefy ESD protection, too.

This thread is rather obsessive.  A single 1N5231B and series resistor will do more than good enough.  The original device isn't made of glass, it's got an ESD rating as well.  Whatever's left after the diode and resistor will be much less duration and energy, and that's what matters.  If a 10kV strike is effectively reduced to an equivalent 1kV or less, it won't die.  We're not dealing with 1970s metal gate CMOS, or teeny tiny RF transistors!

Tim

[SlowBro]

This thread is rather obsessive.

I was beginning to think that myself FYI the product is for hobby farmers and is not life-critical. If it fails I can ship a new one without much fuss. I'm just trying to cut down on warranty work.

[David Hess]

A higher value series resistor will increase the protection and the higher its peak voltage rating the better.  A 50 or 100 volt resistor is not going to do much for a 1000 volt ESD pulse when it flashes over.  Higher wattage resistors are higher voltage but they make special high voltage resistors also.  I would put series resistors on both sides of the shunt diodes.

Do you have some examples of high voltage resistors? The only way I can think to make it possible to handle a 1000V spike with a series resistor that's not gargantuan is with a 1G ohm (or thereabouts) 1W resistor, and if I do that I'll kill my signal levels (right?). That sounds like overkill in my (untrained and possibly incorrect) opinion.

The resistance value and wattage are not higher.  Just the peak voltage rating is higher so they can sustain high voltages and currents for short periods of time.  If you are looking for surface mount, then the Panasonic ERJ series "Anti-Surge Thick Film Chip Resistors" are an example.

[mikeselectricstuff]

For short distances, simple TTL UART works fine up to the same sort of speeds I2C can do. Ideally using a buffer type driver like HC541 or HC365, and 100R or so series terminantion at source. If you need protection angains connection to >5v, add a ~2K2 series R with 1nf across it, in series with the normal series termination resistor. 

The problem with I2C is it relies on a resistive pullup, so cable capacitance directly affects speed, and the resulting slow edges can make it very susceptible to noise.

[SlowBro]

The resistance value and wattage are not higher.  Just the peak voltage rating is higher so they can sustain high voltages and currents for short periods of time.  If you are looking for surface mount, then the Panasonic ERJ series "Anti-Surge Thick Film Chip Resistors" are an example.

Thank you, that makes a lot more sense. I was thinking, I know I'm a newbie, but...

I found that if in the Digikey parametric search I also include the search phrase "Pulse" I can see all of the pulse-withstanding resistors. I'll definitely be using those since they're only a few pennies more.

[SlowBro]

For short distances, simple TTL UART works fine up to the same sort of speeds I2C can do.

I found that the I2C speed of the temp/humidity sensor readings are acceptable down to 100 Hz so it should be able to tolerate all sorts of line abuse. And the need is only to get periodic temperature humidity readings; I can design in the software a rejection of bad readings and just try again. I think it'll be okay but if not I'll take your suggestion. I can stick an Atmega on the end by the sensor and talk at around 9600 baud.

[MarkL]

I found that the I2C speed of the temp/humidity sensor readings are acceptable down to 100 Hz so it should be able to tolerate all sorts of line abuse. And the need is only to get periodic temperature humidity readings; I can design in the software a rejection of bad readings and just try again. I think it'll be okay but if not I'll take your suggestion. I can stick an Atmega on the end by the sensor and talk at around 9600 baud.

There's no data integrity protection in the returned BME280 data or in the I2C protocol, so you might not be able to detect a bad bit depending on where it lands.  It might create crazy values, which is easy to spot, or it might change the temperature subtly by a couple of degrees.

One method would be to read the result registers twice between measurements (during Tstandby).  If the reads are identical you can be confident there were no transmission errors.

Also, the BME280 supports 3- or 4-wire SPI as well as I2C.  Just FYI, since T3sl4co1l brought up SPI.  I would still try slow I2C.  It should be fine.  If not, consider SPI before adding another processor to the mix.

[SlowBro]

A sticking point about using SPI is the module I bought is only wired up for I2C. I see on the datasheet that the same pins are used for both but because there are 10k pull-ups onboard I would think that rules out trying SPI mode.

I like your idea of doing two reads and comparing. There may be tiny variations that I can account for in code, but should not be wide swings. This should work fine.

[MarkL]

A sticking point about using SPI is the module I bought is only wired up for I2C. I see on the datasheet that the same pins are used for both but because there are 10k pull-ups onboard I would think that rules out trying SPI mode.

SPI mode is activated by pulling CSB low, once.  If you don't pull CSB low it stays in I2C mode.  The internal pullup is 120k (typ).  I guess you're referring to a 10k on an eval or carrier board?  Even if it's 10k, a processor can still pull it down to activate SPI mode, if that's your concern.

I like your idea of doing two reads and comparing. There may be tiny variations that I can account for in code, but should not be wide swings. This should work fine.

The idea would be to catch it *between* measurement updates, so that you're reading the same data out of the registers twice.  The data should be bit-for-bit identical since it has not been updated.

The chip measures the environment, writes the data to the result registers, and then goes back to sleep (the state they call Tstandby).  The result registers can be read as often as you like even if it's sleeping.

Alternatively, you can just continuously read the result registers at a rate of 3 or 4 times (or higher) than the update rate.  Any two back-to-back readings that are identical could constitute a valid reading.  The standby time is programmable from 0.5ms to 1sec.

You could also used "Forced" mode.  Here, you would trigger a measurement, wait for it to finish, and then read the result registers twice.  Having it synchronous like this may be easier to implement, but the spec sheet recommends free-running "Normal" mode if you are using the IIR filter (sec 3.3.4).

[David Hess]

For short distances, simple TTL UART works fine up to the same sort of speeds I2C can do. Ideally using a buffer type driver like HC541 or HC365, and 100R or so series terminantion at source. If you need protection angains connection to >5v, add a ~2K2 series R with 1nf across it, in series with the normal series termination resistor.

There are all kinds of ways to improve performance.

I am very leery of using LSI (large scale integration) for off board signals except within the same chassis simply because external drivers can be much more robust and may be replaceable.  For this reason if I did use an LSI signal directly, I would go heavy on the external protection network.

The problem with I2C is it relies on a resistive pullup, so cable capacitance directly affects speed, and the resulting slow edges can make it very susceptible to noise.

Replacing the resistive pullup with a current source pullup will improve the performance somewhat.

[T3sl4co1l]

Hehe, the unfortunate thing about LSI vs. drivers is -- to us it seems fine to buffer and isolate dirty outside signals from the sensitive inner bits, and we'd be perfectly okay with replacing a driver if that's all that's failed on a board.  Success, right?  Unfortunately: 1. a failure is a failure, and 2. the service tech is just going to swap the board anyway.  So who really gives a damn?

That said, you could get the best of one and a half worlds by placing the drivers/buffers/isolators on a sacrificial daughterboard.  Service tech pops in a new one, good to go.  There's still down time for the end user, but you get to keep your smug sense of efficiency.   Obvious downside: cost and space!

So of course -- when overall, end user, uptime, operational reliability, is tantamount: you have no choice but to belt-and-suspenders the interface, so it does not glitch or fault under adverse conditions.  Doesn't matter if the drivers or brains get fried, a fail is a fail.  Do whatever is necessary to maintain operation!  Drivers, filtering, whatever it takes.

Tim

[David Hess]

I have seen modern surface mount boards where the interface ICs were socketed DIPs at the edge of the board so they could be sacrificed and replaced.

As you point out, if the ESD protection shorts out the signal line, that is the same as a hard failure whether the driver or LSI logic is dead or not.  I have seen that happen with input protection circuits for RF inputs and oscilloscopes.