Home/Support/Support Forum/Routers on matching network ID + PAN ID not talking OTA

Routers on matching network ID + PAN ID not talking OTA

0 votes
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 "'\n", node_id->node_info);
node_add(node_id);
}

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?

Thanks
asked Jun 27 in XBee Programmable Development by D2K New to the Community (14 points)

Please log in or register to answer this question.

1 Answer

0 votes
What is their full part numbers?
answered Jun 28 by mvut Veteran of the Digi Community (15,323 points)
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.
...