Home/Support/Support Forum/S3B-900HP Programmable - topology diagrams
New and improved user forum site going live on 12/6 (All users will need to reset their password when the new forum is active)

S3B-900HP Programmable - topology diagrams

0 votes
With the assumption that a custom UI would also need to be developed for whatever system is displaying it, is there sufficient enough access with what's provided in the XBee CW SDK to allow a developer to create a similar reproduction of XCTU's network topology diagram within Network Working Mode? My network is entirely composed of S3B-900HP programmables in API mode.

I like seeing the signal quality dBm of the neighboring nodes and also how they are linked. This is sufficient information for what I want to develop into a UI. So if it is possible, what libraries/functions would be a good starting point?

asked Dec 18, 2020 in DigiMesh Proprietary Mesh Networking by D2K New to the Community (16 points)
edited Jan 13, 2021 by D2K

Please log in or register to answer this question.

1 Answer

0 votes
I don't know if there is enough memory but you can use the ND command to get the data with.
answered Dec 18, 2020 by mvut Veteran of the Digi Community (15,515 points)
Sorry, I am having trouble following.

Since the DigiMesh protocol is only going to get you the RSSI of the last hop, then assuming you know the way the route table is configured, you should be able to reproduce what the Network Working mode topology diagram shows, as it only shows dBm from consecutive neighboring nodes and not across multiple.

In my mind, it seems one way to do this is to iterate N times through the Coordinator's NODE_TABLE:

for (i=0; i<NODE_TABLE_SIZE i++)

-Send 0x10 Tx_Request to node_table[i].node_identifier and enable Unicast Trace Route message.

-You'll receive a ton of responses, but those responses aren't guaranteed to be in order of the "tree", so to speak.

Is there a function in the C API that cleans this process up? Am I thinking about this correctly, or is there an easier approach?  

Is this what you meant with ND? So instead:
- Ensure every node has NO=0x04.
- "Coordinator" tells every node in its table to issue their own ND.
- Each node issues ND
- Each node receives 0x95 back. This now includes neighbor's RSSI.
- Have each node then take Sender address (not Source) and RSSI and then send that to Coordinator to identify the neighboring(Sender) node for that individual node.
- Figure out the topology. Pooling all the responses, the more "trunk-like" nodes should appear the MOST when tallying the "Sender" messages because they are sending 1 message per descendent node.

That is one way.
If I were to go the original Unicast trace route approach, how would I reliably request RSSI via the DB command if it applies to the "last packet received"?

I see a couple issues:

1.) How do you know who transmitted to it last? (unless you transmit to it, then immediately follow up with "DB" which isn't necessarily practical.

2.) How on earth would you reliably obtain a "branch" node's RSSI if that node branched off 3 different ad hoc mesh routes? Then it would be ambiguous as to between which other host that received signal quality applied to.