Communication bus for off the pcb sensors

[ZeroResistance]

A variety of sensors like temperature, pressure etc. are available in SPI, I2C today.
I have a requirement where I need to locate these sensors slightly away from the main board (the board where the microcontroller reside
The distance could be as low as 1 foot to as long as 5 feet.

1. Are SPI / I2C capable of handling such distances?
2. If so would I need additional buffering at the transmitter and at the sensor end.?
3. I see that daisy chaining is possible in SPI, this reduces the number of lines that have to go out from the main board to just a common clock, and a common chip select, the SDO / SDI pins are daisy chained.
4. Are there any other buses out there that are meant to handle these kinds of distances. I guess SPI / I2C is quite ubiquitous in the sensor domain and RS485 / RS422 seems to be too overkill to provide for each sensor?

Thanks in advance!

[rstofer]

I don't know about SPI but there are I2C extenders that will go out to a mile but the data rate falls off

http://electro8051.free.fr/buslong/AN452.pdf

Google is your friend!  Here is a TI app note on extending the SPI bus but it doesn't look simple.  The problem is timing, you need to get the data from the far end into the shift register before the next clock.

http://www.ti.com/lit/an/slyt441/slyt441.pdf


For SPI, you need a common Clk, MISO and MOSI plus one SS' per device.

At 5 feet, I might just try it without extenders.  I might bring along Vcc and Gnd and do a little termination resistor thing on the far end.  You would be doing this anyway for SPI I2C because it is an open-collector bus.

ETA:  Fixed bus type - typo...

[ZeroResistance]

I don't know about SPI but there are I2C extenders that will go out to a mile but the data rate falls off

http://electro8051.free.fr/buslong/AN452.pdf

Google is your friend!  Here is a TI app note on extending the SPI bus but it doesn't look simple.  The problem is timing, you need to get the data from the far end into the shift register before the next clock.


http://www.ti.com/lit/an/slyt441/slyt441.pdf

Thanks  for the info.

For SPI, you need a common Clk, MISO and MOSI plus one SS' per device.

Yes that's the typical way of wiring it up however I also found some info on daisy chaining devicies for SPI.

At 5 feet, I might just try it without extenders.  I might bring along Vcc and Gnd and do a little termination resistor thing on the far end.  You would be doing this anyway for SPI because it is an open-collector bus.

So as far as the open colllector think you are referring to here is I2C?
And for termination which lines would I need to terminate?

[max_torque]

The big question you haven't mentioned is what exactly is between the sensor and the pcb?

If the "5 foot" distance is inside a known enclosure, with no user access (let alone say a lightning strike, ESD discharge or similar!), then sure, one of the low voltage digital serial streams may well work, but if the "real world" is between the sensor and the pcb, then data architectures like RS485, CAN or LIN have been invented for very good reasons!

Also, is the sensor architecture fixed or extensable?  Serial data networks like CAN are easy to use for user configerable systems where you might want to add extra sensors, or remove them etc.  Something like SPi is no use (really) in that case, as in effect your hardware is fixed.

[ZeroResistance]

The big question you haven't mentioned is what exactly is between the sensor and the pcb?

If the "5 foot" distance is inside a known enclosure, with no user access (let alone say a lightning strike, ESD discharge or similar!), then sure, one of the low voltage digital serial streams may well work, but if the "real world" is between the sensor and the pcb, then data architectures like RS485, CAN or LIN have been invented for very good reasons!

Yes there would be an enclosure in somecases but in other cases there might not  be as in if the sensor is mounted on a motor, the motor may or may not be inside an enclosure. There is a very rare possibility that it would be out in the open though (I mean  the case of a lightening strike).

Also, is the sensor architecture fixed or extensable?  Serial data networks like CAN are easy to use for user configerable systems where you might want to add extra sensors, or remove them etc.  Something like SPi is no use (really) in that case, as in effect your hardware is fixed.

[/quote]
i understand your point but isn't SPI / I2C also extensible like you can add multible sensors on the same bus for both of them.

[MosherIV]

Both SPI and I2C were originally designed to be internal serial bus, that is inside encloseure with little noise.

SPI is meant to be a high speed bus, capable of transmission speeds of 5MHz or above under the right conditions.

5 foot, external to enclosure, next to (noisey) motor breaks all those rules.
It may work but do not blame us or the bus standard if it does not work.

Already mentioned, try RS485, RS232, CAN or LIN.

[Kirkhaan]

You can also consider to take a look at DALI.
That for sure is robust, but the datarate is limited though.
I believe there is also a SR (Sensor Ready) variant that can provide power over the same 2 wires.

[JPortici]

Yes there would be an enclosure in somecases but in other cases there might not  be as in if the sensor is mounted on a motor, the motor may or may not be inside an enclosure. There is a very rare possibility that it would be out in the open though (I mean  the case of a lightening strike).

Use CANBus, as long as there always are at least two nodes.

i understand your point but isn't SPI / I2C also extensible like you can add multible sensors on the same bus for both of them.

well yes but for SPI you have to add and route another CS signal for every device you want to add, unless you are very very very lucky and each sensor has both MISO and MOSI that can be used to daisy chain the devices.
for I2C, you have to make sure that every device on the bus has a different address, it's much harder to automate vs CAN and SPI and I2C should never ever leave the board

[ZeroResistance]

Already mentioned, try RS485, RS232, CAN or LIN.

All those methods would require a driver and a microcontroller next to the sensor, won't they? I was trying to avoid that, but looks like there would be issues mentioned in the earlier posts.

I was even considering using differential line drivers for clock to extend the length of certain high speed traces for say SPI.

[max_torque]

Given that you can buy a CAN enabled micro controller for ~ £1  and even less for a basic micro that has a UART from which you can buffer out as RS-485 with a suitable (cheap) transceiver, unless you are on a REAL tight budget, then there is no reason to  not develop a "smart" sensor.  That processing power on the sensor can be used to report all sorts of useful info, from diagnostics to automatic set up data etc

Something like a CAN or RS485 transciever includes lots of sensible real world protections, and have become industrial and automotive standard for good reason.  There are also plenty of existing products that use either CAN or RS-485, meaning if you pick a standard protocol (say modbus) there is no reason your master cannot have already existing slaves added into it's network, massively widening the options for system set up.

Classic Modbus modules are cheap and widely available, eg: http://www.advantech.com/products/rs-485-i-o-modules-adam-4000/sub_1-2mlkht

[Eka]

I formerly had a few I2C sensors at the end of a meter long shielded cable connected to a Raspberry Pi Zero. A few times a year a lightening strike close by could knock out a couple of the sensors. The system then had to have a full power off power cycle for the glitched sensor to start working again. Not easy when the power supply has a battery backup in it. I've had a lot less lockups now that the sensors are on a 30 cm cable, but they still happen. Next revision of the hardware will have the sensors connected through a normally closed TPDT relay. That way I can power the sensors down without powering down the whole system. I'd switch the Vcc, Data, and Clock lines. I'd keep the grounds connected. The dual trow is so the relay grounds the lines when it switches the sensors off to reset them. The I2C bus has proper termination, and transient voltage suppressors (TVS) to clamp the signal lines and Vcc voltages to a maximum of about 6 Volts above ground, and a volt below ground, but that is enough to glitch a couple of the sensors.

The system does have a bucket tip type rain gauge, but it is optically isolated using an optical link.

[T3sl4co1l]

RS-422 transceivers can extend SPI trivially.  Just add interfaces, and twisted pair cable.  Don't ignore ground, everything is still common ground, and still prefer shielded cable for best results.  (RS-422 receivers have a generous immunity, so they can tolerate a fair bit of noise via unshielded cable.)

It's not very efficient on wires, but it's very easy to realize.  The cables are easy, too -- you can buy 5-pair ribbon cable that's got twisted sections, followed by flat sections where IDC connectors mate as normal.

RS-232 and RS-485, with various protocols (and for 485, bus arbitration), are very common for industrial sensors.  CAN bus.  Maybe Profinet, haven't heard it much around here but I recall it's broadly similar.

If heavy-weight solutions are okay, there's always Ethernet, and a facility probably has an existing network of it.

For max 2m, I would mind, but accept, I2C on shielded cable.  SPI (CMOS level) on shielded cable, with terminations, and maybe added Schmitt trigger receivers, would be a little preferred over that.  RS-422 seems a little over-the-top for this range but will be very reliable, even moreso with a shielded cable.  I don't think you'd worry about anything else, unless say you've already got a CAN bus in the project so you can just tee onto that.

Tim