Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #14000 > unrolled thread

Sensor wiring

Back to article view | Back to comp.arch.embedded

Contents

  Sensor wiring Mel Wilson <mwilson@the-wire.com> - 2013-09-30 13:16 -0400
    Re: Sensor wiring Tim Wescott <tim@seemywebsite.really> - 2013-09-30 12:39 -0500
      Re: Sensor wiring Jim Stewart <jstewart@jkmicro.com> - 2013-09-30 11:05 -0700
      Re: Sensor wiring Mel Wilson <mwilson@the-wire.com> - 2013-09-30 14:25 -0400
        Re: Sensor wiring Rob Gaddi <rgaddi@technologyhighland.invalid> - 2013-09-30 11:40 -0700
          Re: Sensor wiring Tim Wescott <tim@seemywebsite.really> - 2013-09-30 14:17 -0500
        Re: Sensor wiring Johann Klammer <klammerj@NOSPAM.a1.net> - 2013-09-30 22:30 +0200
      Re: Sensor wiring Les Cargill <lcargill99@comcast.com> - 2013-09-30 21:55 -0500
    Re: Sensor wiring Don Y <this@isnotme.com> - 2013-09-30 11:58 -0700
    Re: Sensor wiring stephenXXX@mpeforth.com (Stephen Pelc) - 2013-09-30 20:05 +0000
      Re: Sensor wiring hamilton <hamilton@nothere.com> - 2013-09-30 15:22 -0600
        Re: Sensor wiring hamilton <hamilton@nothere.com> - 2013-09-30 15:23 -0600
      Re: Sensor wiring Dave Nadler <drn@nadler.com> - 2013-10-01 13:36 -0700
      Re: Sensor wiring Dave Nadler <drn@nadler.com> - 2013-10-01 13:39 -0700
    Re: Sensor wiring Vladimir Vassilevsky <nospam@nowhere.com> - 2013-09-30 16:58 -0500
      Re: Sensor wiring Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2013-10-01 08:44 +0200
    Re: Sensor wiring upsidedown@downunder.com - 2013-10-01 10:02 +0300
      Re: Sensor wiring Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-10-01 09:11 +0100
    Re: Sensor wiring Paul Rubin <no.email@nospam.invalid> - 2013-10-01 00:36 -0700
    Re: Sensor wiring Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-10-01 09:19 +0100

#14000 — Sensor wiring

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.

[toc] | [next] | [standalone]

#14002

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

[toc] | [prev] | [next] | [standalone]

#14003

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.

[toc] | [prev] | [next] | [standalone]

#14005

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.

[toc] | [prev] | [next] | [standalone]

#14006

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.

[toc] | [prev] | [next] | [standalone]

#14010

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

[toc] | [prev] | [next] | [standalone]

#14015

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

[toc] | [prev] | [next] | [standalone]

#14022

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

[toc] | [prev] | [next] | [standalone]

#14008

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.

[toc] | [prev] | [next] | [standalone]

#14012

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

[toc] | [prev] | [next] | [standalone]

#14016

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

[toc] | [prev] | [next] | [standalone]

#14017

On 9/30/2013 3:22 PM, hamilton wrote:
> 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.
Sorry, its a RasPi.

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

[toc] | [prev] | [next] | [standalone]

#14052

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.

See also:
http://www.ixysic.com/Products/OptBusRepUniBi.htm

[toc] | [prev] | [next] | [standalone]

#14053

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.

See also: http://www.ixysic.com/Products/OptBusRepUniBi.htm

[toc] | [prev] | [next] | [standalone]

#14018

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

[toc] | [prev] | [next] | [standalone]

#14028

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

[toc] | [prev] | [next] | [standalone]

#14030

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.

[toc] | [prev] | [next] | [standalone]

#14040

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.

[toc] | [prev] | [next] | [standalone]

#14034

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?

[toc] | [prev] | [next] | [standalone]

#14043

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch.embedded

csiph-web