Routers on matching network ID + PAN ID not talking OTA

I am configuring several S3B-900HP programmable radios, all as routers, in a field environment as follows:

  • 3 routers serving as remote monitors + an ESD pushbutton, where the user – holding a remote – can stop everything on the process floor. These NI’s are 92001…92003.

  • 2 routers serving as the core process controllers/data generators, each from separate but identical machines, who are to update the 3 radios mentioned above with a couple serially encoded data samples. These NI’s are 30001…30003.

I am interested in assigning them all as routers because they could potentially assist one another in achieving signal coverage in a uniquely challenging environment (spatial and obstacles/propagation), so there is value in the digimesh network. I configure every radio in API mode because I always end up putting some degree of custom functionality on each controller.

On the latter 2 XBees, I am periodically, every 25s, executing some pretty simple code in an attempt to find other radios:

(void)xbee_cmd_simple(&xdev, “ND”, 1);

…to which node discovery callbacks are enabled and handled:

if ((node_by_addr(&node_id->ieee_addr_be)) == NULL) {
sprintf(txbuf, “New radio:'%” PRIsFAR "’
", node_id->node_info);

And this doesn’t seem to be working.

First, anything from xbee_transparent_dump() is absent, so no OTA data is received.
Second, the standard code from so many of the SDK examples, as follows, provides nothing:

wpan_envelope_create(&envelope, &xdev.wpan_dev, &node_ieeeaddr, WPAN_NET_ADDR_UNDEFINED);
envelope.length = strlen(rxbuf);
envelope.payload = rxbuf;
envelope.options = 0x00;
envelope.dest_endpoint = DEFAULT_DEST_EP;
envelope.source_endpoint = DEFAULT_SOURCE_EP;
envelope.profile_id = DEFAULT_PROFILE_ID;
envelope.cluster_id = DEFAULT_CLUSTER_ID;
result = wpan_envelope_send(&envelope);

I’ve had 2 unique results from doing this:

1.) node_by_name(NI) returns NULL, so -1 is returned.
2.) The enabled xbee_transmit_status_handler() in the past, prior to me issuing “ND” commands, returned “0x25” or, “Route Not Found”

What am I doing incorrectly that is not allowing these 2 radios, same network ID, same PAN, to not communicate?


What is their full part numbers?


Is the Channel Mask the same for both units?

HP 0
ID 5452
MF 19
MT 3
PL 4

Are you able to get the range test to work telling XCTU that you have a programmable module?

Yes, in both the range test and when I search for remote devices from one radio in the list. Range test results:

Do both modules have the same firmware and part number on the label? Do both have the same CM values?

Yes they do.

VR 8075 both
HV 234B and 234A
HS 301 both
DD B0000 both
NP 100 both
CK 81ED and FC89

Both part numbers XBP9B-DMSTB002

I am presuming that you have your application loaded on both modules. That may be why the range test does not work. The range test would need to have the transparent app loaded on it for that to work.

I also presume that both radios have antennas connected and pointed in the same direction (up).

Both are also powered and are not in a sleeping state.

Are you able to see either one (ND) from a 3rd module that is NOT a programmable version?

The range test mentioned above was successful. It said 25 sent, 25 received. Maybe XCTU put it into a default bootloader state?

I was able to locate one of the big issues thus far. A loose power connection to Vcc providing very intermittent switching (or poor conductance) was causing some problems. I do not get the “Route Not Defined” 0x25 errors anymore, and get 0x00 now when sending. I do commonly see 0x25 whenever Vcc becomes low and Tx power is thereby throttled.

The issue I can’t resolve now is as follows:

1.) Core process routers (the 2 units) send my custom snapshots OTA to any designated monitoring routers (the 3 units) which as indicated above shows successful.

2.) these messages appropriately trigger xbee_transparent_dump() on the receiving radios however the “node_id = node_by_addr(ieee)” portion is returning NULL values — even though the handler is triggering — presumably indicating some sort of payload.

