Arbitration process between radios for a S3B-900HP Programmable Digimesh coordinator

Question

What is the best way on the S3B-900HP Programmable to implement a network where the Coordinator can be changed?

Example scenario, really the only scenario:

1.) Two mobile devices ("A" and "B") arrive to a location where they will stay for a few days
2.) Device A turns on at some time (first)
3.) Device A attempts to discover a network Coordinator but finds none
4.) Device A, in API mode, executes xbee_cmd_simple for "CE" in code and changes to a Coord (??) and reboots
5.) Device B turns on
6.) Device B discovers network Coordinator: device A
7.) Device B begins arbitration process to claim Coord by checking with current Coord to see which has greater value MAC addr
8.) Device B has a greater MAC, so device A issues xbee_cmd_simple for "CE" and changes to router and reboots
9.) Device B issues xbee_cmd_simple for "CE" and changes to Coord and reboots
10.) After some time, the network is reconfigured upon another ND cast by the Coordinator.

Is this a practical solution, or would the CE commands not work?

Thanks

Answer 1

If this network is not a sleeping network, then why is there a Coordinator? In a Digi mesh network, a coordinator is only needed when you are using a synchronous sleeping network.

Comments

These are deployed to outdoor oil and gas environments that make signal quality impossible to anticipate, so there is a benefit in making every radio a router instead of an endpoint. For this, and even without synchronized-sleep, I have assumed the Coordinator radio is needed to maintain a routing table; much to my chagrin, i have not been able to surpass 35 nodes as the magic number of supported clients when sizing 'node_table' in _nodetable.c.  

In this network, there are 2 "critical" units that are a central parser for snapshot data from client radios, aggregating their information. I am also adding clients to this network for low-data rate handheld devices that will act as ESDs (a write to both critical units) and also provide read-only info displays for the aggregated data from the critical units.

How would a unicast destination be resolved without a Coordinator if AODV doesn't store information on Routers? RREQ broadcasts every time? Sorry, I may be confused and still a bit inexperienced.

---

No, every node that is sending data, be it a Router, coordinator or end device, if it is sending data from the UART or an enabled ADC/DIO line, it has its own routing table that is used for each data packet sent.

The Digi Mesh products are a true mesh network where there is no need for a coordinator to establish a mesh network. A coordinator is only used in Synchronized sleeping networks to help keep the network together.  When a node is first sent out or has data to be sent, a broadcast is sent out announcing it to the network. It also does a 1 hop node discovery to determine what nodes are in range.  This data is stored in its own routing table. So when the first time a data packet is being sent, a rout discovery is performed. This neighbor table is then used to help determine the rout before the data packet is ever sent.

---

Well that makes things interesting now. The thought of not needing to manage a new arbitration process in software is wonderful! I already have developed a schema of unique Node Identifiers based on my device type. I assume then that every node's node table keeps a record of every other node on the network, and at a minimum, what adjacent node to relay data to in order to get to the destination node?

Currently since I have been organizing my networks with one coordinator as the aggregator, I can typically hard-code the NI given the use case. In this scenario, are there any slightly more convenient methods in the SDK to more effectively find nodes? Maybe a wildcard search variant of node_by_name() so I can better filter results? Or will I just need to compare the results of node_table_dump() each time?

Thanks!

---

No it does not. The nodes have a small routing table. The node sending the data is what keeps the table on how the data is to be sent/routed.  The other routers only keep a neighbor table to know who is in range of it. This way, the data provided in the rout record is used to send the data.

---

But if every node will send data snapshots at some point, and every node is a router, then each node will have this route table?

What's the easiest way to find a node while knowing some of it's NI but not the exact value? (i.e. ADMIN422, ADMIN174, etc., where searching for "ADMIN*" is effectively what I want to do.

---

Unless the routers are sending data from the UART or ADC lines, they will not have a routing table. The data packet that is being sent has in it the routing table.