I’m working on my first xbee project and need a little advice as to which way I should tackle it. I have series 1 xbee pros and will be connecting them over distances of around 200m outdoors.
The fundamentals are that I will have one 3G connected arduino with xbee centred in the field with 4 digital sensors each connected to their own xbee. Every unit will be solar powered. The sensors will be going high for various lengths of time but I am only interested if they go high and back to low within a short period, say 500ms to 2000ms. When this happens I want the central arduino to log it. I don’t need to know which sensor has triggered, the data is treated as one and the same.
What I need advice on is:
a) should I be using beacon or non-economic(w/coordinator) mode?
b) should I have an arduino at each sensor use IO line passing to send a pulse if the sensing period is within my criteria, or should I ditch the arduino at each sensor point, using only xbees with IO line passing, and do the criteria matching with the central arduino?
Does it matter how many milliseconds the digital level was high? Or just that it did within that period? And is the time of this happening important? To what resolution in milliseconds?
The Xbee series 1 do not have a means to check for how long a pin stays high. It can only forward the state of the digital pin to another Xbee. And in the transmission of that there may be a bit of lag or skew if they are not constant on (if in sleepmode because of solarpower). So that pulse duration on the receiver side may not be that accurate to rely on.
It’s the time that it stays high for that’s important. So to alleviate any lag I’d be better off using an arduino at each end point to check how long the sensor is high, and only if it meets the criteria then send a line pass to the xbee, and at the central controller accept all incoming line passes as a success.
If that is the requirement then I wouldn’t make use of the linepassing functionality. Good timing is important I understand from your requirements. I’m not sure if the Xbees can deliver on that. Use an arduino to measure the time the sensor line is high. It’s clock is much more stable than delays encountered with RF transmissions. Preferably you want to be making use of sleep modes and the interupt pin to wake it up when the sensor triggers up or down. And then make it wake up the Xbee by a pin when needed to send the time-data as serial-data. Having them always on is not good for battery life. Since you want this to be solar powered you need this to be as energy efficient as you can. Research how to use sleep modes on a Arduino board. This may requiring stripping the Arduino board from non-essential components that guzzle current. You may need to remove leds, pull-up resistors or disable the voltage regulator to do that. For simplicity you can try without doing that, but it will help battery life.
Valen:
Does it matter how many milliseconds the digital level was high? Or just that it did within that period? And is the time of this happening important? To what resolution in milliseconds?
The Xbee series 1 do not have a means to check for how long a pin stays high. It can only forward the state of the digital pin to another Xbee. And in the transmission of that there may be a bit of lag or skew if they are not constant on (if in sleepmode because of solarpower). So that pulse duration on the receiver side may not be that accurate to rely on.
But! XBee series 1 has pin change detection with virtual wire a.k.a. “IO Line Passing”.
The receiving end will get a message when the input pin on the sending side changes 1 to 0 to 1. The pair will recreate that 1,0,1 on the corresponding pin at the receiving device. You can also direct these IO changes to the UART, formatted as the standard Digi API (0x7E…)
Accuracy is necessary for determining how long the sensor is high. Once this is determined there is no real requirement for accurate timing. I think the most simplistic form of what I’m trying to achieve is:
if any of my surrounding sensors (1,2,3 or 4) is high for between 500ms an 2000ms flash D13 LED on central Arduino. The important thing here is if 2 or more of the sensors consecutively meet the criteria I still need to see discrete flashes for each on the central Arduino.
Sounds like the best way to achieve this is an arduino (or similar) connected to each of the sensors to read the sensor state and send a serial string to the xbee if criteria is met. Central arduino (or similar) will wait to receive serial string from its xbee (regardless of where it’s come from), and upon receipt issues a blink to D13. Am I right in understanding that if multiple strings come into the central xbee it will buffer these and the arduino will process them one at a time?
Is there any need for me to use nonbeacon w/coordinator mode?
I need the MCU to determine whether the sensor has been high for between 500ms and 2000ms before going low again. If it’s high for more or less then that time period I need to ignore until the next time it goes high.
What I’m now considering is how I’ll make sleep work, for both the arduinos and xbees. I figure I need to break it into 2 separate processes.
a) Use the sensor output to wake the arduino and check the state of the sensor against my criteria. Then save the result of that to a variable as an incrementing counter and go back to sleep.
b) Wake the central arduino with a watchdog timer (I’m thinking every hour). When it wakes, wake the central xbee. Now from this point can the central xbee wake the node xbees? What I’m thinking is if it can do that, then I could have a code send a line pass or something to each node xbee, thus waking their respective arduinos then firing code that sends the result of its counter before going back to sleep again. My central arduino would ‘poll’ each node in this manner, combine the data and then do what it has to from there.
Does this sound reasonable?
[EDIT]
I have just realised how silly this sounds. I can well imagine that I can’t wake a sleeping xbee from another xbee as the very means by which they communicate is effectively ‘asleep’. Okay so in that case perhaps I should look at the cyclic sleep function and somehow tie that in to each respective arduino.