Developing 25+ device microcontroller/Zigbee network, how to avoid hard-coding polling addresses?

Question

I'm developing a 25+ node XBee/Zigbee "star" type network with one coordinator and end routers.

To put it simply, it will be similar to a security system where all the nodes are "waiting" on an event; if triggered.

To get up and going quickly yes I'm using the Arduino platform despite the disdain of many EE's.

The XCTU software is great for configuring the XBee radios in AT mode, but if I want to have my coordinator polling each node to see if an event has been triggered, how can I get the randomly-assigned remote IDs that the XBee assigns, or at least avoid manually hard coding arbitrary IDs to each end node?

Ideally I could pull this info off the XBee instead of developing a whole new formulate and assgin IDs routine upon network reset. Seems like I'd be reinventing a lot of the utility built into the XBee system already.

I haven't found any good info yet digging through the XBee documentation.

Any thoughts are welcome! Thanks.

Answer 1

I would work it the opposite direction, have each node when powered on report on a known address, the controller sees this, assigns it a unique ID, if there is a collision have the nodes wait a random time period before trying again, at minimum longer than the assignment of another node.

Answer 2

Any thoughts are welcome!

It seems to me that if it's similar to a security system where all the nodes are "waiting" on an event, then the nodes need only send and not bother to listen. So, my recommendation is to assign each node a unique address and let them potentially "clash" and re-transmit important messages once more at an interval defined by the unique address. Why complicate stuff with receivers in each node (unless of course it isn't like "a security system where all the nodes are "waiting" on an event").

I want to be able to view all nodes and their current status as online or unavailable in real-time to view if one falls out of range/battery dies etc. I was thinking of having the coordinator polling their status and wait for a response (where no response means the node is unavailable).

But that places a lot of system resources (and cost of ownership) into collecting battery data when, in fact, that can be automatically generated by the "transmit-only" transmitter sending status information every once in a while. Collision occurrence is going to be naturally very low so please consider this.

You can tell if one node is "broken" by the absence of a status transmission in the requisite time plus an hour or 30 minutes or a day or whatever. Ask yourself, do you really need to have power hungry receivers in each node? If using transmit-only protocol, the batteries will last a hundred times longer too.

Great points. I am not familiar, though, what collision detection techniques one could employ in this instance if the nodes are configured as transmitters "blind" to all other devices but the coordinator. Are you implying all nodes transmit every message twice, with the second at a staggered offset? If the coordinator receives garbage, how would a node know it's transmission failed?

You have to be practical and accept that there will be times when collisions occur. Many radio systems are designed like this. Do the stats - if a transmitter transmits its non-urgent status once every two hours (for instance) and its transmit message lasts 100 ms (including preamble and checksum), that's a time occupancy of 0.0014%. If you have 50 such transmitters, the overall system occupancy is only 0.07%. Then do the math on collisions (remembering that your checksum will throw away dodgy looking messages).

A node doesn't care if its message fails except when it's being activated (by a burglar) AND it should, in those circumstances, transmit multiple times to ensure this important message "gets through". After all, a burglar isn't going to be tripping multiple sensors at precisely the same time. Be practical is my advice.