[Zigbee] How a router can know the parrent is available before send a message

[Tu Hoang]

Hi everyone,

I am trying to send a custom zigbee message by using this function  zb_zcl_finish_and_send_packet_new() with a callback function to free the buffer after send. i managed to make it work but there is a problem that i haven t know how to solve.

I have a nrf52833 to work as a coordinator and some routers using button to send message (also using NRF52833) to  form a zigbee mesh. By using the custom message mentioned above, the devices can communicate with each other, but when the coordinator is downed, because of the retry mechanism, sending 1 message turn in to resending the same message multiple times. With just some consecutive press at this state, the router frezze and get into hardfault.

I try to find out what is the root of the problem and it seem like because the buffer pool is full since it is not free in time thank to the retry mechanism keep the device to go into callback to free the used buffer. So i am thinking, is there any way that i can identify if the coordinator is down or not so that i can check everytime i send one. I notice that we have a signal in zigbee_helpers.c of parents unreachable but i want some thing more realtime so that i can check every time the coordinator is down.

So my question is that is there any way to check for this like reading link status or send data request message or something that i can do. And if there is one, can you show me the API of that one also.

Thank you, please reply soon,

Best regards,

TU

[Marjeris Romero]

Hi,

Do you have any sniffer trace to see what is happening when the coordinator is down?

To check if the coordinator is up you could send a match descriptor request to dst_addr 0x0000 for example.

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_tz_v4.1.0%2Fzigbee_example_cli_reference.html&anchor=match_desc

[Tu Hoang]

so i have the sniffer trace by nordic too but basically, it look something like this

So when i press the button twice, i can see that reports with the same sequence number (105 and 106) were send repeatedly and if i keep pressing the button consecutively it will crash the MCU. When i make the coordinator online again, everything works fine like this 

and i notice that there is a message called link status like this

It keeps sending every 5s so the problem i wanted to ask is that any way i can ultilize that to detect the coodinator.

I knew the descriptor request but it is quite overkill for this case since i will call it everytime  i try to send something  and a lot of infomation in it is not really needed so, is there any other way?

Best,

Tu

[Marjeris Romero]

Hi Tu,

Sorry for not getting back to you earlier. Instead of sending a match desc req you can also read some basic attributes from the coordinator for example, perhaps that's an alternative? I am not sure how you would use the Link status to detect this though, did you have any ideas in mind?

Best regards,

Marjeris

[Tu Hoang]

So there is Link quality indicator field in the link status message. I was thinking that the coordinator can broadcast that message through out the network then its receivers can know if the signal is poor or not then I can control the over-sending retry message.

And by the way, i want to ask another question, is it possible to restrict the number of message resending when the destination is not reachable? if it is, can you guide me.

[Marjeris Romero]

Hi,

Are you talking about the Link status message or Link Quality request messages? The Link status messages are sent as a broadcast from the coordinator, there is no link quality indicator field in this message.

These link status messages are used to keep track of route symmetry. All the neighbouring routers keep track of these messages to determine which routers can hear them and which routers they can hear with incoming and outgoing cost.

I don't think you can get the status of the coordinator network from this message alone.

From the Zigbee documentation:

"If a router fails to receive nwkRouterAgeLimit link status messages from a router the neighbor entry is considered stale and may be reused if necessary to make room for a new neighbor."

But that the entry is considered stale doesn't mean that it gets remove from the neighbor table, so there is no way to know if the coordinator have left the network from reading the routers' current neighbor table.

What you can try to do is to send a Link Quality request (zdo mgmt_lqi) from the router to the coordinator and ask for the link quality (LQI value).

If the coordinator is OFF the ZDO Link Quality request will timeout, and then you can assume the coordinator is no longer on the network, but this is the same as principle as trying to send a request for reading attributes or sending a match desc req, if the coordinator doesn't respond the request will time out.

 

Tu Hoang said:

And by the way, i want to ask another question, is it possible to restrict the number of message resending when the destination is not reachable? if it is, can you guide me.

The number of retries when the destination is unreachable depends on the number of retries needed on each layer, and these are defined by the Zigbee specification.

The expected number of retransmissions from the code perspective:

• MAC: 4 in total (first frame failed + 3 retransmissions)
• NWK: 4 in total (first frame failed + 3 retransmissions)
• APS: 3 in total, actually there is a little bug in sdk v4.1.0 here, there should be 4 retransmissions in total (first frame failed + 3 retransmissions) but instead there are 3 transmissions in total, first frame failed + 2 retransmissions.

This gives around 47-48 expected retransmissions.

For MAC and NWK layers the minimum number of retransmissions is set to 3 by the specification.

For the APS layer the only constant specified in the Zigbee specification is the maximum number of retransmissions apscMaxFrameRetries and it doesn't look like there is a minimum value, but it's defined in ZBOSS stack by ZB_N_APS_MAX_FRAME_RETRIES 3. Since this is a ZBOSS compile-time configuration parameter you will need to recompile the whole stack to change this value, which it's only possible if you are a member of the ZOI (Zboss Open Initiative).

Long story short, no, there is no easy way to "restrict" or decrease the number of retransmissions after the first frame of a message is sent, as this is part of the Zigbee specification.

If you are worried about latency or bandwidth and you have an enviroment which potentially can get "overflooded" with retries, a good policy could be to keep the packet lenght as short as possible for the given transmission, but to be honest I haven't seen any customers having trouble before because of the packet retry mechanisms of Zigbee.

Best regards,

Marjeris

[Tu Hoang]

Sorry for the late reply, but thank you very much for being very patient with me. At first I though that link staatus with the outgoing and incoming cost can help me to check for the LQI since the path cost is calculated by LQI, but on second thought, i have a mesh network so a link status with radius 1 is not really going to cover every nodes in the network. So i decided to go with your advice but i just make a custom test message with zb_aps_send_user_payload with only one byte of payload before sending the real message. And it works well.

So thank you for the help, have a nice day.

Best regards,

Tu