Joerg wrote:> On 4/7/21 8:31 AM, Phil Hobbs wrote: >> 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 -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Super-slow I2C edges?
Started by ●April 7, 2021
Reply by ●April 8, 20212021-04-08
Reply by ●April 8, 20212021-04-08
On Wed, 7 Apr 2021 11:31:10 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:>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 HobbsA 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.
Reply by ●April 8, 20212021-04-08
On 8.4.2021 06:30 AM, Phil Hobbs wrote:> Joerg wrote: >> On 4/7/21 8:31 AM, Phil Hobbs wrote: >>> 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 HobbsThe 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
Reply by ●April 8, 20212021-04-08
Tauno Voipio wrote:> On 8.4.2021 06:30 AM, Phil Hobbs wrote: >> Joerg wrote: >>> On 4/7/21 8:31 AM, Phil Hobbs wrote: >>>> 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 -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●April 8, 20212021-04-08
On Thursday, April 8, 2021 at 2:40:07 AM UTC+10, Joerg wrote:> On 4/7/21 8:31 AM, Phil Hobbs wrote: > > 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.pdfThis 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
Reply by ●April 8, 20212021-04-08
On 4/8/21 6:05 AM, Phil Hobbs wrote:> Tauno Voipio wrote: >> On 8.4.2021 06:30 AM, Phil Hobbs wrote: >>> Joerg wrote: >>>> On 4/7/21 8:31 AM, Phil Hobbs wrote: >>>>> 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.>>> Humph. >You can say that out loud :-)>> >> 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/
Reply by ●April 8, 20212021-04-08
On Wed, 7 Apr 2021 23:30:47 -0400, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:>Joerg wrote: >> On 4/7/21 8:31 AM, Phil Hobbs wrote: >>> 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 HobbsThere 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
Reply by ●April 8, 20212021-04-08
On 4/8/2021 6:30, Phil Hobbs wrote:> Joerg wrote: >> On 4/7/21 8:31 AM, Phil Hobbs wrote: >>> 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/
Reply by ●April 8, 20212021-04-08
On Thursday, 8 April 2021 at 19:05:35 UTC+1, Dimiter Popoff wrote:> 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
Reply by ●April 8, 20212021-04-08
On 4/8/2021 23:11, John Walliker wrote:> On Thursday, 8 April 2021 at 19:05:35 UTC+1, Dimiter Popoff wrote: > >> 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 >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/
