[Zigbee-mesh] How to initiate the route discovery manually?

[Tu Hoang]

Hi everyone,

I am making a zigbee mesh with just coordinator and routers only. I intended to have the mesh to cover a very large areas with nodes that can be moved (not frequently). I am using SDK4.1.0, for coordiantor , i uploaded the CLI example inside and for the router  i used the exact same example of lilght bulb with the only change is that i exclude every parts relating to notification led or button.

Tell my if i am wrong but from what i learn, when the nodes send a message to another node, without having the address in the routing table it will initalise the route discovery by (1) sending route request or (2) after some time out when it did not received a MAC ACK from the node it try to send to. My expectation is that i will work like a charm since it is almost the same as the example but it did not. It has a really annoying that even with the router is very far from the coordinator, even with very low LQI and miss a lot of MAC ACKs, it still persistently try to send to the coordinator and not every try to broadcast route requeset. And for the first condition to start a route discovery, when the router send route requests, the coordinator can definitely hear it (i have a sniffer just right by coorfinator side).

So my question is that i want to start the route discovery manually to have better control over the mesh. is there any way i can do that. If not, is there any solution for the route discovery. 

Thank you in advances,

Best regards,

Tu

[Tu Hoang]

Hi Marte,

Sorry I just click the wrong button.

So to answer your question let me sum up the way route discovery happen in my case. After about 10-12 no ACK packets, the route request started to send. Then a nearby node reply and a new route is formed. But for about 20 secs usually after the link status message, the connection is broken. I have a wild guess that may be when the coordinator send the link status, some how the router receive it So it realise that the coordinator is in the neighbor and try to send packets.

I did retry the experiment but this time with the addition of Many To one Route Request sent at every minute. The problem here is that everytime the Many To One Route Request is sent, it is like the router delete the entry in routing table of 0x0000. So I guess there is something going on with the routing table that cause this behavior.

Thank you in advance,

PS: Can you still be noticed about the update of this ticket. I am very sorry of any inconvinient. Please tell me if i need to create a new thread to continue.

Tu

[Marte Myrvold]

Hi Tu,

I am still notified about updates on this, so you do not have to worry about that. If the questions are no longer relevant to the original topic in the ticket, we prefer that customers create new tickets, but this is still very relevant, so there is no need to create a new ticket. No inconvenience at all, I am just happy to help.

From what I can see in the sniffer it does not look like either the router or the coordinator believes the other to be a neighbor. I looked through some of the Link Status messages, both from the router and the coordinator, and none of them had the other in the link status list field. This field contains the list of all router neighbors, including the coordinator. The only neighbor the router had in the link list was 0x1b67, so it should not think the coordinator is a neighbor. The link list seems to be correct for 0x1b67 and the coordinator as well.

I am sorry, but I have not been able to see why the connection is broken. I have forwarded your sniffer capture to our developers to see if they can find anything.

Best regards,

Marte

[Tu Hoang]

Hi Marte,

Thank you very much for your kindness. I want to update something to you. So I found this answer that help me to see the neighbor table of a device

https://devzone.nordicsemi.com/f/nordic-q-a/70780/nrf52840-zigbee-router-s-neighbour-table-management-lqi-is-not-updating-even-if-the-end-device-is-disconnected.

So I did a similar jobs based on the code snippet for getting the routing table but i notice something very weird about the struct zb_nwk_routing_t, which should have all the field contained in the routing table. It does but there is mismatch with next_hop_addr_ref where in the zigbee spec (here) it is 2 octes but in the zboss_api_internal.h it is only maximum 8 bits. So is it because I have an old version of zigbee spec that the structure of routing table change? Or is it because of they are different parameter? Does this have something to do with some routing table malfunction? Also, a similar problem with status bit, in the document they use 3 bits but in the struct only 2 bits is used.

In addition, i have another question, so if I modified gc_neighbor_table, will it change directly the routing table that the stack used, and what gc stands for. And I also notice that when I print out the neighbor table of a node connected directly to the coordinator, all entry by default will have the destination address is 0x0000 along every others parameters in zb_nwk_routing_t is 0, Is it means that they are not currently using any route from the routing table? If the answer is yes then, when an new route is create, the device can know to use the new route by looking at status bit or used bit to choose the path the transmit data. 

Thank you and please inform me if there is something new.

Best regards,

Tu

[Tu Hoang]

Hi Marte,

I have something to update and ask for your advice.

So I did some other test and try to get the neighbor table along with the routing table from the node. Then i came up with some really weird outcome. So for the case i sent you the sniffer,when i logged the neighbor table for inside the node, it looks like the router can still listen to the coordinator, but it never get to the link status. The entry corresponding to the coordinator have lqi varied close the zero and the aging changing from 0 and 1 repeatedly. When the node receive route reply, the newly created entry inside the

After doing some investigation, I have a theory like this. Let's say the broadcast range of one node (coordinator) is larger than the other node (router) (because i do not have a large enough area to move the devkit out of range so i reduce the transmitting power by nrf_802154_tx_power_set()), when putting them apart, while the router can not send any messages to coordinator, once in a while, it still can receive a link status from the coordinator. And the link status messages are coincidentally receive so that it the router see the coordinator as its neighbor for just a short period of time. That is why it some time does not start a route request and sometime even it establish a new route the the destination, it never use that route for long because the node never gets out the the transmitting range of the coordinator. It never stops considering the coordinator as a neighbor.

So my question is, if there is already an entry in neighbor table, is it true that the node will do anything but send the message directly to the address of that entry. And is it true if even there is an entry in routing table with the same address, the node will prioritize the entry in neighbor table and delete the entry from routing table?If all of the suspicions are correct, can you tell me some way to get rid of this problem.

Thank you in advance,

Best regards,

Tu

[Marte Myrvold]

Hi Tu,

Sorry for the delay. I have an update from the Zigbee team regarding the sniffer log you attached. I have copied their response below:

In pcap file, the first procedure when the router 0xf392 started to look for a new route to the coordinator begins around 248th packet and seems to end successfully. I think the router was reset in that point. Then it sends ZCL commands to trigger looking for a new route one more time. A new route is also found this time but at 1008th packet the router 0xf392 seems to forget that it should send packets thru 0x1b67 instead of directly. It looks like a stack issue.
How is reporting triggered? By ZBOSS or manually by the customer?

I got this before I updated them about what you wrote in your last reply, so not all of it might be relevant if the problem is that the router still sees the coordinator. I have updated our Zigbee team with the updated information from you, and I have asked for clarification regarding your questions.

Best regards,

Marte