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.
Sensor wiring
Started by ●September 30, 2013
Reply by ●September 30, 20132013-09-30
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. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●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.This. Tim knows what he's talking about. Most of us have scars from trying what you want to do.
Reply by ●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 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.I was hoping to avoid a crystal on the sensor end and reuse the pins. Switching to an ATtiny?4 wouldn't kill me, I guess. Mel.
Reply by ●September 30, 20132013-09-30
On Mon, 30 Sep 2013 14:25:52 -0400 Mel Wilson <mwilson@the-wire.com> wrote:> 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 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. > > I was hoping to avoid a crystal on the sensor end and reuse the pins. > Switching to an ATtiny?4 wouldn't kill me, I guess. > > Mel. >If you were desperate to avoid a crystal on the sensor end, you could also run the async RX line to a counter pin, and use the bit timing to servo the on-board oscillator. "I know I'm off by no more than 10%, and I saw a high for 1.95 bits. Therefore it was really high for 2 bits, and I'm running slow by 2.5%" sort of a thing. Though that may wind up being a lot of code-slinging to save a cheap rock/ceramic slab. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Reply by ●September 30, 20132013-09-30
Hi Mel, On 9/30/2013 10:16 AM, 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?Argh! Expect to (effectively) built an I2C-to-X bridge on each end of the line, if you are intent on a shared cable. IME, unless you include plans for replacing the devices at one or both ends of the line as a matter of "routine maintenance", consider an alternative communication medium. Opt for galvanic isolation. [I have hundreds of "field I/O's" here and all of them are isolated by one means or another] Do you have *power* at both ends of the line? Or, is power conveyed over a similar cable? I.e., if you can eliminate the need for a power cable, then you have extra incentive to eliminate the *data* cable! :> Alternatively, if you *do* have a power cable, you can use it for signaling if your data rates are low enough (or you want to spend on transceivers!) No mention of data rates. With smarts on each end of the line, if your bandwidth *requirements* are low, you can opt for a slower means of encoding them. Do you really need bidir comms? Consider wireless (with measures to protect the transactions if they are "important" or "significant"). You can buy/build a small ~900MHz modem for far less than the cost of the wire + trench digging effort. Also consider a PLC modem -- if power to your "out building" (?) is fed from the first building. If intent on running some sort of "wire", first choice is optical fiber (depending on data rates, you can often get this cheap at surplus). Or, transformer couple and push *audio* down the wire (possibly even supporting duplex operation by chosing different carriers). Look at old modem technologies for hints.> Acknowledging that out-of-spec bits per second is a definite possiblity.
Reply by ●September 30, 20132013-09-30
On Mon, 30 Sep 2013 11:40:40 -0700, Rob Gaddi wrote:> On Mon, 30 Sep 2013 14:25:52 -0400 Mel Wilson <mwilson@the-wire.com> > wrote: > >> 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 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. >> >> I was hoping to avoid a crystal on the sensor end and reuse the pins. >> Switching to an ATtiny?4 wouldn't kill me, I guess. >> >> Mel. >> >> > If you were desperate to avoid a crystal on the sensor end, you could > also run the async RX line to a counter pin, and use the bit timing to > servo the on-board oscillator. "I know I'm off by no more than 10%, > and I saw a high for 1.95 bits. Therefore it was really high for 2 > bits, and I'm running slow by 2.5%" sort of a thing. > > Though that may wind up being a lot of code-slinging to save a cheap > rock/ceramic slab.Or go really slow and just bit-bang the interface. But you run into the same "lots of code for two pins" tradeoff. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●September 30, 20132013-09-30
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.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. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
Reply by ●September 30, 20132013-09-30
Mel Wilson wrote:> 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 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. > > I was hoping to avoid a crystal on the sensor end and reuse the pins. > Switching to an ATtiny?4 wouldn't kill me, I guess. > > Mel. >you could use the SPI interface. it is not open collector stuff, so the signal is a bit more reliable against noise pickup. it is clock sync, so osc accuracy is no problem either. Also, all of those atmel controllers seem to have one...
Reply by ●September 30, 20132013-09-30
On 9/30/2013 2:05 PM, 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/Interesting part. Lets do a little math and see if its worth it: http://www.digikey.com/product-detail/en/PCA9600DP,118/568-4716-1-ND/2025007 $3.69 each for two chips = $7.38 http://www.digikey.com/product-detail/en/SP485CN-L%2FTR/1016-1825-1-ND/3586542 $1.09 each for two chips = $2.18 Difference = $5.20 Does this project have the budget for an extra $5.20[*]? Tiny85: http://www.digikey.com/product-detail/en/ATTINY85-20PU/ATTINY85-20PU-ND/735469 $1.29 each Tiny84: http://www.digikey.com/product-detail/en/ATTINY84A-PU/ATTINY84A-PU-ND/2774082 $1.38 each That adds another $0.09 to the project. So for $5.29 increase in cost you can do what you want reliably, or cheaper and still be reliable. You did not mention what was on the receiving end for this data. 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
