Searching \ for '[PIC] [EE] Interfacing remote digital sensors' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=sensor
Search entire site for: '[EE] Interfacing remote digital sensors'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] [EE] Interfacing remote digital sensors'
2008\06\21@214826 by Yair Mahalalel

flavicon
face
Hello Piclist,

I've been an (almost) lurker on this list for a long while, but only
recently found a professional excuse to use PICs (developing new
detectors for the planned upgrade of the Large Hadron Collider at CERN,
by the way) - I attached an analog MEMS accelerometer to a 18F4553 and
built quite a decent inclinometer from them.

I now need to build a one off enhanced version of it that will measure
acceleration at three to five locations simultaneously at much higher
precision. I got a few LIS3LV02DL digital accelerometers from ST that
seem sufficiently accurate for the job, but as the distance between the
main processor and the sensors can be as large as 2 meters, I'm not sure
what would be a robust way to connect them together.

The accelerometers support both I2C and SPI communications, and my
initial thought was to use sufficiently heavily shielded cables (CAT-5E)
that the noise level will be acceptable, but as I understood from the
I2C specs, it is limited to 400pF total bus capacitance, which is close
to that of the cabling alone. SPI is unstandardized, so I'm even less
sure about using it in this context. As the acc. chips have no data
correction mechanisms I am quite wary of working so close to the limits -
it won't do if due to some kink or environmental change the chips will
start reporting nonsense without the main board even noticing the
difference after they're installed at the test site.

I can think of several ways to overcome this problem - mostly having to
do with either attaching inverters/transceivers to the sensors, fitting
each with a small PIC to handle cleverer encoding schemes, or both, but
the system has to ship in a month and I wouldn't like to over-engineer
it if some common practice for handling long range transmission of
originally inter-IC protocols exists.

My knowledge of things EE is eclectic and haphazard (as my command of
English), and I'm unused to veering off application notes and the easily
googlable, so I hope at least the problem statement is clear, and if not,
please ask ahead.

Cheers,
Yair.

2008\06\21@222507 by Bob Ammerman

picon face
>The accelerometers support both I2C and SPI communications, and my
> initial thought was to use sufficiently heavily shielded cables (CAT-5E)
> that the noise level will be acceptable, but as I understood from the
> I2C specs, it is limited to 400pF total bus capacitance, which is close
> to that of the cabling alone. SPI is unstandardized, so I'm even less
> sure about using it in this context. As the acc. chips have no data
> correction mechanisms I am quite wary of working so close to the limits -
> it won't do if due to some kink or environmental change the chips will
> start reporting nonsense without the main board even noticing the
> difference after they're installed at the test site.


SPI can be more easily extended than I2C because none of the lines are
bi-directional.
You can use whatever line-driver chips you want to create a robust link.

Of course if you're in a noisy environment (like near a bunch of hardrons
colliding into one-another) you might need some pretty special line-drivers.
I would be tempted to do something that was 'current-loop' based to have a
very low impedence.

Or, you could even use an optical interface if noise is a big problem.

In any case, it would just be a wire from the point of view of the software.

-- Bob Ammerman
RAm Systems

2008\06\21@232208 by Marcel

picon face
Wow, to think a PIC is associated with such cool science experiments as
the hadron collider...  congratulations!

What you need to do for connecting depends on two things here mainly:
speed and environmental noise. I don't know how much capacitance per
meter you should expect with CAT-5E cable but if your acquisition rates
are low enough, it should not affect things too much.  Check to see if
the input pins you will be using are schmitt trigger types; these will
be far more tolerant of slow rise times.

Even low capacitance cable can have problems in high noise environments
so this cannot be answered by someone who isn't on site, I think.  We
have all seen photos of "atom smashers" with enormous electromagnets
pulsing tremendous currents and such.  So after deciding on the first
question of how fast you need to run, the next question is to decide how
much shielding you will need.

Good luck and absolutely understand you must report back on how it all
goes!!!


Yair Mahalalel wrote:
{Quote hidden}

2008\06\22@004726 by Yair Mahalalel

flavicon
face
On Sat, Jun 21, 2008 at 10:24:37PM -0400, Bob Ammerman wrote:
>
> SPI can be more easily extended than I2C because none of the lines are
> bi-directional.
> You can use whatever line-driver chips you want to create a robust link.

