Clifford Heath wrote...> > Winfield Hill wrote: >> >> I miss-spoke, we're using an Atmel ARM SAM D21. > >> but datasheet says the I2C outputs have reduced >> slew-rates. Hmm, the IO spec says 20-50ns with >> a 10 to 400pF load. > > Presumably the slew-rate limiting depends on the > selected data rate, but the data sheet is pretty > quiet on that.Here's their spec, fall time, for 0.7 to 0.3 Vdd: typ max Standard/Fast 20 50 ns Fast Mode + 15 50 High Speed Mode 10 40 Yes, it changes with speed setting, but not much. Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns. I = C dV/dt, with 75pF, that's i = 5mA, during a 50ns transition. This is what can kill using twisted-pair wires in a short USB cable. If we have 75pF crosstalk with a 200pF load, that's still a 28% Vdd interference signal, which is smack on the 30% trouble threshold. Why only slow to a fast 50ns transition with a 10us bit interval? That's only 0.5%. That's why I made more changes and added extra stuff. -- Thanks, - Win
I2C cable
Started by ●May 10, 2019
Reply by ●May 11, 20192019-05-11
Reply by ●May 11, 20192019-05-11
On 12/5/19 12:13 pm, Winfield Hill wrote:> Clifford Heath wrote... >> >> Winfield Hill wrote: >>> >>> I miss-spoke, we're using an Atmel ARM SAM D21. >> >>> but datasheet says the I2C outputs have reduced >>> slew-rates. Hmm, the IO spec says 20-50ns with >>> a 10 to 400pF load. >> >> Presumably the slew-rate limiting depends on the >> selected data rate, but the data sheet is pretty >> quiet on that. > > Here's their spec, fall time, for 0.7 to 0.3 Vdd: > > typ max > Standard/Fast 20 50 ns > Fast Mode + 15 50 > High Speed Mode 10 40 > > Yes, it changes with speed setting, but not much. > Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns. > I = C dV/dt, with 75pF, that's i = 5mA, during > a 50ns transition. This is what can kill using > twisted-pair wires in a short USB cable. If we > have 75pF crosstalk with a 200pF load, that's > still a 28% Vdd interference signal, which is > smack on the 30% trouble threshold. Why only > slow to a fast 50ns transition with a 10us bit > interval? That's only 0.5%.Hmm, good numbers. I guess it was a cost justification. Slow slew would need a bigger capacitor, and/or paralleled strong and weak output devices - but they're probably just re-using some pin driver from elsewhere. I wonder if any variable-slew chip parallels output devices, using the weak ones to slew and (time delayed) the strong ones to drive/clamp the line.
Reply by ●May 12, 20192019-05-12
On Saturday, May 11, 2019 at 10:14:01 PM UTC-4, Winfield Hill wrote:> Clifford Heath wrote... > > > > Winfield Hill wrote: > >> > >> I miss-spoke, we're using an Atmel ARM SAM D21. > > > >> but datasheet says the I2C outputs have reduced > >> slew-rates. Hmm, the IO spec says 20-50ns with > >> a 10 to 400pF load. > > > > Presumably the slew-rate limiting depends on the > > selected data rate, but the data sheet is pretty > > quiet on that. > > Here's their spec, fall time, for 0.7 to 0.3 Vdd: > > typ max > Standard/Fast 20 50 ns > Fast Mode + 15 50 > High Speed Mode 10 40 > > Yes, it changes with speed setting, but not much. > Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns. > I = C dV/dt, with 75pF, that's i = 5mA, during > a 50ns transition. This is what can kill using > twisted-pair wires in a short USB cable. If we > have 75pF crosstalk with a 200pF load, that's > still a 28% Vdd interference signal, which is > smack on the 30% trouble threshold. Why only > slow to a fast 50ns transition with a 10us bit > interval? That's only 0.5%. That's why I made > more changes and added extra stuff.I don't follow your crosstalk analysis. You are assuming your load is purely capacitive. But your load includes resistance as well. That means you need to factor in the frequency aspect of your signal slew rate so the total effect of capacitance and resistance can be understood. Or are you sure your resistive load is of no consequence? With such slow edge rates I'm not sure that would be valid. I suppose a simulation would be easy enough. -- Rick C. +- Get a 1,000 miles of free Supercharging +- Tesla referral code - https://ts.la/richard11209
Reply by ●May 12, 20192019-05-12
On a sunny day (11 May 2019 19:13:48 -0700) it happened Winfield Hill <hill@rowland.harvard.edu> wrote in <qb7vgs02cif@drn.newsguy.com>:>Clifford Heath wrote... >> >> Winfield Hill wrote: >>> >>> I miss-spoke, we're using an Atmel ARM SAM D21. >> >>> but datasheet says the I2C outputs have reduced >>> slew-rates. Hmm, the IO spec says 20-50ns with >>> a 10 to 400pF load. >> >> Presumably the slew-rate limiting depends on the >> selected data rate, but the data sheet is pretty >> quiet on that. > > Here's their spec, fall time, for 0.7 to 0.3 Vdd: > > typ max > Standard/Fast 20 50 ns > Fast Mode + 15 50 > High Speed Mode 10 40 > > Yes, it changes with speed setting, but not much. > Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns. > I = C dV/dt, with 75pF, that's i = 5mA, during > a 50ns transition. This is what can kill using > twisted-pair wires in a short USB cable. If we > have 75pF crosstalk with a 200pF load, that's > still a 28% Vdd interference signal, which is > smack on the 30% trouble threshold. Why only > slow to a fast 50ns transition with a 10us bit > interval? That's only 0.5%. That's why I made > more changes and added extra stuff.The rise - and falltime spec has little meaning, because the i2c system works differently. Data is sampled by the clock. As long as you wait long enough after each transition, data will be stable, and toggling the clock during stable data a million times due to oscillations in the transient will still read that data in correctly. I always do i2c in software. Some years ago I had this chip with a hardware i2c interface (was it a PIC? do not remember, yes I think it was), and a datasheet that sounded really funny to me. So did it in software as always and it worked perfectly Sure enough in the chip errata the i2c hardware interface was mentioned as erratic, and fixed. So here a 'shot' from a 2 channel i2c driver: http://www.panteltje.com/pub/iiclib.c Note the IIC_BUS_DELAY, it is defined in iiclib.h: #define IIC_BUS_DELAY 1 But you can make it as long as you want (in case of lots of cable capacitance), as long as transient oscillations are gone by the time you toggle the next I/O. That is why busdly(IIC_BUS_DELAY); is called afer each I/O pin change. In fact on a Linux multitasker usleep() can change a lot.... man usleep On embedded use a loop, example PIC 18F code, iicbus delay: iicdly: ; iic bus delay movlw D'225' movwf iic_delay_cnt iicdly_loop: decfsz iic_delay_cnt bra iicdly_loop return
Reply by ●May 12, 20192019-05-12
On a sunny day (Sun, 12 May 2019 07:10:51 GMT) it happened Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> wrote in <qb8gu6$lpf$1@dont-email.me>:> On a sunny day (11 May 2019 19:13:48 -0700) it happened Winfield Hill ><hill@rowland.harvard.edu> wrote in <qb7vgs02cif@drn.newsguy.com>: > >>Clifford Heath wrote... >>> >>> Winfield Hill wrote: >>>> >>>> I miss-spoke, we're using an Atmel ARM SAM D21. >>> >>>> but datasheet says the I2C outputs have reduced >>>> slew-rates. Hmm, the IO spec says 20-50ns with >>>> a 10 to 400pF load. >>> >>> Presumably the slew-rate limiting depends on the >>> selected data rate, but the data sheet is pretty >>> quiet on that. >> >> Here's their spec, fall time, for 0.7 to 0.3 Vdd: >> >> typ max >> Standard/Fast 20 50 ns >> Fast Mode + 15 50 >> High Speed Mode 10 40 >> >> Yes, it changes with speed setting, but not much. >> Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns. >> I = C dV/dt, with 75pF, that's i = 5mA, during >> a 50ns transition. This is what can kill using >> twisted-pair wires in a short USB cable. If we >> have 75pF crosstalk with a 200pF load, that's >> still a 28% Vdd interference signal, which is >> smack on the 30% trouble threshold. Why only >> slow to a fast 50ns transition with a 10us bit >> interval? That's only 0.5%. That's why I made >> more changes and added extra stuff. > >The rise - and falltime spec has little meaning, because the i2c system works differently. > >Data is sampled by the clock. >As long as you wait long enough after each transition, data will be stable, >and toggling the clock during stable data a million times due to oscillations in the transient will still read that data in >correctly.Correction, maybe I spoke too soon, clock oscillations on edges may an have effect, but it never seems to happen with capacitive loads or any loads I have tried.
Reply by ●May 12, 20192019-05-12
On 11 May 2019 15:18:46 -0700, Winfield Hill <hill@rowland.harvard.edu> wrote:>Rick C wrote... >> >> Winfield Hill wrote: >>> Winfield Hill wrote... >>>> Lasse Langwadt Christensen wrote... >>>>> >>>>> the STM have programmable slewrate on the IOs >>>> >>>> Aha! I'll see if our programmer can activate that. >>> >>> I miss-spoke, we're using an Atmel ARM SAM D21. >>> Not sure if they have programmable slew rate, >>> but datasheet says the I2C outputs have reduced >>> slew-rates. Hmm, the IO spec says 20-50ns with >>> a 10 to 400pF load. Well, anyway, I've added a >>> resistor (100-ohm) in series with the I2C lines.A twisted pair typically has an impedance of 100-120 ohs and since the transmitter has some output impedance, a smaller resistor should be sufficient to match to the line impedance. A 100 ohm resistor in the transmitter line will also reduce the low state noise margin. If the current through the open drain pull-up resistot(s) is more than 4 mA, this will reduce the low state noise margin by 400 mV, so if a conventional TTL receiver is used, this will kill the noise margin completely. Using 47 ohm series resistor and limiting the drain resistor current to 2 mA and the loss of noise margin would be only 100 mV.>> >> That seems excessive. Even with a 20 ns rise time >> the round trip on a 1 meter cable is around half >> the rise time. I think the magic number to ignore >> reflections is for the rise time to be 6 times the >> round trip delay. The capacitance you can expect >> on this run would very likely put the rise time >> higher than this threshold so no further actions >> would be needed to prevent reflections. > > Yes, I agree, but my worry isn't so much about > reflections, as about crosstalk. If a fast SCL > falltime induces an SDA signal, apparently this > can cause trouble. Fix with slow falltimes.I do not understand this crosstalk objections if CAT5/6 cables are used, with one pair for SCL and other pair for SDA. After all in 100/1000BasetT Ethernet, the whole symbol time is 10 or 8 ns (not just rise/fall time) and these cables are specified for up to 100 m. Of course, i you have split pairs, such as running SDA and SCL in the same twisted pair, there are going to be problems.> >> Do you think your rise time will be less than >> 60 ns? > > Yes, according to the spec, without the resistor. > Well, OK, I do have an 74HC4052 channel switch > in series; it may be about 100 ohms at 3.3 volts.
Reply by ●May 12, 20192019-05-12
upsidedown@downunder.com wrote...> > Winfield Hill wrote: >> Rick C wrote... >>> Winfield Hill wrote: >>>> Winfield Hill wrote... >>>>> Lasse Langwadt Christensen wrote... >>>>>> >>>>>> the STM have programmable slewrate on the IOs >>>>> >>>>> Aha! I'll see if our programmer can activate that. >>>> >>>> I miss-spoke, we're using an Atmel ARM SAM D21. >>>> Not sure if they have programmable slew rate, >>>> but datasheet says the I2C outputs have reduced >>>> slew-rates. Hmm, the IO spec says 20-50ns with >>>> a 10 to 400pF load. Well, anyway, I've added a >>>> resistor (100-ohm) in series with the I2C lines. > > A twisted pair typically has an impedance of 100-120 > ohms and since the transmitter has some output > impedance, a smaller resistor should be sufficient > to match to the line impedance.Thanks for your calculations, thoughts and comments. I had to decide against CAT5 and twisted pair. I'm not trying to match impedances at my slow speeds, the 100-ohms is to slow falltime against 200pF of load.> [snip] If the current through the open drain pull-up > resistor(s) is more than 4 mA, this will reduce the > low state noise margin by 400 mV ...The pullup resistors are 10k to 3.3V and 10k to 1.8V, or about 0.5mA. So with 100 ohms that's 50mV, and adding my analog switch, that's 100mV. [Actually, the switch may be enough resistance, scope meas on Monday may show I can skip the 100-ohms.]> ... so if a conventional TTL receiver is used ...The drivers and receivers are all proper I2C, with (lousy) thresholds spec'd at 0.3 to 0.7 Vdd. For 3.3V that's 1.0V, for 1.8-volt devices, it's 540mV.>> Yes, I agree, but my worry isn't so much about >> reflections, as about crosstalk. If a fast SCL >> falltime induces an SDA signal, apparently this >> can cause trouble. Fix with slow falltimes. > > I do not understand this crosstalk objections if > CAT5/6 cables are used ...Sorry, I've been forced away from CAT5, and have selected flat six-wire cables on RJ12. But, yes, on opposite sides and separated by ground wires, there likely won't be any crosstalk. I'll make scope meas on Monday. If I leave a spot for 100 ohms on the PCB, it may be best to be 0 ohms. -- Thanks, - Win
Reply by ●May 12, 20192019-05-12
On 12/5/19 5:16 pm, Jan Panteltje wrote:> On a sunny day (Sun, 12 May 2019 07:10:51 GMT) it happened Jan Panteltje > <pNaOnStPeAlMtje@yahoo.com> wrote in <qb8gu6$lpf$1@dont-email.me>: > >> On a sunny day (11 May 2019 19:13:48 -0700) it happened Winfield Hill >> <hill@rowland.harvard.edu> wrote in <qb7vgs02cif@drn.newsguy.com>: >> >>> Clifford Heath wrote... >>>> >>>> Winfield Hill wrote: >>>>> >>>>> I miss-spoke, we're using an Atmel ARM SAM D21. >>>> >>>>> but datasheet says the I2C outputs have reduced >>>>> slew-rates. Hmm, the IO spec says 20-50ns with >>>>> a 10 to 400pF load. >>>> >>>> Presumably the slew-rate limiting depends on the >>>> selected data rate, but the data sheet is pretty >>>> quiet on that. >>> >>> Here's their spec, fall time, for 0.7 to 0.3 Vdd: >>> >>> typ max >>> Standard/Fast 20 50 ns >>> Fast Mode + 15 50 >>> High Speed Mode 10 40 >>> >>> Yes, it changes with speed setting, but not much. >>> Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns. >>> I = C dV/dt, with 75pF, that's i = 5mA, during >>> a 50ns transition. This is what can kill using >>> twisted-pair wires in a short USB cable. If we >>> have 75pF crosstalk with a 200pF load, that's >>> still a 28% Vdd interference signal, which is >>> smack on the 30% trouble threshold. Why only >>> slow to a fast 50ns transition with a 10us bit >>> interval? That's only 0.5%. That's why I made >>> more changes and added extra stuff. >> >> The rise - and falltime spec has little meaning, because the i2c system works differently. >> >> Data is sampled by the clock. >> As long as you wait long enough after each transition, data will be stable, >> and toggling the clock during stable data a million times due to oscillations in the transient will still read that data in >> correctly. > > Correction, maybe I spoke too soon, clock oscillations on edges may an have effect, > but it never seems to happen with capacitive loads or any loads I have tried.Reflections from inductive and/or delay-line loads, i.e. not properly terminated?
Reply by ●May 12, 20192019-05-12
On a sunny day (Sun, 12 May 2019 19:38:40 +1000) it happened Clifford Heath <no.spam@please.net> wrote in <AQRBE.46022$8B4.29667@fx02.iad>:>On 12/5/19 5:16 pm, Jan Panteltje wrote: >> On a sunny day (Sun, 12 May 2019 07:10:51 GMT) it happened Jan Panteltje >> <pNaOnStPeAlMtje@yahoo.com> wrote in <qb8gu6$lpf$1@dont-email.me>: >> >>> On a sunny day (11 May 2019 19:13:48 -0700) it happened Winfield Hill >>> <hill@rowland.harvard.edu> wrote in <qb7vgs02cif@drn.newsguy.com>: >>> >>>> Clifford Heath wrote... >>>>> >>>>> Winfield Hill wrote: >>>>>> >>>>>> I miss-spoke, we're using an Atmel ARM SAM D21. >>>>> >>>>>> but datasheet says the I2C outputs have reduced >>>>>> slew-rates. Hmm, the IO spec says 20-50ns with >>>>>> a 10 to 400pF load. >>>>> >>>>> Presumably the slew-rate limiting depends on the >>>>> selected data rate, but the data sheet is pretty >>>>> quiet on that. >>>> >>>> Here's their spec, fall time, for 0.7 to 0.3 Vdd: >>>> >>>> typ max >>>> Standard/Fast 20 50 ns >>>> Fast Mode + 15 50 >>>> High Speed Mode 10 40 >>>> >>>> Yes, it changes with speed setting, but not much. >>>> Slowest mode, dV/dt = 0.4 3.3V / 20ns = 66 mV/ns. >>>> I = C dV/dt, with 75pF, that's i = 5mA, during >>>> a 50ns transition. This is what can kill using >>>> twisted-pair wires in a short USB cable. If we >>>> have 75pF crosstalk with a 200pF load, that's >>>> still a 28% Vdd interference signal, which is >>>> smack on the 30% trouble threshold. Why only >>>> slow to a fast 50ns transition with a 10us bit >>>> interval? That's only 0.5%. That's why I made >>>> more changes and added extra stuff. >>> >>> The rise - and falltime spec has little meaning, because the i2c system works differently. >>> >>> Data is sampled by the clock. >>> As long as you wait long enough after each transition, data will be stable, >>> and toggling the clock during stable data a million times due to oscillations in the transient will still read that data in >>> correctly. >> >> Correction, maybe I spoke too soon, clock oscillations on edges may an have effect, >> but it never seems to happen with capacitive loads or any loads I have tried. > >Reflections from inductive and/or delay-line loads, i.e. not properly >terminated?Unless those take round the world trips those will be sufficiently attenuated after some short time. How fast can bees fly? Why be in a hurry? A fly is differrent those can be really fast ;-) But seriously, just use cable with individually screened pairs, like I used audio cable, if you want to cover a few meters. For more use special drivers if unidirectional (no checking of SDA pulldown). Else go optical. Optical fiber does not take that much space, is 'trickety proof, a PIC as i2c to optical interface, whatever. With wasps it would be easy, you give those individual stripes for different messages, and use a barcode scanner, training is needed. Other ideas ? ? ants?
Reply by ●May 12, 20192019-05-12
Martin Riddle wrote...> > On 11 May 2019, Winfield Hill wrote: > >> Mounted RJ45 connector, but too big, cable too >> stiff, unsure of how the shielded variant works. >> Went to smaller, simpler RJ12 instead. > > There is plenum rated cable, it does not outgas > when burning eg; low smoke. > PVC is not too good for outdoor use. > Might want to check for RoHS/REACH compliance, > that way you will not get the phthalates.Interesting points. The little RJ12 cable we're discussing is outside, totally outside. Outside of the hive, and outside of my beehiove monitor. If my beehive monitor goes up in flame, I'm sure it'll outgas! It probably makes phthalates too. Little RJ14 phone cables may not be happy with an extended season of sunlight, but the Amazon RJ12 data cables look like they're more robust. -- Thanks, - Win
