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 -- 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 7, 20212021-04-07
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.pdf -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●April 7, 20212021-04-07
On 2021-04-07 17:31, 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? > > Thanks > > Phil Hobbs >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
Reply by ●April 7, 20212021-04-07
On 4/7/2021 11: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? > > 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 delay isn't so bad, see page 12: <https://www.mouser.com/datasheet/2/368/Si860x-1666303.pdf>
Reply by ●April 7, 20212021-04-07
On 4/7/2021 1:37 PM, bitrex wrote:> On 4/7/2021 11: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? >> >> 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 > delay isn't so bad, see page 12: > > <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.
Reply by ●April 7, 20212021-04-07
onsdag den 7. april 2021 kl. 18.43.57 UTC+2 skrev Arie de Muijnck:> On 2021-04-07 17:31, 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? > > > > Thanks > > > > Phil Hobbs > > > 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> 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
Reply by ●April 7, 20212021-04-07
On 2021-04-07 20:50, Lasse Langwadt Christensen wrote:> onsdag den 7. april 2021 kl. 18.43.57 UTC+2 skrev 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 modeChips with schmitt trigger inputs don't care.>> 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 slowPhil mentioned 1 kHz, that is max 35 bit messages - close... Arie
Reply by ●April 7, 20212021-04-07
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 HobbsSpec 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
Reply by ●April 7, 20212021-04-07
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 HobbsI 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.
Reply by ●April 8, 20212021-04-08
On 4/7/21 4:43 PM, boB wrote:> 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 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/