I guess line drivers are indeed unavoidable - the maximum total current
the sensors can source is less than a mA, a far cry from the PICs.

Since I will be using CAT-5, I guess driving two of its twisted pairs
through differential transceivers such as those for RS-485/422 would keep
SPI's data lines happy.

That would leave 4 wires for power, clock and slave select, unless the
clock would want a twisted pair of its own, in which case I'll have to
get clever with feeding the sensor.

> Of course if you're in a noisy environment (like near a bunch of hardrons
> colliding into one-another) you might need some pretty special line-drivers.
> I would be tempted to do something that was 'current-loop' based to have a
> very low impedence.
>
> Or, you could even use an optical interface if noise is a big problem.

Near the accelerator and the interaction points, I believe most communications
outside heavily shielded Faraday boxes is indeed optical, but the test
stand we'll be using will only see a relatively low current test beam,
so I don't expect the noise levels to be much higher than in a high tech
office. I just want to have reasonable margins.

> In any case, it would just be a wire from the point of view of the software.

Unless I chicken out and throw another small heap of hardware at the
problem to implement some Error detecting encoding scheme. :-) My only
cross check right now is to see that the vector sum of the three axes
is reasonably close to 1g, but the Devil, as they say, is in the LSBs.

> -- Bob Ammerman
> RAm Systems

Thanks,
Yair.

2008\06\22@015316 by Yair Mahalalel
flavicon
face
On Sat, Jun 21, 2008 at 08:21:38PM -0700, Marcel wrote:
> Wow, to think a PIC is associated with such cool science experiments as
> the hadron collider...  congratulations!

Thanks! I'm doing my best to get these two cool pieces of hardware
together, although I suspect somewhere between those gigameters of wire
there are already quite a few PICs hiding.

But even if my current evil schemes come into fruition, this is not for
the current phase of the LHC (which is all but starting operations), but
for its upgrade, due in about 10 years.

> What you need to do for connecting depends on two things here mainly:
> speed and environmental noise.

I expect both to be relatively low. To take advantage of the full
accuracy of the sensors they cannot be sampled at more than 40Hz.
Assuming roughly 10 bytes per sample and five sensors, this yields about
20kbps, well within the low range of both protocols' specs.

I expect EMI levels to be low, though I don't really know. Asking
around, they tell me that it's very quiet unless one of the big cranes
along the ceiling moves - they have badly isolated electrical motors.
My rule of thumb is that it will have to work on my improvized workbench
first. I'm sure it's more noisy than anything we'll encounter there.

> I don't know how much capacitance per
> meter you should expect with CAT-5E cable but if your acquisition rates
> are low enough, it should not affect things too much. Check to see if
> the input pins you will be using are schmitt trigger types; these will
> be far more tolerant of slow rise times.

Google suggests values around 50pF/m, which is why I said a total of
400pF is probably a bit too close.

Schmidt triggers are provided on both sides of the loop, but I guess
that is moot once I have line drivers - now they will need to trigger
properly.

Can you give me a hint about slew rate? Would I want them as large as
possible to compensate for the 'sluggishness' of the wire, or do I want
them controlled at some fixed fraction of the clock cycle to prevent
possible overshoots or ringing?

> Even low capacitance cable can have problems in high noise environments
> so this cannot be answered by someone who isn't on site, I think.  We
> have all seen photos of "atom smashers" with enormous electromagnets
> pulsing tremendous currents and such.  So after deciding on the first
> question of how fast you need to run, the next question is to decide how
> much shielding you will need.

LOL! ATLAS, the experiment I'm working on, indeed contains the largest
magnet ever built (in terms of flux), but it doesn't pulse by a long
shot. It just sits there with its 20kA flowing through its
superconducting coils (8 of them, it's a toroid). I never saw it in
action (it's quite dangerous, I'd have to leave my glasses behind) but I
doubt it even hums.

And the tests I'm trying to join will be far away from it, in some quiet
rural side beam that will never see all that action, just a low rate of
pions at a few GeV. Still, you are absolutely correct about having to be
on site. After everything works, I'll build the most indecipherable UI,
to ensure myself a plane ticket to the Alps.

> Good luck and absolutely understand you must report back on how it all
> goes!!!

I will, though unless you're into it, you'll probably find these tests
very boring. To see how much, google for 'SLHC thin gap chamber
upgrade', click on a few PDFs, and imagine a little PIC patiently
reporting the alignment of the gas chambers relative to the beam and to
each other while a group of physicists scratch their head, trying to
figure out why they can't manage to improve their spatial resolution.

Cheers,
Yair.

2008\06\22@032052 by Wouter van Ooijen

face picon face
> I can think of several ways to overcome this problem - mostly having to
> do with either attaching inverters/transceivers to the sensors, fitting
> each with a small PIC to handle cleverer encoding schemes, or both, but
> the system has to ship in a month and I wouldn't like to over-engineer
> it if some common practice for handling long range transmission of
> originally inter-IC protocols exists.

1. a PIC near to the sensor, use RS485 to transmit the data, with error
detection/retransmission, or transmit N times 9with checksum), or
(another) form of forward error correction.

