Waking a remote xbee from another xbee via wireless

lrtnorfolk

Good Evening,
I have a project that involves a propeller, sonic range finder, and a temp sensor. The project takes a temp and range measurement every hour, reads the clock, and saves the data to eeprom. About once a month, I would like to download this data wirelessly (via xbee). I just ordered two xbee pro's. After looking over documentation, I am a little confused about the sleep mode. You see, I would like to place the remote xbee (connected to the project) in hibernate (for a month)... until it is woken up from another xbee's transmission (the xbee that will receive the data). Is this possible? Any and all comments are much appreciated. Take care.
Renee

groggory

If an xbee is sleeping you cannot wake it from a remote host. The reason is that it's receive radio is not turned on. Simple logistics there! :-)

Read this...
http://www.digi.com/wiki/developer/index.php/Designing_a_Sleeping_XBee_Sensor#Cycle-Sleep_-_The_XBee_Controls_Sleep

Tell us a bit more of your situation. If you can have an always-on 'server' ... or have a server that you turn on on the 30th of every month... or ...

There are a lot of questions to ask before we can come up with the best solution for you.

Please delve deeper into your project requirements.

Tracy Allen

I faced this same issue in a data logger where someone would pass by every few weeks with a "reader" that would offload the data remotely. The XBees are not in a network, just one here, one there. Power has to be conserved as much as possible. The way I have it now is that the remote XBee comes out of sleep and initiates a broadcast API packet at 20 second intervals. The packet contains essential information like the MAC or MY address of the sender as well as the most important summary data. After it transmits, it listens for a response. The packet transmission takes less than 10 milliseconds and we allow 40 milliseconds for response, so the XBee is on for about 50 milliseconds at 50 mA. That averages out to 125 microamps. Broadcast mode does not retry, so that saves energy. It's possible to reverse the direction of the pings, so the remote only listens at intervals and the reader pings repeatedly when in the vicinity and listens for the response to get into sync. It doesn't make much difference with the standard XBee, but it would with the XBee pro where the transmit current is 5 times greater than the receive current. I also save energy by activating only during a window of time during the day as determined by the real time clock.

I'd prefer a lower power solution. Hmmm?

XBee networks achieve much lower average current consumption by precise time synchronization, but that was not possible here.

lrtnorfolk

Thanks for the reply! First, I would like to say that I sould have been more precise in my first e-mail. Sorry about that. Tracy... I was thinking about doing exactly what you said above. I think the procedure that you discribe is the direction that I will have to take. The remote xbee will be directly connected to the project and sleep. Like you said, I can wake it up periodically to "sniff" (but not transmit). I can use the xbee connected to the laptop to "ping" when I'm in the area. I will be using the xbee pro 60mA, 802.15.4 on both ends. As indicated, the other xbee will be connected to another prop (or directly to a laptop)... depending on if I can extract the data from the pc and convert into a CSV (excel) file. If not, I will simply receive the data and copy it to eeprom. Then convert it to a CSV file from there.

I have not received the xbee's yet, as they are on backorder. I have been reading the documentation however. I would like to ask a question in reference to the xbee "Product Manual: XBee / XBee-PRO 802.15.4 RF Modules" (from the Digi website http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/point-multipoint-rfmodules/xbee-series1-module#docs). On page 25, under SM = 5... it states "Use this mode to wake a sleeping remote module through either the RF interface or by the de-assertion of Sleep_RQ for event-driven communications. " It indicates that it can be woken up through the RF interface. What does this mean?

The last thing I would like to ask is, if you have used the RN-XV modules (by Roving Networks). The data sheet indicates that the modules can be used in adhoc mode. I'm thinking that I might be able to use just one module (connected to the project). Then, adhov the module once a month via laptop to download the data. Has anyone used the RN-XV modules in this type of scenario? Thanks for all your help. Really appriciate it.
Renee

groggory

Alright, so I'm assuming you can't physically get to the remote module.

Also, you do not have the ability to leave a 'server x-bee' on all the time in the range of the remote module.

To maximize power saving while still making it reasonable to get the data off your xbee's I would like to propose this...

Use the cyclic sleep feature of the xbee to sleep in 30 minute increments. When it wakes up it will listen for 20 ms. If it does not receive a packet it will go back to sleep. FYI...receiving takes less energy than transmitting. If it does receive a packet then it will wait for a random number of seconds between 0-5s and then transmit to the origin of the broadcast packet it just received. FYI...all packets have the originating source in the header. After the transmission is verified the xbee is turned off and your laptop is told that data has been successfully sent. The microprocessor now does cleanup like deleting old data.

