On Monday, September 30, 2013 4:05:02 PM UTC-4, Stephen Pelc wrote:
> We have done this in a very noisy environment. You *need* to use
> buffer chips like the NXP P82B96. See:
> http://ics.nxp.com/products/i2chubs/
>
> I2C is an edge triggered protocol. Many I2C peripherals are very
> sensitive to fast noise pulses. We often find bit-banged I2C to be
> more reliable for masters than using the peripheral hardware.
> I2C slave code for bit-banging is just nasty.
On Monday, September 30, 2013 4:05:02 PM UTC-4, Stephen Pelc wrote:
> On Mon, 30 Sep 2013 13:16:55 -0400, Mel Wilson <mwilson@the-wire.com> wrote:
> We have done this in a very noisy environment. You *need* to use
> buffer chips like the NXP P82B96. See:
> http://ics.nxp.com/products/i2chubs/
>
> I2C is an edge triggered protocol. Many I2C peripherals are very
> sensitive to fast noise pulses. We often find bit-banged I2C to be
> more reliable for masters than using the peripheral hardware.
> I2C slave code for bit-banging is just nasty.
> I want an I2C connection between a Raspberry Pi and an ATtiny85 over 35m
> of
> buried wire. Any guidelines for signal conditioning and protection?
> Acknowledging that out-of-spec bits per second is a definite possiblity.
>
> Thanks, Mel.
Hi Mel,
I have just seen this and note you already had quite a few responses.
The sort of distance you are going I would definitely say that I2C is not
the long range interconnect you ould want. Galvanic Isolation and Transient
Protection is going to be required for both ends of the link.
If you also need power fed to the instrument end then this has also to be
figured in and similarly protected if it is other than a mains supply. In
which case I would look at either opto-isolator or transformer coupled
connections. It is easy to recreate the I2C electrical conditions at each
end of the isolated link. What you use in between should be given careful
consideration but just raising the voltage level of the signals and
employing appropriate protective zener/varistor/capacitor clamping and
filtering with energy controlling resistors will be the route I would take.
You can use a cable with a screened twisted pair for each line and even a
third one for the low-power feed if you need it (3 pair cable by Belden
would probably suit if you have a suitable conduit for the cable to go
through).
If you had mentioned the sort of data rate you were interested in it would
have been easier to suggest something more specific.
--
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Reply by Tom Gardner●October 1, 20132013-10-01
On 01/10/13 08:02, upsidedown@downunder.com wrote:
> On Mon, 30 Sep 2013 13:16:55 -0400, Mel Wilson <mwilson@the-wire.com>
> wrote:
>
>> I want an I2C connection between a Raspberry Pi and an ATtiny85 over 35m of
>> buried wire. Any guidelines for signal conditioning and protection?
>> Acknowledging that out-of-spec bits per second is a definite possiblity.
>
> Since there is a reference to a buried wire, it suggests that two
> buildings are connected together. If both buildings are mains powered,
> there can be some ground potential differences, which at exceptional
> conditions (thunderstorms etc.) can be even outside the balanced
> RS-422 common voltage range (-5 to +12 V).
>
> For this reason, galvanic isolation should be used at both ends
I was wondering if someone was going to mention that!
You could consider using 1mm core plastic fibre optic cable.
Reply by Paul Rubin●October 1, 20132013-10-01
Mel Wilson <mwilson@the-wire.com> writes:
> I want an I2C connection between a Raspberry Pi and an ATtiny85 over 35m of
> buried wire. Any guidelines for signal conditioning and protection?
Bluetooth?
Reply by ●October 1, 20132013-10-01
On Mon, 30 Sep 2013 13:16:55 -0400, Mel Wilson <mwilson@the-wire.com>
wrote:
>I want an I2C connection between a Raspberry Pi and an ATtiny85 over 35m of
>buried wire. Any guidelines for signal conditioning and protection?
>Acknowledging that out-of-spec bits per second is a definite possiblity.
Since there is a reference to a buried wire, it suggests that two
buildings are connected together. If both buildings are mains powered,
there can be some ground potential differences, which at exceptional
conditions (thunderstorms etc.) can be even outside the balanced
RS-422 common voltage range (-5 to +12 V).
For this reason, galvanic isolation should be used at both ends
A separate isolated, say 12 V power supply could be used to implement
an I2C style open collector network. 680 ohm resistors from the power
supply to the data and clock lines are pulled down by the optocoupler
transistor, causing a 20 mA current to flow. A low current (1 mA) is
used to sense the buss state.
Assuming you want 1 us rise/fall times, with 680 resistor, would allow
1.5 nF stray capacitance or 42 pF/m, so 100 kHz clock rate should be
just doable.
Reply by Stef●October 1, 20132013-10-01
In comp.arch.embedded,
Vladimir Vassilevsky <nospam@nowhere.com> wrote:
> On 9/30/2013 12:16 PM, Mel Wilson wrote:
>> I want an I2C connection between a Raspberry Pi and an ATtiny85 over 35m of
>> buried wire. Any guidelines for signal conditioning and protection?
>> Acknowledging that out-of-spec bits per second is a definite possiblity.
>
> If it is not meant for mass production, it would even work in most
> cases. Protection: use USB trazorb like TPD2E001. Who cares.
>
> BTW, I've seen a *practical* system where they run DS 1-wire temperature
> sensors through 20m lines :)
That's different. DS 1-wire is actually intended to be run on long lines,
I2C is not. IIRC, the DS appnotes speak of a total load on the 1-wire of
100 "meter load units" where a meter of wire is one unit and a device is
a couple of units.
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
"The one charm of marriage is that it makes a life of deception a neccessity."
- Oscar Wilde
Reply by Les Cargill●September 30, 20132013-09-30
Tim Wescott wrote:
> On Mon, 30 Sep 2013 13:16:55 -0400, Mel Wilson wrote:
>
>> I want an I2C connection between a Raspberry Pi and an ATtiny85 over 35m
>> of buried wire. Any guidelines for signal conditioning and protection?
>> Acknowledging that out-of-spec bits per second is a definite possiblity.
>
> I really think that any work that you think you're going to avoid by
> sticking to I2C is probably vastly overshadowed by the amount of work
> that you'll need to do to make it function reliably. This is,
> unfortunately, one of that great class of expedients that works well
> enough to fool you into thinking its a success, but tends to break in the
> presence of bosses or customers.
>
> I suspect that your best bet would be a simple asynchronous link sending
> serial commands via properly-terminated RS-422. You'll need two twisted
> pairs (one for transmit, one for receive), but it should be dead reliable.
>
> The only thing that would drive me to retaining I2C in this case would be
> if there's some existing software that works with I2C and was very
> resistant to being rewritten to use asynchronous serial.
>
+1
--
Les Cargill
Reply by Vladimir Vassilevsky●September 30, 20132013-09-30
On 9/30/2013 12:16 PM, Mel Wilson wrote:
> I want an I2C connection between a Raspberry Pi and an ATtiny85 over 35m of
> buried wire. Any guidelines for signal conditioning and protection?
> Acknowledging that out-of-spec bits per second is a definite possiblity.
If it is not meant for mass production, it would even work in most
cases. Protection: use USB trazorb like TPD2E001. Who cares.
BTW, I've seen a *practical* system where they run DS 1-wire temperature
sensors through 20m lines :)
VLV
> If the remote end only sends data, then only one pin would be required.
> [TxD, the RS485 chip can be enabled all the time]
>
> hamilton
>
> [*] plus shipping if you do not already have these chips on hand
>