2. check I2C transceivers, like P82B715

3. Use SPI, with whatever buffer seems appropriate. maybe simple HC TTL,
maybe RS4xx, etdc.

Note that 2. and 3. might need some coding on the (remote) PIC to detect
and correct errors.


--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\06\22@074915 by olin piclist

face picon face
Yair Mahalalel wrote:
> but as the distance between
> the main processor and the sensors can be as large as 2 meters, I'm
> not sure what would be a robust way to connect them together.

I would stay away from IIC, but SPI should be fine with a few basic
precautions.  2 meters shouldn't be that hard to do at all, assuming the
other end is not separately grounded.  A few possibilities:

1 - Just hook it up using the existing digital outputs and inputs.  Use a
separate twisted pair for each of the three digital lines.  This will
probably work fine most of the time.

2 - Keep the clock rate low and add a little low pass filtering.  For extra
credit, you can detect unexpected transitions on the incoming data line and
discard the packet.

3 - Use redundancy.  Don't believe the answer unless you get the same value
or close to it twice in a row.

4 - Use differential signalling, with single ended to/from differential
converters at each end.  There are off the shelf chips that do this.

5 - Put a little PIC at the sensor, then have it send back data wrapped in
packets with checksums.

Unless there are some special circumstances you haven't told us about, I
would probably do #4 and keep the clock rate to less than 1MHz.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\22@080617 by Dario Greggio

face picon face
Olin Lathrop wrote:

> I would stay away from IIC, but SPI should be fine with a few basic
> precautions.  2 meters shouldn't be that hard to do at all, assuming the
> other end is not separately grounded.  A few possibilities:

for what matters (and I'd discourage this in the OP's application - I'm
kind of close to CERN and would not like to see an explosion from here
:)) ) I've used I2C up to 5-8meters, just lowering pull-ups to
330-470ohms, lowering speed to some 10-15KHz, and using Cat5E cable.


> 1 - Just hook it up using the existing digital outputs and inputs.  Use a
> separate twisted pair for each of the three digital lines.  This will
> probably work fine most of the time.

exactly, agreed


> 3 - Use redundancy.  Don't believe the answer unless you get the same value
> or close to it twice in a row.

good one too

> 4 - Use differential signalling, with single ended to/from differential
> converters at each end.  There are off the shelf chips that do this.

yep, agreed

> 5 - Put a little PIC at the sensor, then have it send back data wrapped in
> packets with checksums.

agreed as well, IMO if hardware and costs can be accepted, I'd go with
this and 485 or so.


--
Ciao, Dario -- ADPM Synthesis sas -- http://www.adpm.tk

2008\06\22@081421 by olin piclist

face picon face
Yair Mahalalel wrote:
> Can you give me a hint about slew rate? Would I want them as large as
> possible to compensate for the 'sluggishness' of the wire, or do I
> want them controlled at some fixed fraction of the clock cycle to
> prevent possible overshoots or ringing?

The important thing is to match the impedences.  Twisted pair is usually in
the 100-150 ohm range.  Get differential line drivers that are matched to
the cable impedence and make sure the receiving end is terminated with the
same impedence.  Some differential line receivers include the terminating
impedence.

If all this is done right, the natural slew rate of the line driver and the
filtering of the cable will keep the edge nasties down.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\22@084304 by olin piclist

face picon face
Dario Greggio wrote:
> I've used I2C up to 5-8meters, just lowering pull-ups to
> 330-470ohms, lowering speed to some 10-15KHz, and using Cat5E cable.

