X-Number/Unlimited Attached Sensors/I/O Daisy-chained

[kenmoini]

Hello there,

I've got a rather large project to work on. I'm currently trying to formulate and develop a system to use in greenhouses. This system will control lighting circuits, exhaust, air/water pumps, dosing equipment, etc. There are already comparable systems out there, but they lack the features, are too complicated to configure and use, aren't as interoperable as I'd like, a far from open-source, and otherwise rather expensive.
My plan was to use a wired interface while I was developing the general system/sensors/software, and add wireless capability with either Xbee or JeeLink. The original idea was to use one cable to daisy-chain the sensors...RJ45 probably, with the I2C lines, 9V, 5V, GND. Then the sensors have an I2C GPIO expander (MCP23017), power regulator/converter, and the sensors attached to the MCP23017. That was all fine and dandy till I read the spec and found that they can only be set to 8 different addresses with the three addressing pins. So now that's out since I need to be able to support more than 8 sensors. I looked into a Dallas 1-wire interface, but the selection of sensors and interfacing devices seems to be lacking.
Is there any interface that I can easily attach the maximum amount of sensors to and have them easily connect to the Raspberry Pi via a common daisy-chained connection without having to worry about limits on inputs/outputs addressing or collisions? I'd like to not have to build addition chip-selection circuitry, and simply have this handled by addressing and references.
I could go straight to wireless, but that still requires having A) lots of attached battery packs, B) Extra power outlets, C) a common connection anyway (at least for power), D) additional overhead cost, E) All/Many of the above. Would the best method be to go about the wired-interface be to use the basic Atmega328 and just add the basic circuitry to support the IC/sensors per sensor, and send data over a common I2C? Could address up to the 128 max I2C devices per RPi?

If this daisy-chained wired-network seems confusing, GrowTronix uses a serial 1-wire network daisy-chained over RJ45, but again this 1-wire Dallas-based network has generally limited sensors/control over input/outpt (from my understanding).

[gordon@drogon.net]

Why not just put one Pi in each greenhouse. Then you can run Cat-5 between then, or use Wi-Fi.

So, develop the ultimate sensor module for a confised area - one green house - then copy that to the other green houses and network them.

simples...

-Gordon

[kaos]

This strikes a chord. I have been mulling over options for a similar network, though in my case I was thinking of a home- rather than greenhouse automation, but I think the requirements might be very similar.

First, re. Gordons suggestions of "more Raspis": This would be a good solution when either the number of sensors/actuators is limited, or their locations are clustered, so that many of them can be connected to each Raspi without special transceivers. If, however, you have a large number of sensors and actuators, fairly evenly distributed over a sizeable area, I think some form of lightweight network would make better sense.

My main conclusions to date:
-Use RS485 (see http://en.wikipedia.org/wiki/RS-485) for transport. This is a "multi-drop" (meaning, for practical wiring purposes, daisychain-able) bus, using differential (twisted wire pair) signalling for long reach. (Up to 1200 meters according to that wikipedia article, but I suspect that that is a best case, using special RS485 cable, low baud rate, and few devices connected. But, even if we can only manage a tenth of that reach, I think we would have solved very many problems.) Transceivers for this bus are also very cheap.
-Use CAT5/5e/6 network cable and RJ45 connectors, as these are both ubiquitous and cheap. This cable is not a quite perfect fit for RS485, which calls for 120 ohms characteristic impedance and shield, while network cable has a characteristic impedance of 100 ohms, and while you can get it shielded (STP; shielded twisted pair), the more common and cheaper variety is unshielded (UTP; unshielded twisted pair). The impedance is close enough though, that it has been used successfully for RS485, and I expect that in a reasonably interference free environment, even the unshielded version will give good results.
-Another reason to use network cable is that it gives us extra wires which we can use for power delivery. Not very high power, since the wires are thin, but sufficient to run a microcontroller and a few sensors; more power hungry devices, like most actuators, would still require their own power supplies.
-As RS485 only defines the transport layer, we will need to select or design a communication protocol. Here, I am not quite certain what is best. I have been looking at Modbus, which is a common protocol for industrial devices, but find it a bit limiting. I would have liked to extend it with stuff like automatic address allocation and standardized device ID and capabilities reporting.
-Last but not least, drivers and software will need to be written for the Raspi, and a reference firmware (to be adapted to each case) for the microcontrollers of the slave devices. I could handle the microntroller end, once the protocol has been settled, but I am a Linux noob, and I confess that I find the thought of jumping into the deep end by starting my "Linux experience" with writing device drivers, somewhat scary .

I have some more thoughts on this matter (how much power we can deliver, how to make the best use of it, best wiring scheme, how to implement automatic addressing, etc.), but this post is already too long. I can expand on it later, if anybody is interested.

--
Best regards, Kári.

[kenmoini]

Re: Gordon...
Well, a few reasons as to why I doubt I could apply that setup you described...
A) I'd like to have the environment setup/configured/defined by software rather than the network/hardware.
B) Equipment varies quite a bit, as does the environment with the different greenhouses. As imagined, various crops, different sizes (depending on harvest cycle, profitability, light dependencies, etc), so again it'd best be to design the relationships via software that can handle expansion and alterations.
C) I'd like to Open-Source the controlling software, as well as the hardware. Again, having it modular and controls defined in software makes this a lot easier for others to pick up without having to deal with a bunch of IO planning; plug-n-(maybe-ARV-burn)-play.
Otherwise, I'm planning on maybe connecting a bunch of Atmega328s via I2C, your work with the Q2W is interesting...seems like your expansion board has I2C daisy-chainable support? Up to how many devices?

