Forums

I2C cable

Started by Winfield Hill May 10, 2019
lørdag den 11. maj 2019 kl. 00.00.31 UTC+2 skrev Winfield Hill:
> jrwalliker@gmail.com wrote... > > > > On Friday, 10 May 2019, upsid...@downunder.com wrote: > > > >> After all, 100 kHz is a quite low frequency. > > > > But the falling edges can be fast enough for transmission line > > effects to be important when the cable is a few metres long. > > Double clocking due to reflections makes a mess of i2c. > > > > Using the lowest possible pullup resistors or using active > > pullup that approximates to a constant current clamped at > > Vcc can help with noise immunity in the high state. > > Right, John. Fast falling edges are worrisome. Even > more-so, as I'm driving I2C with a fast STM processor. I > regret my PCB doesn't have a place for source resistors, > or anything (in this rev anyway).
the STM have programmable slewrate on the IOs
Lasse Langwadt Christensen wrote...
> > the STM have programmable slewrate on the IOs
Aha! I'll see if our programmer can activate that. -- Thanks, - Win
On a sunny day (10 May 2019 07:09:13 -0700) it happened Winfield Hill
<hill@rowland.harvard.edu> wrote in <qb40m902842@drn.newsguy.com>:

>We need a 1-meter length of 100kHz (or slower) >I2C onnection. It'd be nice to use a pre-made >cable: micro-USB, 4-wire RJ11, or RJ45 ethernet. >Some considerations: SCL and SDA crosstalk(?), >high ground capacitance. Also need 3.3V, Gnd. > >Micro-USB: SCL and SDA twisted together, bad? >RJ11: flat, SCL and SDA on outside lines? >RJ45: SCL and SDA shielded from each other.
I have used i2c to drive announcement displays in an office building over hundreds of meters, using unshielded cable, ONE WAY, cable measured about 100 Ohm, used a fast able driver chip (was in the eighties cannot remember what chip) and drove clock and data with 100 Ohm. At home I had i2c bus coming from a 8052 micro 'as is' using 4 core individual shielded audio cable and 180 degrees DIN connectors. No problem even when I was running a 150W watts radio transmitters that would upset everything else around from TV to VHS recorder. Bus speed is not critical, normally you can slow down i2c if there is a lot of capacitance, But I would not, for a bidirectional setup with those simple pull-up resistors in the open, use unshielded cable, nearby cellphones can do bad things. Lightning..
On Saturday, May 11, 2019 at 3:10:59 AM UTC-4, Tim Williams wrote:
> "Rick C" <gnuarm.deletethisbit@gmail.com> wrote in message > news:0be3e775-67ce-4a39-891a-a2b9330fd7a5@googlegroups.com... > > > > I thought I had read the standard once some time ago and don't recall that > > it is intended to be sampled like a UART. Is that literally in the spec > > or does it say some amount of noise is to be rejected and not seen as a > > start condition or clock edge? > > > > It's been so long since I looked at the standard in that much detail. But > some kind of minor filtering is required. A digital filter would be a > typical implementation. > > If you have, say, MCU peripherals that require fairly high clocks relative > to the data rate (i.e., "400kHz"), say a 16x or higher prescaler, that's > probably what's being done. > > In a correct implementation, the "400kHz" isn't, it's just the average when > everything is behaving as it should, activating and releasing SCK in a > timely manner, and with pull-up, capacitance and rise time in spec.
Yeah, I didn't think the standard had any such filtering specified. Originally the I2C spec was for connecting devices on a single PCB, so no filtering should be required. The signals need to be given the standard integrity attention you would give any of the other clock and data signals running around the board. This sensitivity to noise is why you need to take more care in distributing the signals to other boards or more so, other chassis. You can add whatever type of filtering you wish to your own implementations, but don't expect other devices to have the same degree of noise immunity. -- Rick C. -- Get a 1,000 miles of free Supercharging -- Tesla referral code - https://ts.la/richard11209
On 11 May 2019 05:08:24 -0700, Winfield Hill
<hill@rowland.harvard.edu> wrote:

>Jasen Betts wrote... >> >> On 2019-05-10, Winfield Hill wrote: >>> We need a 1-meter length of 100kHz (or slower) >>> I2C onnection. It'd be nice to use a pre-made >>> cable: micro-USB, 4-wire RJ11, or RJ45 ethernet. >>> Some considerations: SCL and SDA crosstalk(?), >>> high ground capacitance. Also need 3.3V, Gnd. >> >> do you need UV resistant? weatherproof? > > It'd be nice, but otherwise I'll wrap everything > with rubber mastic electrical tape, or some such. > >>> Micro-USB: SCL and SDA twisted together, bad? >> >> yes bad, maybe put SDA on white as SCL on red >> and +3 on green >> >>> RJ11: flat, SCL and SDA on outside lines? >> >> or SDA-0-scl-3.3 >> >> or RJ12: 0-SDA-0-3.3-SCL-0 > > This is my choice: RJ12 6P6C connector, except > 3.3-SDA-3.3-0-SCL-0 (3.3 and 0 are equivalent) > Flat 6P6C cables from Amazon, $4 each. An RJ12 > connector at each end, series damping resistors. > A bit of a kludge, but beehive clock is ticking. > >>> RJ45: SCL and SDA shielded from each other. >> >> meh. > > 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 outgass 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. Cheer
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. -- Thanks, - Win
On Saturday, May 11, 2019 at 5:23:35 PM UTC-4, 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.
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. Do you think your rise time will be less than 60 ns? -- Rick C. -- Get a 1,000 miles of free Supercharging -- Tesla referral code - https://ts.la/richard11209
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. > > 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.
> 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. -- Thanks, - Win
On Saturday, May 11, 2019 at 6:19:01 PM UTC-4, 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. > > > > 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.
20 ns is already an inordinately slow rise time. I can assure you it will not create measurable crosstalk in a 1 meter cable. Especially if you use twisted pair.
> > 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.
Sorry, I misread the numbers you posted. Still, the 6:1 is a rule of thumb for ignoring any further consideration. Your rise time will be slow enough that it is highly unlikely to result in significant reflections. -- Rick C. -+ Get a 1,000 miles of free Supercharging -+ Tesla referral code - https://ts.la/richard11209
On 12/5/19 7:23 am, 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,
Not the D21, not on GPIO pins. Pullup/down but not drive strength/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.
Presumably the slew-rate limiting depends on the selected data rate, but the data sheet is pretty quiet on that.