This violates the maximum required current sink spec, which is something
like 2 or 3 mA.  I don't remember what the maximum guaranteed logic low
level is, but even 470ohms from 3.3V would require 4.8mA to pull down to 1V.
You don't want to do this unless you know something more about your chips
beyond just being IIC complient.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\22@084953 by Thomas C Sefranek

flavicon
face
----- Original Message -----
From: "Olin Lathrop" <spam_OUTolin_piclistTakeThisOuTspamembedinc.com>
To: "Microcontroller discussion list - Public." <.....piclistKILLspamspam@spam@mit.edu>
Sent: Sunday, June 22, 2008 7:51 AM
Subject: Re: [PIC] [EE] Interfacing remote digital sensors


> 5 - Put a little PIC at the sensor, then have it send back data wrapped in
> packets with checksums.
>
>
I'd suggest CAN....

 *
 |  __O    Thomas C. Sefranek  tcsspamKILLspamcmcorp.com
 |_-\<,_   Amateur Radio Operator: WA1RHP
 (*)/ (*)  Bicycle mobile on 145.41, 448.625 MHz

ARRL Instructor, Technical Specialist, VE Contact.
hamradio.cmcorp.com/inventory/Inventory.html
http://www.harvardrepeater.org

2008\06\22@085805 by Dario Greggio

face picon face
Olin Lathrop wrote:

>>I've used I2C up to 5-8meters, just lowering pull-ups to
>>330-470ohms, lowering speed to some 10-15KHz, and using Cat5E cable.
>
> This violates the maximum required current sink spec, which is something
> like 2 or 3 mA.  I don't remember what the maximum guaranteed logic low
> level is, but even 470ohms from 3.3V would require 4.8mA to pull down to 1V.
> You don't want to do this unless you know something more about your chips
> beyond just being IIC complient.

I know, I know :)
it was a prototype which just had to collect temperature values for some
2 months, and then game over. There were some 8 TC74 sensors (Microchip
is always tolerant about characteristics - I counted on that) and one
SHT11 from Sensirion.
All fine with it. Ah, the I2C was bit-banged.

--
Ciao, Dario

2008\06\22@110752 by Yair Mahalalel

flavicon
face
Hi Wouter,

On Sun, Jun 22, 2008 at 09:20:14AM +0200, Wouter van Ooijen wrote:
> > I can think of several ways to overcome this problem - mostly having to
> > do with either attaching inverters/transceivers to the sensors, fitting
> > each with a small PIC to handle cleverer encoding schemes, or both, but
> > the system has to ship in a month and I wouldn't like to over-engineer
> > it if some common practice for handling long range transmission of
> > originally inter-IC protocols exists.
>
> 1. a PIC near to the sensor, use RS485 to transmit the data, with error
> detection/retransmission, or transmit N times 9with checksum), or
> (another) form of forward error correction.

I'm hesitant to add PICs and fragile code to this project. I only passed
the LED flashing phase a few days ago and validating communication code
in the short time I have is a risk I'll postpone until I am convinced
that pure electrical solutions cannot reduce the error rate
satisfactorily.

I have a few 628s lying around from rejuvenating my old Wisp, and a couple
of 10Fs, but it looks like I might have to glue the sensors to the
detectors, and so manufacture about 10 of these units. Getting enough
PICs that are similar enough (at least from the same family) for this
purpose will also add overhead.

> 2. check I2C transceivers, like P82B715
>
> 3. Use SPI, with whatever buffer seems appropriate. maybe simple HC TTL,
> maybe RS4xx, etdc.
>
> Note that 2. and 3. might need some coding on the (remote) PIC to detect
> and correct errors.

That I am more comfortable with, as the detectors are supposed to be
static and any packets that seem suspicious I can simply discard,
but I have very little to work with - the sensors send two 8 bit packets
containing the 12 bit internal ADC results. I will check the other 4
bits for signs of noise (and perhaps trigger an alarm), monitor the
communications for missing/extra bits in the packet (I think the PIC has
some facility for that) and calculate the vector sum of the three
vectors to detect motion/vibration. But except for sudden jumps in the
data, perhaps, there is little I can use to directly validate it.

Regarding the RS4xx family, I find the descriptions in Wikipedia and
elsewhere quite complicated, but would I be correct to say that the
half-duplex, multi-master nature of RS-485 makes drivers built for it a
better match for SPI?

Cheers,
Yair.

