Super-slow I2C edges?

Post by Phil Hobbs
So we're building these reasonably-swoopy SiPM/MPPC/APD modules, and we
need to temperature-compensate the gain and dark current, as well as
keeping track of the relative humidity so we don't get condensation.
In the scheme of things, this means running digital lines out to muxes,
dpots, DACs, and sensors. This version uses I2C for everything. Simon
has done I2C stuff many times, but I haven't--I've always gone straight
and used SPI. ;)
We want to round off the edges of the I2C control signals to reduce the
amount of hash getting into the signal path, but I'm not entirely sure
how far we can safely go with that. The data rate isn't a big issue--1
kHz with 50-us edges would be better than good enough--but I2C is fairly
famous for gotchas, many of which are far from obvious.
Any experience doing this?

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:

https://www.nxp.com/docs/en/data-sheet/PCA9615.pdf

--
Regards, Joerg

http://www.analogconsultants.com/

Phil Hobbs

2021-04-08 03:30:47 UTC

Post by Phil Hobbs
So we're building these reasonably-swoopy SiPM/MPPC/APD modules, and
we need to temperature-compensate the gain and dark current, as well
as keeping track of the relative humidity so we don't get condensation.
In the scheme of things, this means running digital lines out to
muxes, dpots, DACs, and sensors. This version uses I2C for
everything. Simon has done I2C stuff many times, but I haven't--I've
always gone straight and used SPI. ;)
We want to round off the edges of the I2C control signals to reduce
the amount of hash getting into the signal path, but I'm not entirely
sure how far we can safely go with that. The data rate isn't a big
issue--1 kHz with 50-us edges would be better than good enough--but
I2C is fairly famous for gotchas, many of which are far from obvious.
Any experience doing this?

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. 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

Tauno Voipio

2021-04-08 09:09:36 UTC

Post by Phil Hobbs
So we're building these reasonably-swoopy SiPM/MPPC/APD modules, and
we need to temperature-compensate the gain and dark current, as well
as keeping track of the relative humidity so we don't get condensation.
In the scheme of things, this means running digital lines out to
muxes, dpots, DACs, and sensors. This version uses I2C for
everything. Simon has done I2C stuff many times, but I haven't--I've
always gone straight and used SPI. ;)
We want to round off the edges of the I2C control signals to reduce
the amount of hash getting into the signal path, but I'm not entirely
sure how far we can safely go with that. The data rate isn't a big
issue--1 kHz with 50-us edges would be better than good enough--but
I2C is fairly famous for gotchas, many of which are far from obvious.
Any experience doing this?

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. 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

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.

--
-TV

Phil Hobbs

2021-04-08 13:05:46 UTC

Post by Tauno Voipio

Post by Phil Hobbs
So we're building these reasonably-swoopy SiPM/MPPC/APD modules, and
we need to temperature-compensate the gain and dark current, as well
as keeping track of the relative humidity so we don't get condensation.
In the scheme of things, this means running digital lines out to
muxes, dpots, DACs, and sensors. This version uses I2C for
everything. Simon has done I2C stuff many times, but I
haven't--I've always gone straight and used SPI. ;)
We want to round off the edges of the I2C control signals to reduce
the amount of hash getting into the signal path, but I'm not
entirely sure how far we can safely go with that. The data rate
isn't a big issue--1 kHz with 50-us edges would be better than good
enough--but I2C is fairly famous for gotchas, many of which are far
from obvious.
Any experience doing this?

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. 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.

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

Joerg

2021-04-08 16:17:08 UTC

Post by Tauno Voipio

Post by Phil Hobbs
So we're building these reasonably-swoopy SiPM/MPPC/APD modules,
and we need to temperature-compensate the gain and dark current, as
well as keeping track of the relative humidity so we don't get
condensation.
In the scheme of things, this means running digital lines out to
muxes, dpots, DACs, and sensors. This version uses I2C for
everything. Simon has done I2C stuff many times, but I
haven't--I've always gone straight and used SPI. ;)
We want to round off the edges of the I2C control signals to reduce
the amount of hash getting into the signal path, but I'm not
entirely sure how far we can safely go with that. The data rate
isn't a big issue--1 kHz with 50-us edges would be better than good
enough--but I2C is fairly famous for gotchas, many of which are far
from obvious.
Any experience doing this?

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. 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.

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.

Post by Tauno Voipio

Humph.

You can say that out loud :-)

Post by Tauno Voipio
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. ;)

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!

--
Regards, Joerg

http://www.analogconsultants.com/

Spehro Pefhany

