Super-slow I2C edges?

I2C is a protocol I use reluctantly but sometimes the client wants it or there is no other chip. AFAIR if you go above 1usec slew rate for slow mode trouble can brew. You could vet every single I2C device on that bus as to whether it can tolerate slow slew, which usually means lengthy conversations with app engineers. The alternative would be circuitry that squares things up at either side.

Can you leave the signals square enough and go differential for less crosstalk? Then you can also have proper RF termination on the lines which reduces crosstalk even more. Maybe a PCA9615 could be used but it's pricey:

Most modern I2C devices can tolerate slow edges, they use internal schmitt triggers on data and clock inputs. Check the datasheets for maximum slew rate. Hoewever, lots of modern devices use the SMB standard that communicates though I2C but has internal timeout guarding in each chip. Making the transfers too slow causes the devices to go off-line during the transfer.

Arie de Muijnck

A modulated i2c isolator will round off the rise-time, it looks like maybe the switch on the other side isn't hard on-off but opened somewhat gradually by integrating the RF carrier across the barrier so the time delay isn't so bad, see page 12:

That concept in itself without the perhaps unnecessary isolation might be viable for a predictable edge-slower-downer.

I believe the I2C spec say max 1us for <400kHz standard mode

afair the timeut on SMB is ~35ms, so it would have to be very slow

Chips with schmitt trigger inputs don't care.

Phil mentioned 1 kHz, that is max 35 bit messages - close...

Arie

Spec is maximum 1us tr and 300ns tf for standard mode,

300ns for both in fast mode and 120ns for both in fast mode+.

I would try a C and/or an RC. The pullup R should work for the high-rising R. So a small-ish buildout-R from each open collector data-clock pin and then put the C in the middle to GND maybe ?

I would see how slow you can make it work and then back-off 2 or 3 (or more ?) times to make sure it works in production ?

Just a suggestion. I have to sometimes use an R-C in noisy environments to be able to receive logic signals over a back-plane and that seems to work well for that. But that is not I2C.

2-3 times is a good margin but it can backfire when the same device from another mfg is used or the original mfg does a redesign.

A really tough one I experienced: A FET was in a 12V circuit. Vgs spec'd at +/-20V so all was fine. Then a mfg decided to protect the gate and added in zeners. They changed the datasheet but not (!) the part number. Then new Vgs spec was +/-8V and ... poof ... pop ... poof ... bang ...

Then there was an n-channel FET a long time ago that had a p-channel sibling which shared its name. Forgot which one but that almost tripped me up.

Maybe. My interest is mainly in belt 'n' suspenders, where we don't push fast edges any closer to signal paths than necessary.

The present gizmo has a Sensirion SHTC3 T/H sensor, which needs Fast I2C speeds; an AD5273 dpot, whose datasheet per usual AD practice is nearly completely vague about timing; and an LTC2633 DAC, which is almost as persnickety as the SHTC3.

So I suppose we'll have to suck it and see at normal bus speed.

Humph.

Phil Hobbs

A 10 kHz sine wave has 50 us transition.

A receiver comparator is essentially a high gain linear amplifier. which is finally driven into saturation. With slow edges, the amplifier remains a longer time in the linear region. If the line source impedance is high, external noise may drive the amplifier multiple times into saturation, generating a sequence of pulses before the final transition. For instance a line driver with neither transistor is active ON during the transition and the line is floating is sensitive to this.

A high gain linear amplifier with some unknown resistances and capacitances at input might even start an oscillation during the slow transition, generating multiple pulses. Thus, designing an RC filter to slow down the signal can be a bit problematic. Perhaps an R/C/R might be useful, so that the amplifier doesn't directly see the capacitance, which with some amplifier topologies could cause oscillation.

I guess that one reason for the relatively fast transition specification is to avoid problems with oscillations if the input remains a long time in the linear transition area.

Of course, using positive feedback (Schmitt trigger) reduces much of these problems.

The Sensirion SHT protocol is not completely compatible with the I2C specification.

I used a SHT11 in an industrial product and it had a tendency to lock up. The only resolution to it was to add a power supply switch to the SHT and temporarily switched off the supply when the sensor locked up.

We always do that anyway. ;)

Thanks

Phil Hobbs

This sounds very sensible. If you've got sensors that can be messed up by electromagnetic interference, hooking them with a noisy signalling system isn't clever.If you can buy a systems that sends balanced signal that spreads out a lot less electromagnetic noise it has to be the way to go.

LVDS is nice that way, but it's rather more than you need.

Yup, if stuck with fast mode for even one device the goose is cooked :-(

Even if the manufacturer would say "it usually works slower as well" I would not count on it unless it's in writing. And still things can go south, like when they transfer production to a new process where all the datasheet values are still maintained but now it doesn't like slow transitions anymore.

You can say that out loud :-)

That is one of the reasons why I do not use I2C in designs unless I have to. For me, having to power-cycle a device does not instill confidence in its design.

Now I have that with a little ArchLinux ARM box but at least that one isn't mision critical. Every few days or sometimes weeks it hangs up. It disappears from the LAN, no more ssh, nada, zilch. Only a power cycle gets it going again. Looking in the log afterwards there is no smoking gun anywhere. So I guess that'll need a nightly re-boot as a cron job. Harumph!

There are isolators that are designed for I2C use, on the most recent persnickety data acquisition system I designed them in for full galvanic isolation, but maybe they'd help even without that. Might be cheap insurance to plop them down on the board with bypass 0Rs

I would not worry too much about the i2c edges, I don't think you will have much of an issue because of them. The rising edge is slow enough anyway - just turning off open drain outputs, the falling edge is limited only by the channel resistance but still probably no point limiting that current either, unless you cannot separate well the current paths you don't want to disturb from those of the i2c line. Now upsetting the i2c line is not that impossible as I have managed once (a nearly 100V flyback primary close enough to the i2c line, about 1mm IIRC).

Dimiter

====================================================== Dimiter Popoff, TGI

Adding around 50 to 100 ohms series resistance to sda and scl on each device can be useful in slowing the fall time. The i2c specification discusses this. Another way of improving performance is to make the bus linear without any branches. With a linear bus, the impedance seen by any particular device will be around 50 ohms if each conductor has a characteristic impedance of 100 ohms. If there are branches the impedance will be lower, so there will be more current flowing on the falling edge (for long buses). Being at the end of a linear bus is best for low noise as the impedance is higher than anywhere else. I have found that i2c works very well up to more than 10m when treated as a linear transmission line, especially with constant(ish) current pullup and series resistors on each device.

John

I agree with everything you say of course, I just don't expect limiting the current for the falling edge to be that necessary. It may turn out to be of course, just my feeling at the moment. Typically currents through the power/gnd pins of the digital parts, I2C peripherals included, are likely to have a much bigger role to play. But one never knows - until the product is finished, as we all know all too well.

Dimiter

====================================================== Dimiter Popoff, TGI