> --
>
> Wouter van Ooijen
>
> -- -------------------------------------------
> Van Ooijen Technische Informatica: http://www.voti.nl
> consultancy, development, PICmicro products
> docent Hogeschool van Utrecht: http://www.voti.nl/hvu
>
> --

2008\06\22@112734 by olin piclist

face picon face
Yair Mahalalel wrote:
> Regarding the RS4xx family, I find the descriptions in Wikipedia and
> elsewhere quite complicated, but would I be correct to say that the
> half-duplex, multi-master nature of RS-485 makes drivers built for it
> a better match for SPI?

Not really.  Your signals are all point to point with a fixed direction.
The only part of RS-485 that is of any use to you is the single to
diffefential to single line conversion.  What you really want is just some
differential line drivers and receivers, preferably ones that are matched to
the impedence of your cable.  It may be that using off the shelf RS-485
chips is a available way to get that if you hard wire each end to the
appropriate tranmitter or receiver mode, but other talk of RS-485 is
misleading.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\22@113505 by Wouter van Ooijen

face picon face
> Regarding the RS4xx family, I find the descriptions in Wikipedia and
> elsewhere quite complicated, but would I be correct to say that the
> half-duplex, multi-master nature of RS-485 makes drivers built for it a
> better match for SPI?

RS485 drivers can be used for uni-directional balanced data transfer,
IMHO they would be a good choice. Technically other RSxxx
driver/receivers might be OK too, but take a typical RS485 transceiver
and you can use the same chip at both ends. They tend to be easily
available too. SN75176B is the jellybean chip.

I2C extenders are probably easier (only one chip at each end), but
probably much less resistant to all kinds of interference. Whether that
matters is up to you...

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\06\22@124549 by Yair Mahalalel

flavicon
face
Hi Olin,

On Sun, Jun 22, 2008 at 07:51:27AM -0400, Olin Lathrop wrote:
> Yair Mahalalel wrote:
> > but as the distance between
> > the main processor and the sensors can be as large as 2 meters, I'm
> > not sure what would be a robust way to connect them together.
>
> I would stay away from IIC, but SPI should be fine with a few basic
> precautions.  2 meters shouldn't be that hard to do at all, assuming the
> other end is not separately grounded.

The other end will be electrically isolated.

> A few possibilities:
>
> 1 - Just hook it up using the existing digital outputs and inputs.  Use a
> separate twisted pair for each of the three digital lines.  This will
> probably work fine most of the time.

That's an option I might have considered (and perhaps will), had the
other end been a PIC or another healthy IC, but the sensor seems to only
be able to source 0.8mA (the datasheet is not very clear on this, as it
wasn't designed with this purpose in mind), and I assume this is too low
for driving the line.

Additionally, if I understand the principle behind these MEMS sensors
correctly, they work by measuring capacitance in the sub-femtoFarad
range, so isolating them from external noises would probably be
advisable in that respect as well.

Regarding using a full pair for the clock line, I'm considering trying
to get away without balancing it and pairing it with the power line, or
I'll be a wire short for including the slave select, which the sensor
insists on.

> 2 - Keep the clock rate low and add a little low pass filtering.  For extra
> credit, you can detect unexpected transitions on the incoming data line and
> discard the packet.

I don't expect to need more than 20kbps net bandwidth, so I currently
plan to start with the Fosc/64 setting on the PIC with a 20MHz
oscillator to get 256kHz, and might try to lower it further if it will
seem necessary.

> 3 - Use redundancy.  Don't believe the answer unless you get the same value
> or close to it twice in a row.

Thanks. The detectors are heavy and supposed to be rigidly harnessed. A sharp
transition within 25ms (the sampling interval), especially if it is not
accompanied by jitter in the accelerometers on the other axes would be a
good internal indication that something is amiss.

> 4 - Use differential signalling, with single ended to/from differential
> converters at each end.  There are off the shelf chips that do this.

I had a look at different chips, and the ones produced for RS-485 seem
suitable for the purpose. I'm concerned, though, that as the sensors
believe they're on an SPI bus, they'll leave their IO lines drifting
when not spoken to. Tying them weakly to the middle of their Schmidt
trigger hysteresis range can probably prevent spurious signals, but they
might still introduce noise, so I'm thinking of using FETs to detach
them from the bus when they're not part of the conversation.

> 5 - Put a little PIC at the sensor, then have it send back data wrapped in
> packets with checksums.

The nature of my application is such that if line noise is limited to
short periods of time (such as a crane changing position), it will be
enough to spot that there is noise and alert the users, asking them to
wait until it's over. The communication doesn't have to be perfect on
average, only on median :-).

