How about 10/100BaseT ethernet with Power-Over-Ethernet? Although most IEEE802.3af or -at modules do cost a bit much, there are lower cost POE modules available too, like SilverTel Ag9050-SI ($13?) for example. With an ethernet-enabled device, something like a Raspberry Pi (B model with Ethernet for $35), your hardware costs would be over the range you indicated, but you'd only need one Ethernet cable, up to 100 meters long, to each node. You could bring the cable to inside the IP67/NEMA4 enclosure, so you'd only have one cable (plus sensor and motor leads) to protect.

Of course the client would also need a power sourcing switch (PoE switch), which increases the overall costs. On the other hand, it would be an easily extended tree network using off the shelf components, with very few limitations to hardware scaling to thousands of devices. Note that only the "leaf" switches connected directly to the devices need to be PoE, the trunk ones can be normal ones.

Raspberry Pi, a NXP LPC1768 board, or any other of the more powerful boards should have no problem in providing a normal TCP/IP Ethernet control interface, especially if they run an embedded Linux like Ångström. Raspberry Pi, for example, has both floating-point support (nice for math calculations), and an SD card slot for storage. This would mean you do not need a server at all, as you can store all data locally in each node. You would supply a cross-platform user interface for managing the sensors, as well as collecting the logs; the client could put it on as many machines as they need -- a ruggedized laptop in the greenhouse itself might be mighty useful. Both Python and Java have good TCP/IP APIs, so the user interface should be no problem.

I would be careful about relying too heavily on wireless technology in a greenhouse. The distributed pumps may generate EM interference, and if the structures are metal or heavily metal reinforced, they may block the signals. Water pipes might also block the signals.

Caveat audiens: as many members have pointed out, I tend to overkill.

1 members found this post helpful.

I would most likely stick with RS485. The converter is about $1 and I would be paying for cable and hub blocks of my own design. I would need the 3000 foot range of RS485 as the facilities are large. The synapse SNAP radios go from 1500 feet for the $15 chips to 1.5 miles for the high power systems with antenna ($45) I still have to bring 24VAC to the sensors to fire the solinoid valves. See: http://www.synapse-wireless.com/

I agree that you should have a zener diod installed. You will get transients in the system. People and nature do a lot of stupid things.

"power" is a vague term when you talk about EMR and antenna. 0.001w in a 1/4wave omni (basic stick antenna) can suddenly look like 1w if transmitted by a tuned yagi. yagi's increase directional power density (careful you dont exceed fcc levels, etc).

my guess is, if the SNAP radio has 1500ft onmi range, then you can likely double or even triple that range with a yagi. SNAP is unlicensed 2.4GHz band, common kitchen microwave, so be careful about attenuation by water.

The 2.4 GHz transmitter and receive antenna will be covered with water which is as you say in the water band. I will for the first cut be using cat5 cable with rs485 protocol. The rs485 must be biased to vcc and ground which counts as 20 loads. RS485 allows 32 loads. That leaves 12 loads free but my rs485 driver chips present 1/8 load so that means I can have 96 devices on the network. One thing that may be a problem is updating software in the embedded linux system. In my PIC system devices I have commands to access a bootloader and then do a system restart after the load is complete. Something similar will be needed in the embedded linux computer to update linux if needed. (or my deamon). Also updates to the html files on the embedded system will need to occur. I guess they will be located on the sd card. Any ideas will be welcome. Alvin...

Primary storage for embedded Linux is often flash memory of various types and in various combinations. One common configuration is to have a bootloader in onboard flash, and removable flash such as Compact Flash or SD card for the root filesystem. You can then update the OS by replacing the removable flash media. You could also do updates over the network using this configuration.

--- rod.

1 members found this post helpful.

I am wondering if an SD Card will be up to communicating with files between the daemon and the php routines or the normal logging of data (as well as logs) from the devices. Maybe it should be a hard disk. Should a copy of linux be located on the SD Card/Disk so that it could be updated over the internet? Then it would have to load from the SD card on powerup. The php/html would have to located on the SD card. Also developement would be easier/ more straight forward from a ram system connected to a hard disk and running a copy of say Ubuntu.

What aspect of the SD card are you concerned about? Performance (speed), capacity, fault tolerance/robustness, something else? As I said, SD flash as primary storage is a very common configuration. Booting from such a system is also common.
Your development environment doesn't have to be anything like the production system. Emulators and other means of accomplishing rapid test and debug turnarounds will significantly improve your productivity in code development. Stuff that is generic web application can be done on any well-equipped development host that supports the same tools such as Apache + PHP, and should be completely portable to an embedded target. Ubuntu may serve that role. Debian seems to be the platform of choice for a lot of software developers, especially for embedded systems.

--- rod.

SD card should be fast enough. choose wisely.
http://en.wikipedia.org/wiki/Secure_Digital

also, will the SD holder/pins/card be sealed in some way? if its a high humidity environment you need to make sure the pins wont oxidize, etc.

