LQI on coordinator

[abe]

Hello, I developed for my customer, a ZigBee coordinator in last 2019, using nRF5 SDK for Thread and Zigbee v3.2.0.
Now my customer ask me if it possible to have the LQI value for each end node
There are any ways to get this value from Coordinator?
I see the function zdo mgmt_lqi ... is this helpful?
Thaks
Abele Barbieri

[Marte Myrvold]

Hi Abele,

You can use zdo mgmt_lqi for this, but if you want to know the LQI between the coordinator and its neighbor then you do not need to send a Mgmt_Lqi_req command. This command is for obtaining the neighbor table of a remote devices. One of the fields of the neighbor table is LQI, so if you want to know the LQI between a remote device and all of its neighbors, then this command is useful. On the coordinator you can check the entries of its neighbor table locally.

I have made a function that will iterate through the neighbor table and print to log the short address and LQI of each neighbor:

static zb_void_t get_lqi()
{
    uint32_t i;
    zb_uint16_t addr;

    /* If gc_neighbor[i].used is 0, the entry is not used */
    /* If gc_neighbor[i].ext_neighbor is 1, this is ext neighbor record, else base neighbor */
    for (i = 0; i < gc_neighbor_table_size; i++) {
        if ((gc_neighbor[i].used == 0) ||
            (gc_neighbor[i].ext_neighbor != 0))
        {
            continue;
        }
        zb_address_short_by_ref(&addr, gc_neighbor[i].u.base.addr_ref);
        NRF_LOG_INFO("short_addr: 0x%04x, #LQI: %d", addr, gc_neighbor[i].lqi);
    }
    
}

Be aware that this will only show the LQI of the devices that are neighbors to the coordinator. If they are not neighbors, either because they are out of range or because the remote device is an end device with a parent that is not the coordinator, then you cannot use the above. In that case you do not have a direct link between the coordinator and the remote device, so you would not have a LQI between the coordinator and remote device anyway.

Best regards,

Marte

[abe]

Ok, it is clear.
Then, there are NO way for coordinator to know the LQI of end nodes that aren't neighbors?

[abe]

Sorry, I forgot to inform about my coding ...
The steering and network formation of all end node is trough the Coordinator
The custom application of my "Coordinator" needs to receive also information (battery, on/off status, ... ) to take some actions related
Then, for all end nodes that are allowed to entry on the network, my "Coordinator" custom application make some binding and subscription for needed clusters
If I chek the communication "over the air" I see that some end nodes send directly to coordinator, but they are not on the Coordinator neighbor table

[Marte Myrvold]

When you say that you check the communication over the air, do you mean by capturing a sniffer log? If so, can you upload the sniffer log here?

[abe]

Yes, over the air communication was sampled using ZigBee sniffer.
Unfortunately I have not available logs.
In any case, I try to add more info to this case, as I have have observed
- On my "desk" setup I have my Coordinator, one bulb, one smart pulg, and one SED Door Sensor. The door Sensor is closer to Coordinator; the Bulb is farther
- smart plugs and bulbs (that are also ZR) some times (I have not understood how and why) immediatly after the Coordinator allow access and give Network address to end node, takes some "network" actions
- as a result for the actions above, the end node is no more on Coordinator neighbors table
- the end node is now on neigbours table of ZR
- when send the autoreporting, it is addressed directly to coordinator
- The kit I'm using (as requeste by my customer) is composed by Heiman ZigBee products

[Marte Myrvold]

Hi,

abe said:

takes some "network" actions
- as a result for the actions above, the end node is no more on Coordinator neighbors table

Are these "network actions" responses to packets from the SED, such as end device timeout and node descriptor request? I would guess so since the result is that the SED is in the neighbor table of the ZR and not the ZC, meaning that the ZR is the parent, but without knowing what the packets actually are I cannot tell you more about what is happening besides what the expected behavior is. When an end device joins a network it will look for a suitable parent device. The end device might find more than one suitable parent, and in that case it will select one of them. 

abe said:

when send the autoreporting, it is addressed directly to coordinator

Is it sent directly to the coordinator without going via the router, or is it just that the destination address is the coordinator?

Best regards,

Marte

[abe]

Hi Marte
I found WireShark log that show one of case I noted.
to explain the contents:

Door Sensor short = 0x7d09, 0x92dc
Bulbs short = 0x91d4

- line 14703 Door Sensor (0x7d09) send IAS status to coordinator
- line 14705 coordinatore reset (only for test)
- line 14717 iniziate rejoin
- line 14723 update sensor address to 0x92dc
- line 14749 Door Sensor (0x92dc) send IAS status to coordinator

rejoin_bulb_nw_add_change.pcapng

[Marte Myrvold]

Hi Abele,

Since the door sensor lost connection to its parent when the coordinator was reset it will try to rejoin the network to get a new (or the same) parent. You can see that the bulb is the new parent since the door sensor sends an end device timeout request to it (packet 14735). Later, the door sensor sends a network address request to find the short address of the coordinator (packet 14746), and from this it will find that the coordinator is in the neighbor table of the bulb, so it knows the route to the coordinator (door sensor -> bulb -> coordinator), and can now send packets to it via its parent. It might seem like the packet is sent directly, but if you inspect the packet and compare it to similar packets sent when the coordinator was the parent you will see that there is a difference.

Coordinator as parent:

Bulb as parent:

As you can see, the destination in the network layer frame is still the coordinator in both cases, because the final destination of the packet is still the coordinator. However, in the case where the bulb is the parent device the destination in the 802.15.4 MAC data frame is the bulb, and not the coordinator. So the packet is routed via the bulb when it is sent from the door sensor and to the coordinator in this case.

Best regards,

Marte