When you are in the area with your laptop run an information gathering program that sends out broadcasts over and over for say... 35 minutes. The broadcasts should be sent out ever 10 ms or faster. On that same laptop, you will be listening for replies (the sensor's data) and recording this data. You will also be sending acks to those sensors to acknowlege that the data has been saved successfully.

...I see a few flaws in this logic but in general it should work for you. It'll just need to be modified to your exact situation.

Tracy Allen

Sleep Mode 5 is a cyclic sleep mode that depends on time synchronization. The wording is a little misleading, "wake a sleeping remote module through either the RF interface or by the de-assertion of Sleep_RQ". The wakup they are talking about occurs at the interval that has been previously established between the coordinator and the end point. At the predetermined interval a ping exchange goes back and forth, and the end point stays awake only if there is data that needs to be exchanged. SM5 differs from SM4 in that in SM5 the XBee can also wake and sleep in response to Sleep_RQ. The coordinator is always awake and ready to receive messages. The details of how it works are laid out in the XBee manual under the section on sleep and the section on operation with a cyclic sleep coordinator.

I thought it might be possible to have the end point wake up and super-quickly associate with any nearby coordinator. However, the association process as defined by IEEE 802.15.4 is time consuming as the end points scans through channels and then determines which it can join and which ones have highest RSSI. It is not meant for the kind of quick access we are talking about.

You can easily imagine a radio transceiver that would allow rapid association. Something like the Nordic Semiconductor nRF24L01+ is not burdened with as much network protocol, although it does take care of packet error checking, retransmission, etc.

I haven't used the Roving Networks products, but for wifi generally, that initial association is slow. Low power wifi works by pinging often enough to keep an established connection alive.

Duane Degn

Tracy Allen wrote: »

You can easily imagine a radio transceiver that would allow rapid association. Something like the Nordic Semiconductor nRF24L01+ is not burdened with as much network protocol, although it does take care of packet error checking, retransmission, etc.

That's my que to say I have an object to use the Nordic nRF24L01+ chips with the Propeller. They don't have a sleep mode that I'm aware of but they draw such a low amount of current, I've powered the chip with a Prop IO pin. This makes it easy to turn off power to the device.

I'm not sure how safe powering the transmitter from an IO pin is but It has worked the times I've tried it. I've measured the current draw on a couple of different modules. The current has been between 14mA and 17mA in receive mode. (I don't remember if I measured the transmit current. I'm pretty sure I have and it was within the Prop's limit.)

One thing that's really nice about the nRF24L01+ modules is the price. You can get units off eBay for less than $3 (there's a link in post #1 of my index to the eBay units). There's a link to the driver in post #2 of my index.

The Nordic units are also fast. The can transmit 2Mbps.

If you're interested in the Nordic transceivers, you might want to look at my Panic Button project too (also found in post #2 of my index).

lrtnorfolk

Duane, Tracy,
Thanks for all your support. I might have to give those nRF24L01+ modules a try. The price is certainly right. Since my project does not require a lot of network protocol, these units make a lot of sense. What kind of range do they have? Is range similar to the standard 1mw xbee (802.15.4)? I also like the idea of driving the modules with a prop pin. Also like the rapid association. In the mean time, I am waiting patiently for my xbee pros to arrive. Thanks again for all your advice. Take care.
Renee

Duane Degn

Renee,

I haven't done much range testing with the Nordic modules. I've mostly used them in my lab for data logging or with robots. I do know they will tranmit to a device a couple of rooms away.

I'll try to run some range tests within the next few days.

Here are a couple of pictures on the units powered by an I/O pin.

This first one if from SparkFun.


And below is one of the inexpensive ones from eBay.




These eBay uints make it really easy to add wireless capability to a Propeller project. As you can see, they plug right into the QuickStart's header. If I use pins 8 through 15 for the Nordic transceiver, I can still use the QuickStart's touchpads and LEDs for input and output.

Tracy Allen

The power is the same, 0dBm, and also the frequency, 2.4 GHz ISM, so the range should be about the same as the 0dBm (1mW) XBee. Depends on the antenna and other usual factors, signal path and interference. Receiver sensitivity, selectivity? I don't have experience myself with the Nordic products, but there are several threads here on the forums.

Many issues of timing and "what if" come up when thinking about how to implement an over-the-air protocol, and that is what makes the predesigned ones like 802.15.4 so attractive. They are vetted. But the protocol makes certain assumptions, such as the one that the network will be composed of static elements that will stay in place or at least within range once the network has formed. The DigiMesh protocol makes the same assumptions. Another protocol is ANT, which is also implemented around Nordic radios, and is popular in sports equipment and medicine, like for heart rate monitors. I don't know of a named protocol that is meant specifically for offloading data in the way we are talking about here, but it can't be that unusual a requirement. I don't mean to imply at all that it can't be done with XBees. That is what I am using currently. It is just hard at a certain point to push the envelope in terms of low power consumption vs speed of response.

Duane, I'm interested in your followup. That's remarkable about the $3.50 price for the module on ebay. The price for the nRF24 chip itself from Mouser is $3.60 each, down to $1.78/500. Then you have to add the xtal and a bunch of other stuff and design the pcb and antenna (a big one) and get agency approvals (?!). Sparkfun has several modules in the $20 price range.

JOHNNY_2323

hola ... Tengo mira sin h