Been at the Embedded Linux Conference in San Francisco CA this week. Heard a lot about MultiArch, Buildroot, Yocto, OpenEmbedded. Also heard about IPV6, BeagleBone, and eMMC. There were some negatives about MMC especially that you can get errors without the card telling you that the data is corrupt. But I will pursue the SD Card but probably first will develop on Ubuntu on an x86 system with a hard disk. I bought a Dell Latitude D830 laptop (2.5 GHz with 4GB for $85) at a Virginia Tech State auction. I put Ubuntu on (10.4) it but it has some problems. So I think I will download the latest version and install it. I would mount the sd card in a NEMA4 box (IP7?) with cables coming out of a septum port that would seal around the cat5 cable. Also heard that a $25 arm board will be out soon (from Angstrom?) You should look at the ELC 2012 videos out next week on the Linux Foundation website about IPv7 as the talk was very good and went over some of the software changes to the kernel APIs . More later. Alvin.....

My first cut for a Linux daemon and test program will be a program to send out an inquiry to the attached device and receive the result over ttyS0. Then I would like to display it on a web client. I guess I could initiate the daemon by the client with a php call from the client to Apache ( I doubt that the first try will be to a web site with existing dns - note that I do not know what I am doing here ) I guess over a null modem Ethernet patch cable. This will exercise me with all applications but I will most likely start with the daemon printing out to the terminal. I still am not sure how to go from the daemon to apache which was the first question on this thread. I guess having php initiate the connection to the daemon will provide some form of path that can be followed back to apache to then display the results to the client. If I can get that working I can then probably do the rest with no problem. Any ideas would be greatly appreciated. Thanks. Alvin....

PHP to serial??
http://code.google.com/p/php-serial/

for testing you could build a simple form in the html with a dropdown with all of your test messages you would send, then submit it to the php page where is extracts the message value and then php makes the send to the serial with the message.

is this what you are asking?

I suggest NOT using an ethernet cross-over cable (not null-modem, which is an RS-232 concept), but rather use a hub or switch to connect all of your devices during your development phase. A hub is best for doing testing, as it exposes all traffic on every port, which makes sniffers more useful.
Your daemon process that talks to the field-bus devices should also expose some IPC interface, so that CGI processes launched by the web server can get and put data to the daemon.

Keep all software layers of the system separate, and try to arrive at optimal interfaces between the various components, so that maintenance and future upgrades can be performed independently. This is the real key to a robust and expandable system; finding the right balance of generalized capability (for future and present flexibility) and simple, elegant, efficient functionality. You want to be able to develop expanded capabilities for the system (trust me, you do) without making it so complex that it is a nightmare to maintain and understand. Perhaps model your interfaces after existing industry standard protocols such as Modbus, VXI, many of the web-oriented protocols such as SOAP, etc, for ways of talking to the fieldbus-attached devices.

You seem slightly short of completely understanding the relationship between many of the WWW components. I'll try to summarize quickly here:
a browser (HTTP client) makes HTTP requests (GET & POST, mainly) for a URL form an HTTP server (web serever). The web server, such as Apache, may launch a CGI (child process, that you write) to figure out how to compose a response to the client's request. This is often (but not always) the action invoked when an HTML form is submitted by the browser. The CGI gets some information that it can use to determine what it should do (commonly from the form elements). It can also do almost anything else, within the limits of the privileges which it has. I suggest the your CGI forward the HTTP request in some form to your daemon process, and also receive response data from it, as applicable. There are some well defined, efficient, and appropriate Interprocess Communications (IPC) methods available to facilitate this. This is one of those interfaces between layers that I mentioned. The CGI composes a complete HTML response, which it writes to its standard output (assuming Linux), and the web server merely shuffles it back to the requesting browser, where the HTML gets rendered as a new page. As an alternative to a CGI application, the web server (not the browser) may invoke PHP to compose the HTML page which will be returned back to the browser. The PHP code may also be used to communicate with your daemon process. You should feel free to use either or both PHP and/or CGI to perform the work at this level.

Using standard IPC methods allows you to communicate from any application, not just your web application. You can develop, test, and debug the daemon layer completely without worrying about the rest of the system. You will find that this promotes the use of small, well trusted tools that you can use for doing testing and diagnostics as you build up the rest of the system. These will be the tools you fall back on when something breaks, and you wouldn't otherwise know where to look. Build up application-related higher-level functions into a re-usable API library, so that your test applications and your production applications are all based on the same code.
--- rod.

The only thing I feel I need to mention is that I think fieldbus implies eithernet where I am using RS485. One thing I am planing to do is implement a one wire bus in parallel with RS485. It will be open collector and when a device wants to talk on the bus it will first check to see if this wire is pulled low implying someone is talking on the bus. If the wire is high then the bus is free and that device can then pull the bus low to capture it and indicate to the other devices that the bus (RS485) is in use. The only problems I see here is A)a possible race condition which I hope to take care of by 1) the bus is slow (38000 BAUD) 2) I will try and make a random time out after the device sees the bus in use. B) The bus will most likely be highly capacitive (3000 feet long) and thus slow but I sould be able to calculate the capacitance (worst case) and resistive load which should give me a worst case delta t which will most likely be helped by adjusting baud rate down. An idea that just hit me would be to make the bus differential using two wires to help speed it up (I have one wire spare including the one wire bus wire). Thank both of you for your excellent ideas and help with the linux box implementation.

yeah, i think using LVDS/TMDS over ethernet at 3k ft might be a issue (although it is better for handling noise). can you use rg59 coax for the single wire bus, that should give ok shielding?