I2C cable

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 wrote in :

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

hat

c

t e

en

Yeah, I didn't think the standard had any such filtering specified. Origin ally the I2C spec was for connecting devices on a single PCB, so no filteri ng 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 a round the board. This sensitivity to noise is why you need to take more ca re 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

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

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

That seems excessive. Even with a 20 ns rise time the round trip on a 1 me ter 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

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.

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

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.

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

Not the D21, not on GPIO pins. Pullup/down but not drive strength/slew rate.

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

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.

I don't follow your crosstalk analysis. You are assuming your load is pure ly 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 tota l 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 no t 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

On a sunny day (11 May 2019 19:13:48 -0700) it happened Winfield Hill wrote in :

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:

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

On a sunny day (Sun, 12 May 2019 07:10:51 GMT) it happened Jan Panteltje wrote in :

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.

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.

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.

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.

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

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.

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

Reflections from inductive and/or delay-line loads, i.e. not properly terminated?

On a sunny day (Sun, 12 May 2019 19:38:40 +1000) it happened Clifford Heath wrote in :

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?

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