But a handful of PICs is planned in case I can't manage perfect signal
reception under normal circumstances.

> Unless there are some special circumstances you haven't told us about, I
> would probably do #4 and keep the clock rate to less than 1MHz.

That will be my starting point. I will do some tests as soon as
possible to get a feel for the problem, and then order the necessary
parts to make it a couple of orders of magnitude more robust than it
needs to be. My knowledge of the intended environment is optimistic but
quite vague and unreliable. For all that I know a big pump with a sparking
motor could be installed next to our stand the day before we arrive.

Thanks for the insight,
Yair.

> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014.  Gold level PIC consultants since 2000.
> --

2008\06\22@134307 by Yair Mahalalel

flavicon
face
On Sun, Jun 22, 2008 at 11:29:20AM -0400, Olin Lathrop wrote:
> Yair Mahalalel wrote:
> > Regarding the RS4xx family, I find the descriptions in Wikipedia and
> > elsewhere quite complicated, but would I be correct to say that the
> > half-duplex, multi-master nature of RS-485 makes drivers built for it
> > a better match for SPI?
>
> Not really.  Your signals are all point to point with a fixed direction.

That is only partially correct, as on the SPI bus all the nodes share
the same I/O lines. I want to make sure that the line drivers will not
pull the line when not in use, as might be acceptable in true point to
point communications.

> The only part of RS-485 that is of any use to you is the single to
> diffefential to single line conversion.

True. And I prefer to use an off the shelf solution instead of trying to
build a solution from not gates or something and taking care of timing
the transitions correctly myself.

> What you really want is just some
> differential line drivers and receivers, preferably ones that are matched to
> the impedence of your cable.

Indeed, but as I wasn't formally educated in electrical engineering and
my experience is very limited, I am unaware of the various
considerations that go into the problem, and since it isn't a simple
question with a closed answer, I acknowledged the limits of my
autodidactic abilities and contacted the list.

Nowhere are the gaps in my knowledge more apparent, perhaps, than in
matters related to line impedance, of which I heard only in the context
of sinusoidal waves. You mentioned earlier in the thread adding low pass
filters to the line. Wouldn't adding small capacitors at the ends of the
line serve, together with the source/line DC resistance, as low pass
filters that restrain overly sharp transitions of the driver? If that is
indeed a viable solution, what transition time should I aim at? Are the
pair impedance (~100 Ohm) and capacitance (~50pF/m) the relevant values
to put in the time constant equation?

> It may be that using off the shelf RS-485
> chips is a available way to get that if you hard wire each end to the
> appropriate tranmitter or receiver mode, but other talk of RS-485 is
> misleading.

I guess another of the shortcomings of only learning the narrow range of
subjects applicable to the problem at hand is that talking to people
with wider understanding tends to create confusion as to the context in
which terms are used. I thought it was clear I'm trying to adhere to SPI
as much as possible at the logical level and my interest in RS-485 is
only with regards to the suitability of the driver chips used with it to
my application. If I failed to convey the distinction, I apologize.

Yair.

>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014.  Gold level PIC consultants since 2000.
> --

2008\06\22@141438 by Yair Mahalalel

flavicon
face
On Sun, Jun 22, 2008 at 08:42:00PM +0300, Yair Mahalalel wrote:
> On Sun, Jun 22, 2008 at 11:29:20AM -0400, Olin Lathrop wrote:
>
> > The only part of RS-485 that is of any use to you is the single to
> > diffefential to single line conversion.
>
> True. And I prefer to use an off the shelf solution instead of trying to
> build a solution from not gates or something and taking care of timing
> the transitions correctly myself.
>
> > What you really want is just some
> > differential line drivers and receivers, preferably ones that are matched to
> > the impedence of your cable.

Ah! What both you and Wouter were saying was that there exist generic
differential line drivers and that using them I might be able to find
better match for my line impedance in the third state as well and be free
from the restriction of a single channel in each direction! I was so
wrapped up in trying to figure out which of the drivers of the two RS-4xx
protocols suited me better, it didn't occur to me that the issue was
common enough to deserve hardware solutions independent of these two,
and I understood all the remarks about line drivers as advice on how
to use their line drivers...