3.) I can see this is likely because the record is not added to the node table at the time of receiving the message, so for now I just instruct it to “node_add(node_id)” anything received since it’s a controlled test.

4.) Receiving this identical message again throws me into my “node_add” case because my check in #3 is whether or not “node_id” is NULL. It comes up as NULL again because it doesn’t find a record in the table.

Here’s some actual data:

Results of xbee_disc_node_id_dump seem not correct:
“Addr: 6f40ddc0-fd1ebf0f 0xbfbf PARENT: 0x0000 Coord NI:[]” (not configured as Coord, no NI)

Results of “addr64_format(buffer, ieee)” are correct:
“00-13-a2-00-41-9f-20-34” (the sender MAC which is accurate)

Results of “sprintf(txbuf,"NodeID:%s
", node_id->node_info);” seem not correct:
“” (blank)

I am not sure I understand what it is you are asking for. The Node ID field is a Digi function and not an IEEE function.

What I mean is that when I receive an OTA message, the IEEE addr64 parameter is passed in correctly when it is handled by xbee_transparent_dump() but when running node_by_addr(ieee), it still returns a NULL *node_id object even after attempting to add it to the table.

The only methods in _nodetable.c to add a node to a table are by node objects. I can’t get it in with just ieee address information, which should be enough. node_add() i see uses ieee_addr_be to decide whether or not to add it, so maybe I will try constructing it manually.

Okay, maybe I can approach this question differently:

I receive data and the process frame handler is triggered:

1.) xbee_transparent_rx picks it up, sends it to xbee_transparent_dump.

2.) In xbee_transparent_dump, “node_id = node_by_addr(ieee)” results in node_id==NULL.

3.) Because of this, I want to add it to node_table, so I execute node_add(node_id). Even though node_id==NULL in the previous step, it still has an address in node_id->ieee_addr_be. This address is 6f-40-df-c0-fd-1e-1f-0f. The node is successfully added to the node table, even though node_id->node_info (my ‘NI’) is still blank.

4.) xbee_transparent_rx picks up another message from the same radio again, sends it to xbee_transparent_dump again.

5.) In xbee_transparent_dump, “node_id = node_by_addr(ieee)” results in node_id==NULL.

6.) This should not read NULL because I’ve already added this radio from step #3. For some reason, it has a slightly different value in ‘ieee_addr_be’. This address is 6f-40-df-c0-fd-1e-0f-0f. I add this node to the table again, using node_add(node_id). The node is successfully added.

7.) xbee_transparent_rx picks up another message from the same radio again, sends it to xbee_transparent_dump again.

8.) In xbee_transparent_dump, “node_id = node_by_addr(ieee)” results in node_id==NULL.

9.) Now, this should DEFINITELY not read NULL because I’ve already added this radio from step #6. And this time, the value in ‘ieee_addr_be’ is the same as step #3, this address is 6f-40-df-c0-fd-1e-1f-0f. I add this node to the table again, using node_add(node_id). The node is successfully added.

7.) This continues indefinitely until node_table is filled to NODE_TABLE_SIZE elements, and it just fills them with alternating duplicate values. The same two addresses each time:

0: 6f-40-df-c0-fd-1e-1f-0f
1: 6f-40-df-c0-fd-1e-0f-0f
2: 6f-40-df-c0-fd-1e-1f-0f
3: 6f-40-df-c0-fd-1e-0f-0f
4: 6f-40-df-c0-fd-1e-1f-0f
5: 6f-40-df-c0-fd-1e-0f-0f

and so forth…

Is what I’m describing characteristic of anything that you have seen before? As far as I can tell, it is not possible for a router radio to parse the NI field from another router. When I use coordinator/router configuration, everything works fine.

The NODE ID field is a field that is specific to the Digi XBee product with the NI value set. It is not going to provide anything in that field for a 3rd party device as the NI field is a Digi specific field.

All radios in use are Digi XBP9B-DMSTB002 with NI uniquely configured in the config.xml.

You may want to do a Node Discovery to verify that the NI is set.