Re: kaos...
Thanks for the heads up on the RS-485 spec, I'll have to look into that more.
Currently my head's at the point where I'll end up basing the sensor modules around an Atmega328, have the supporting circuitry and basic sensory ICs/Diodes/etc, and it communicates back via an I2C line. Connected to a Cat5e line via MagJacks (to better support PoE), has a 9v line that is regulated down by the sensor modules' supporting circuitry, the I2C lines, and I have space for maybe a FTDI link? Thinking I can program/upgrade over the FTDI if there are updates to sketches for better sensory processing. Also don't mind the notion of having to burn/configure address via a quick connection to the RPi, and then placing sensor on network. As I understand it, you can connect the Arduino/Atmega328 to a RPi, is there a limit on the number of devices/addresses?
I'm going to pick up a few JeeNodes cause they're close to what I'm wanting without much prototyping right now, and very competitive on pricing vs DIY (w/ the radio that is). If they work well enough, I might just try to have the whole network communicate wirelessly, and just be powered (maybe fall-back com link) via the RJ45.
Lemme know if you have any additional insight (especially with your mentioning of ideas on addressing/powering devices)

[jasonclark]

+1 for RS485, if you can go 4-wire, the circuit may be simpler - basically you only need a line driver on the UART of the 'Pi.
Keep the baud rate as low as you can, and it'll be a nice system.

Otherwise, SPI is a nice multi-slave device system, but not really recommended for external devices due to cable length.

A nice system could comprise of a ucontroller (Pic/AVR or Arduino) managing each sensor, giving a nice easy comms link over RS485.

[kaos]

I'm afraid I2C and SPI are short range standards that will be unreliable at a few meters, and flat out unusable at a few dozen. I really do think that RS485, or possibly CAN bus is the way to go. Some alternatives I have looked at:
-RS232: Point-to point connection (no daisy chaining). Short range (15m according to conventional wisdom; the wikipedia article claims up to 300m with appropriate cabling, but frankly I would like to see that before I believe it).
-Ethernet: Point-to-point connection, albeit with standardized distribution equipment. Fairly expensive. In fact, one of the cheapest ways to get ethernet connectivity for a device is to build it around a Raspi, which brings us right back to Gordons suggestion of a Pi-per-device.
-1-wire: In many ways attractive, but you pointed out yourself the chief drawback; limited number of available device types, with no way for the DIYer or small scale manufacturer to add to the variety.
-Powerline comms, f.x. X10. Advantage in that it makes use of existing wiring, but every device then has to deal with mains voltage, with attendant risks and costs.
-CANbus. In my view the only serious contender to RS485. It has a clearly defined protocol, so we wouldn't have to design that, but on the other hand we would have to abide by it, and it seems to be fairly complicated. In fact is seems that it would demand either a fairly high powered microcontroller, capable of running a pre-made CAN stack, or a dedicated CAN controller chip, either of which increases costs.

