How to send an identifier byte each cyclic sleep cycle?

Question

I have several end devices that will be set to go into cyclic sleep when their respective arduinos are set into a deep sleep mode. While awake and sending, frame data include a unique identifier byte so that I know which unit the data came from.

During cyclic sleep, I had planned to set each Xbee to send a random DIO pin value just so that I can see remotely that they are powered on and in cyclic sleep mode. However, I during sleep I still want to know which unit this "sleep blip" came from. This worked with one transmitting unit, but when I have more, I need to see some kind of identifier.

I can't use the node identifier, because during networking, frames may come from any given end device and the node identifier data does not tell me where the frame originated- only who it last came from. In practice, I may have some units asleep while others are awake and sending. There would be a high likelihood of a "sleep blip" being picked up and resent by another more active sender, masking its origin.

So my question is whether there is some way I can configure the Xbee to send a specific byte each time it wakes from cyclic sleep. My arduinos will be totally powered down while cyclic sleep is running, so I won't be able to feed anything to the Xbees. If only there were some tiny chunk of memory on the Xbee, or some parameter that I can set prior to sleep and configure the Xbee to transmit it every sleep cycle.

Or perhaps there's some way to configure the 802.15.4 network to NOT share frames between end devices. That way I could actually use the node identifier as an identifier and be sure of where the frame originated.

Anyone have any advice?

Answer 1

why not simply enable an ADC line and set a sample rate. The receiving module would need to be in API mode and you would then know what node it was that sent the data. You would also know which node is sending UART data as well as that 64 bit address would be provided.

On a Zigbee Mesh network, you can't simply turn off the 802.15.4 functionality as that is how the data is routed.

Comments

Thanks a ton, Mvut. That's just what I did when I had one sender. But my new confusion is based around some trials I ran while networking three Xbee Pro S1 radios.

When sending a sample frame from one Xbee and listening with a second Xbee, I would often get the third Xbee's node identifier, signifying that it was the source of the frame.

So how should I find out what radio originally sent the frame? Should I use a different parameter besides the node identifier, such as one of the serial numbers?

---

The S1 hardware is an 802.15.4 Peer to peer, point to point, point to multi-point product.

The Sleeping end device are designed to send data to the 802.15.4 Coordinator.  So the DL and DH of the end devices should be set to the SL and SH of the Coordinator.

don't use a Node identifier.  Use the radios MAC address or Serial number as the indicator who the packet was from. Use API mode on the Coordinator and that data will be provided to you.

---

Because I was getting incorrect node identifiers, this whole time I thought nodes were bouncing or relaying frames.I didn't have any loopback repeating going on, but I did finally figure out why I was getting node identifiers that didn't match the original sender. It had something to do with the fact that all of my 16 bit source addresses were set to 0. Once I individualized them and started using 16 bit Tx requests with FF FF (broadcast) destinations, I started getting correct node identifiers.

So I think I figured out what I need to do. I do need to keep my 32bit destination addresses set to 0, because I need my sensor devices to be replaceable and interchangeable. I plan to programmatically set my 16bit addresses to match my own unique identifiers in the field at the time of use, and then all frames after that will come with the 16bit address attached for free. I'll also use the 16bit address to unicast when needed. All other messages are broadcast.

---

One correction. There is no 32 bit address field.  There is either a 16 bit user defined address or a 64 bit that is set by the MAC address of the radio.