XBEE application question

localroger

I have what is probably a simple XBEE application. I realize that to actually build this I'll have to get the book and spend some time figuring out how to configure and program them, but before asking my boss to commit time and money I'd like to be sure it will work the way I think it can, and that I'm getting the right hardware.

What I will have is four industrial sensors which transmit continuous RS232 data. These cannot be programmed or substituted. They must talk wirelessly to a display, which might be a built-up Propeller console or a PC with USB XBEE dongle, which will sum the data from the four sensors and display the four source values and total in real time and possibly record and time stamp changes.

Low power, high speed, and latency are non-issues as this is a large, slow system. New packets will be transmitted by the sensors once or twice a second. Range needs to be about 50 feet, though more would be better. Cost for the XBEE hardware is not an object (the cost for other hardware in this project will be over $3,000). I will need to sort out which sensor sent what data -- they are not programmable and the data they transmit won't uniquely identify them. I realize that the display will probably have to operate in API mode. What I can't quite sort from what I've read so far is exactly how the display software will need to do to receive and separate the four data streams and if there is a minimum level of XBEE hardware I need for this to be possible.

Thanks in advance if anybody has some experience with this.

Duane Degn

Be aware of the book "Building Wireless Sensor Networks" use the Series 2 (ZigBee) versions of the XBees in its examples.

I personally don't know how to do what you want without adding a uC to each sensor but I bet the Series 2 XBees could do this. I think the Series 1 XBees probably could also.

ElectricAye

localroger wrote: »

...Range needs to be about 50 feet, though more would be better. ....

Having just started to tinker with the Xbees (1mW version), I can't give you much advice, but I have noticed one thing that perhaps you'll want to think about: the signal strength drops dramatically when anything is standing in its line of sight. Even holding an Xbee in your hand and turning around so the signal must pass through your body will drop the signal strength quite a bit, so if these things are being mounted in an environment in which lots of people or vehicles are crossing the signal path, you might find your signals won't always get through. Using the 60mW versions might burn through the human bodies, but I doubt they could bore through metal objects, etc. On the other hand, I suppose you could form networks and such, and with the right geometry perhaps you could obviate the possibility that objects could completely interrupt your transmissions.

Just something to think about.

localroger

Thanks Duane, I went ahead and ordered the book based on a look-inside at the table of contents. It seems likely that the sensor XBEEs will be able to work on their own once configured by a uC. Adding a uC to each sensor would be close to a deal killer, though, as these things don't have much room inside and they need to stay waterproof.

localroger

Thanks for the heads up, ElectricAye. I have no trouble springing for higher power or, better yet, 900 MHz with external antenna if I can get the data functionality straightened out.

Ron Czapala

If your sensors are going to be close to a wireless router, you might want to consider the RovingNetworks RN-XV WiFly module -

it can be configured to automatically connect to a web server upon receiving data on the serial uart (page 58) MANUAL

It is an XBEE configuration. Setting up each module with an IP address and having a webserver handling the data might simply things like multiple units sending at the same time, etc

localroger

For reference, I found the answer in the book Duane suggested; it's very clear that my application can be done with series 2 XBEEs in with the controller in API mode. It also hints that you can receive data from multiple sources in the simpler AT mode, but it comes in all jumbled together with no way to sort out who sent what. It might be possible to do the function in AT mode by using AT commands to switch ID's, but API mode should be straightforward to deal with in Spin.