Re. limit to number of devices/addresses: Depends on both the communication method and protocol. For example, RS485 specifies max 32 "unit loads" but many modern transceivers have much less than one unit load, so more can be added. Addressing schemes may also limit the number of concurrently connected devices, but even the simplest of them will usually allow for ca. 256 devices (8 bit addressing, with perhaps a few addresses reserved for special tasks).

Re. JeeNodes: Thanks for mentioning those, they look interesting.

Re. addressing: My idea is that each network would have one master, which would poll the other nodes for data (this is more or less forced by the RS485 standard, which dictates that only one device can transmit at a time). Each slave node would by default have an address of 0. The master would periodically (maybe once every second) poll that address, and if a device is found, assign it the lowest previously unused address on the network, which the node would then store in non-volatile memory. Thus, when adding nodes you would have the master running and just plug in the nodes one by one, keeping track of the order in which they were added. When you are done, you would go to the master and bring up a list of recorded nodes, where you could add a label/comment to each of them. The node should also have some form of reset mechanism which can be used if it is moved to a different network where it's old address could cause conflict. This could be as simple as a jumper that is checked by the firmware on power-on and, if present, cause it to reset the address to zero. With this method minimal extra hardware would be required on the node; only one jumper, no DIP-switches, keypads or displays needed. Also, each node would have a permanent address on the network.

Re. power: Cat5/5e/6 wire generally uses 24AWG wire, which is about 0.5mm diameter, or about 0.2mm^2 cross section area, and has a resistance of about 94 milliohms per meter. It seems that 0.577A is the max recommended current for "power transmission" over 24AWG wire. We could dedicate two of the four wire pairs to power transmission; one pair for power and the other for return. The return could also double as a ground reference for the RS485 transmission. Thus, we could transmit max 1A over the cable.
Now to decide on the voltage. With 94 milliohms per meter, 500mA means a voltage drop of 47mV/m. That is for each of the power/return legs, meaning a total of 94mV/m, or almost a volt for every 10 meters. If we take your suggestion of a 9V source, and if we assume the node will run at 5V, and further assume we will be using a standard voltage regulator, requiring 7V input, we can only afford to loose 2V in the cable, which, if we are using 1A (500mA pr. wire) means a maximum cable length of about 20 meters. There are, however several ways we can improve these figures:
-Use less current.
-Use a higher source voltage.
-Use low-drop-out regulator at the node.
-Run the node at 3.3V rather than 5V.
My suggestion is a combination of several of these points:
-Limit the current consumption to 500mA total (250mA pr. wire). This also means that a single fuse or polyfuse can be used to protect the bus, as even if one wire breaks, the other will not be called upon to carry more than it's rated current.
-Use an 11 to 14V source. This could be a sealed lead-acid battery of the kind used in UPS's, providing backup in case of power failure.
-Require the nodes to run at any voltage between 6V and 14V. They could meet that requirement either by using LDO regulators or by running internally at 3.3V.
In combination this should allow for over 100 meters between master and slave(s) ( (11-6)/0.047 ).
Now, 500mA may not sound too bad, but remember that that is the total bus current, which will have to be shared amongst all (bus powered) slave nodes. If we assume 30 such nodes (keeping within the limits of the RS485 standard), that's 16.7mA pr. node, which might be too low to even drive the transceiver in transmission mode reliably, let alone power the rest of the node. My proposal is to limit each node to 10mA in normal/standby use, but to allow up to 100mA during communication with the master. This makes use of the polling nature of the RS485 bus, which means that only one slave will be communicating at any time. While 10mA isn't much, it is enough to run most low end microcontrollers, plus a reasonably frugal sensor or two. For more power hungry sensors or other applications it might be possible to run them only during communication with the master, taking advantage of the power boost available then. And of course, a dedicated power supply is always an option for those cases for which the limited bus power just isn't enough.

--
Best regards,
Kári.

[gordon@drogon.net]