2021-04-08 16:31:29 UTC

On Wed, 7 Apr 2021 23:30:47 -0400, Phil Hobbs

Post by Phil Hobbs
So we're building these reasonably-swoopy SiPM/MPPC/APD modules, and
we need to temperature-compensate the gain and dark current, as well
as keeping track of the relative humidity so we don't get condensation.
In the scheme of things, this means running digital lines out to
muxes, dpots, DACs, and sensors. This version uses I2C for
everything. Simon has done I2C stuff many times, but I haven't--I've
always gone straight and used SPI. ;)
We want to round off the edges of the I2C control signals to reduce
the amount of hash getting into the signal path, but I'm not entirely
sure how far we can safely go with that. The data rate isn't a big
issue--1 kHz with 50-us edges would be better than good enough--but
I2C is fairly famous for gotchas, many of which are far from obvious.
Any experience doing this?

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. 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

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

--
Best regards,
Spehro Pefhany

Dimiter_Popoff

2021-04-08 18:05:29 UTC

Post by Phil Hobbs
So we're building these reasonably-swoopy SiPM/MPPC/APD modules, and
we need to temperature-compensate the gain and dark current, as well
as keeping track of the relative humidity so we don't get condensation.
In the scheme of things, this means running digital lines out to
muxes, dpots, DACs, and sensors. This version uses I2C for
everything. Simon has done I2C stuff many times, but I haven't--I've
always gone straight and used SPI. ;)
We want to round off the edges of the I2C control signals to reduce
the amount of hash getting into the signal path, but I'm not entirely
sure how far we can safely go with that. The data rate isn't a big
issue--1 kHz with 50-us edges would be better than good enough--but
I2C is fairly famous for gotchas, many of which are far from obvious.
Any experience doing this?

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. 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

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 http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

John Walliker

2021-04-08 20:11:50 UTC

Post by Dimiter_Popoff
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).

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

Dimiter_Popoff

2021-04-08 21:13:34 UTC

Post by John Walliker

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 http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

Bill Sloman

2021-04-08 14:31:11 UTC

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
https://www.nxp.com/docs/en/data-sheet/PCA9615.pdf

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.

--
Bill Sloman, Sydney

Arie de Muijnck

2021-04-07 16:43:47 UTC

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

Lasse Langwadt Christensen

2021-04-07 18:50:36 UTC

Post by Arie de Muijnck

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.

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

Post by Arie de Muijnck
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.

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

Arie de Muynck

2021-04-07 21:32:28 UTC

Post by Lasse Langwadt Christensen

Post by Arie de Muijnck
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.

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

Chips with schmitt trigger inputs don't care.

Post by Lasse Langwadt Christensen

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

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

Arie

bitrex

2021-04-07 17:37:26 UTC

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:

<https://www.mouser.com/datasheet/2/368/Si860x-1666303.pdf>

bitrex

2021-04-07 17:40:54 UTC

Post by bitrex

Post by Phil Hobbs
So we're building these reasonably-swoopy SiPM/MPPC/APD modules, and
we need to temperature-compensate the gain and dark current, as well
as keeping track of the relative humidity so we don't get condensation.
In the scheme of things, this means running digital lines out to
muxes, dpots, DACs, and sensors. This version uses I2C for
everything. Simon has done I2C stuff many times, but I haven't--I've
always gone straight and used SPI. ;)
We want to round off the edges of the I2C control signals to reduce
the amount of hash getting into the signal path, but I'm not entirely
sure how far we can safely go with that. The data rate isn't a big
issue--1 kHz with 50-us edges would be better than good enough--but
I2C is fairly famous for gotchas, many of which are far from obvious.
Any experience doing this?
Thanks
Phil Hobbs

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
<https://www.mouser.com/datasheet/2/368/Si860x-1666303.pdf>

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

Spehro Pefhany

2021-04-07 23:07:25 UTC

On Wed, 7 Apr 2021 11:31:10 -0400, Phil Hobbs

Spec is maximum 1us tr and 300ns tf for standard mode,
300ns for both in fast mode and 120ns for both in fast mode+.

--
Best regards,
Spehro Pefhany

boB

2021-04-07 23:43:58 UTC

On Wed, 7 Apr 2021 11:31:10 -0400, Phil Hobbs

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.

Joerg

2021-04-08 03:07:17 UTC

Post by Spehro Pefhany
On Wed, 7 Apr 2021 11:31:10 -0400, Phil Hobbs

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.

--
Regards, Joerg

http://www.analogconsultants.com/

u***@downunder.com

2021-04-08 06:27:35 UTC