Home/Support/Support Forum/Arbitration process between radios for a S3B-900HP Programmable Digimesh coordinator

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

0 votes
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
asked May 25 in DigiMesh Proprietary Mesh Networking by D2K New to the Community (16 points)

Please log in or register to answer this question.

1 Answer

0 votes
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.
answered May 25 by mvut Veteran of the Digi Community (15,410 points)
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.
...