One reason I suggested one Pi per geenhouse is because I've done this before - only it wan't green houses it was a factory automation project. The Mk1 version featured each "station" (ie. greenhouse) with a BBC Micro as the station controller and a custom made IO board (another 6502) to control the loading robotics and pallet transport system. The Beebs were networked (Econet) and there were also a number of stations (Beebs) outside the factory floor where we could monitor the overall system, or zoom into one station and activate local controls, check its job queue, etc. The Mk2 as custom-built industrial computers (transputer based) talking on a token ring network with PLCs for each station control. (The stations were usually a CNC machine with loading/unloading robotics to take pallets, etc.)

Each station also could act independantly - if they network went down they'd keep on working as they had a job list, so work could still come in, be processed and sent on to the next station.

So in the greenhouse scenario, each Pi can have the high level data needed to keep that greenhouse going - know it's temps. watering needs, etc. and comminucate that to peripherals either with its on-board GPIO or via a separate microcontroller (e.g. Arduino) Then you can have an overall control system to query each node, send it data (temp, watering needs, etc.) get back data its stored (or have all the nodes store in a database) and you can use Ethernet or Wi-Fi for that. And if the network goes down, then each Pi still knows what it has to do to keep that greenhouse running.

If you're talking really big distances (over 100m) then fibre is the way to go - and Ethernet over fibre "just works" You can use the various 2/4 wire serial interfaces and some will go that distance, but it'll just add to the software complexity.

What you can then do is develop a generic controller - Pi + IO system each running more or less the same software with a control file to tailor it for that greenhouse - ie. how much water & when, how hot and when, lights and so on. With a minimal web server running in each one you can query them individually from anywhere else on the LAN, or update their local data, etc. or uploa a whole new profile when you turn a greenhouse from tomato to marigold mode ..

Simples

-Gordon

[kaos]

I agree that ethernet is attractive in that it is "ready to run"; standardized both in terms of equipment and protocols. And if we are only talking one, or even a few, Raspis per greenhouse, that would be an excellent solution. But that leaves the problem of connecting the various sensors and control devices to the Raspi. We could bring all the connections back to the Raspi, but even that would in some cases require special interfacing/transport arrangements. For example, if a temperature sensor returns an analogue voltage proportional to the temperature, how do you bring that to the Raspi over a distance of tens of meters? One answer would be a current loop, but then we have to design that (or adapt an existing design). Also, this could require a great deal of wiring, if the setup is complex.
Hence the idea of giving each sensor and actuator a minimal intelligence by using a low cost microcontroller, and connecting them via a network, preferably multidrop so they can be daisy-chained, thus further reducing the amount of cabling. If we can also, via the same cabling, provide enough power for at least the more lightweight nodes, that will further reduce cabling complexity, not to mention the cost of power supplies. Of course, giving each sensor/actuator it's own controller makes them very cost sensitive, due to the high number of them. I would like to keep the basic BOM (for microcontroller, transceiver and voltage regulator) to less than 2 dollars, 5$ absolute max.

While writing this it struck me that this is essentially the same problem the CANbus was designed to solve in cars: Traditional car wiring is based on switches, relays and simple components. As cars evolved and demands rose for automatic-that and power-the-other this meant the wiring was becoming seriously complicated. Just think, in your drivers door you might have controls for all the cars power windows, door locks and mirrors, and in the steering wheel, controls for cruise control, radio and transmission, and I haven't even mentioned the instrument panel or air conditioning system. With the traditional approach, each of these switches requires at least one wire, sometimes more, to be brought, often via difficult routes (think of the steering wheel which has to be free to turn several turns each way) to the actuators. This can be solved via CANbus, by setting up command modules at each such concentration of controls, thus requiring only the single twisted wire pair plus power connections to the rest of the electrical system. At the other end, a controller for each actuator (or group of actuators) listens to the bus traffic and responds only to those messages directed at them.

--
Best regards, Kári.

[DAmesberger]

We offer an RS-485 extension board to the Raspberry Pi - RasPiComm.
Have a look at our forums. You can build it yourself and use our drivers (we have the schematics online and also supply open-source tty-device drivers to interface with the RS-485 port) or buy the RasPiComm at RS-Components.

Have a look at http://www.amescon.com
or directly to our forum: http://www.amescon.com/forum.aspx