Ok...  the variety is much wider and more relevant now. Thanks for the
patience.

Yair.

2008\06\22@151125 by Vasile Surducan

face picon face
On 6/21/08, Yair Mahalalel <.....yairKILLspamspam.....mahalalel.com> wrote:
{Quote hidden}

2 meters of CAT5 cable has 400pF ?


. SPI is unstandardized, so I'm even less
{Quote hidden}

> -

2008\06\22@173848 by Yair Mahalalel

flavicon
face
On Sun, Jun 22, 2008 at 12:11:23PM -0700, Vasile Surducan wrote:

> 2 meters of CAT5 cable has 400pF ?

2 meters of CAT-5E are defined to have 104pF (see for example
http://en.wikipedia.org/wiki/Cat5e) but since I'll be connecting several
of these in parallel, the total bus capacitance may reach, or exceed,
400pF.

Yair.

2008\06\22@193526 by olin piclist

face picon face
Yair Mahalalel wrote:
> I had a look at different chips, and the ones produced for RS-485 seem
> suitable for the purpose. I'm concerned, though, that as the sensors
> believe they're on an SPI bus, they'll leave their IO lines drifting
> when not spoken to. Tying them weakly to the middle of their Schmidt
> trigger hysteresis range can probably prevent spurious signals, but they
> might still introduce noise, so I'm thinking of using FETs to detach
> them from the bus when they're not part of the conversation.

You are making this too complicated.  When the sensor isn't driving its data
output line, you don't care what the value is.  A 100Kohm pulldown to ground
on the sensor SPI output line will keep the differential line driver input
signal from floating.  You don't want to keep the signal in the middle of
its range, even if the line driver has a Schmidt trigger input.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\22@200721 by olin piclist

face picon face
Yair Mahalalel wrote:
>> Not really.  Your signals are all point to point with a fixed
>> direction.
>
> That is only partially correct, as on the SPI bus all the nodes share
> the same I/O lines. I want to make sure that the line drivers will not
> pull the line when not in use, as might be acceptable in true point to
> point communications.

I thought that each sensor was in a different place and each had its own 2m
cable back to the main PIC.  If so, I would not try to multiplex the
returned data line by having them someone go to high impedence when not
addressed.  That doesn't map nicely to differential drive.  I was assuming
you'd use separate SPI data input lines to the main PIC, since doing SPI in
hardware is so trivial.  If you really want to use the SPI hardware or need
to have a single data input line for some other reason, use a digital N to 1
line demultiplexer.

> True. And I prefer to use an off the shelf solution instead of trying to
> build a solution from not gates or something and taking care of timing
> the transitions correctly myself.

I agree, but RS-485 specific chips are only one type of single to
differential line converter.  They may still be a good choice due to being
widely available, but I'd look for something specifically designed for the
impedence of the CAT5 cable you are using.  I don't know if such a thing
exists, but it is plausible.

> Nowhere are the gaps in my knowledge more apparent, perhaps, than in
> matters related to line impedance, of which I heard only in the context
> of sinusoidal waves.

I can't repeat several weeks of college level class material here, but
basically a infinite transmission line looks like a resistor to something
driving it with AC at one end.  Things get more complicated when the line
isn't infinite.  When a signal is driven onto one end, it will bounce back
at the other end, then bounce back from that end, etc, etc.  The bounces add
to the original signal, making a mess.  A open end makes a bounce of one
polarity, and a shorted end the other polarity.  To minimize the bounces,
you make a finite line appear infinite by terminating it at the other end
with its characteristic resistance.  The characteristic impedence is the
magic point where the bounces are nulled out as the polarity of the bounce
flips.  After all, if a infinite line looks like a resistor to a load, then
at any point you should be able to cut the line and replace the rest with
the right resistor, and a sender at the other end can't tell the difference.

So the advantage of transmitters and receivers with a controlled impedence
matched to the transmission line is that bounces at each end are minimized,
and are therefore least likely to interfere with the real signal.

> You mentioned earlier in the thread adding low pass
> filters to the line. Wouldn't adding small capacitors at the ends of the
> line serve, together with the source/line DC resistance, as low pass
> filters that restrain overly sharp transitions of the driver?

Yes, at that end of the line, but that also will be a mismatch with the
characteristic impedence and will cause bounces.  I meant a small
capacitance right at the transmitter to slow the edges just a little.  I
also said I would only do this as a last resort, and that the intrinsic slew
rate limitation of the transmitter would probably suffice to keep the edges
from coupling into other equipment you said you were worried about.  Just
the fact that the transmission line is twisted will help a lot too, since
anything more than a few twist lengths from the cable will only see the
common mode signal.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\22@201032 by olin piclist

face picon face
Yair Mahalalel wrote:
> Ah! What both you and Wouter were saying was that there exist generic
> differential line drivers and that using them I might be able to find
> better match for my line impedance

Yes, it is at least a possibility that these exist.

> in the third state as well and be
> free from the restriction of a single channel in each direction!

No.  I wouldn't try to send three states over a differential pair.
Demultiplex multiple incoming data lines at the receiver digitally, or bring
each to its own PIC input pin and do the SPI in firmware.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\06\23@002617 by Vasile Surducan

face picon face
On 6/22/08, Yair Mahalalel <EraseMEyairspam_OUTspamTakeThisOuTmahalalel.com> wrote:
> On Sun, Jun 22, 2008 at 12:11:23PM -0700, Vasile Surducan wrote:
>
> > 2 meters of CAT5 cable has 400pF ?
>
> 2 meters of CAT-5E are defined to have 104pF (see for example
> http://en.wikipedia.org/wiki/Cat5e) but since I'll be connecting several
> of these in parallel, the total bus capacitance may reach, or exceed,
> 400pF.

Well, sound at least ridiculous to build an RS485 for 2 meters of cable.
You may consider the RS485 option only  if you really have harsh
environement there.
I2C will run perfectly on CAT5 at this distance. Connected as follows:
Data+GND = 1 pair, CLK +GND the second pair, all other pairs left tied to GND.
If you need more signals use different cable for something else.
Just for records, I2C are running perfectly at 10 meters or more,
using I2c repetears and/or active terminators.

2008\06\24@011015 by Yair Mahalalel

flavicon
face
On Sun, Jun 22, 2008 at 09:26:15PM -0700, Vasile Surducan wrote:

> Well, sound at least ridiculous to build an RS485 for 2 meters of cable.
> You may consider the RS485 option only  if you really have harsh
> environement there.

I doubt I will, except for perhaps short periods of time, but since I
will not be able to test the environment before the system is deployed
I'd rather stay on the safe side, compensating for the lack of
redundancy/error checking in the sensor data stream.

It also provides some flexibility in case the system will be reused for
larger installations, as I hope it will, or if it will have to be
modified on site.

> I2C will run perfectly on CAT5 at this distance. Connected as follows:
> Data+GND = 1 pair, CLK +GND the second pair, all other pairs left tied to GND.
> If you need more signals use different cable for something else.

To keep to the I2C spec, which I want to do as I don't trust the sensors
to be lax about them, that would mean connecting each cable on a
separate I2C circuit. The two ways I can think of doing that is either
multiplexing the hardware I2C port of the PIC, or implementing it in
software for connecting each to a different GPIO, both more complicated
than the relative transparency of using line drivers.

> Just for records, I2C are running perfectly at 10 meters or more,
> using I2c repetears and/or active terminators.

I think I even saw I2C ports on front panels of high end switches,
suggesting it's indeed not too fragile, but if such use requires
enhancing the physical layer to support the data link over larger
distances than it was designed for, is there a fundamental difference
between that and making SPI use a differential signalling? One
difference I can see is that simple repeaters will allow unmodified
nodes to be attached to the bus, but it doesn't seem very significant to
me for this application.

I am not trying to argue the merits of one solution over the other,
just to see if I understand the differences between the two, and
specifically why you consider one of them to be ridiculous and the other
ideal.

Cheers,
Yair.

2008\06\24@014541 by Wouter van Ooijen

face picon face
>  One
> difference I can see is that simple repeaters will allow unmodified
> nodes to be attached to the bus, but it doesn't seem very significant to
> me for this application.

In that sense I2C-with-repeaters is the same as SPI-with-RSxxx-transceivers.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\06\25@050123 by Alan B. Pearce

face picon face
>Wow, to think a PIC is associated with such cool science experiments
>as the hadron collider...  congratulations!

I have also used several PICs in a piece of test gear that is being used to
test some Stirling Cooler Drive Electronics that will be flown on the Planck
Space Mission.

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...