NRF52840 Zigbee Meshing Capabilities

RE: NRF52840 Zigbee Meshing Capabilities

Marte Myrvold — Wed, 27 Oct 2021 12:20:43 GMT

Hi Fernando,

I cannot see any other reason for the Unimplemented signal by looking at the sniffer log. I see that the coordinator send a Routing Table Request, and that the node, in this case 0xf4ce363a823b69fd, responds with a malformed Routing Table Response with status 'Not Supported'. Thus, this is likely the issue and the reason you are getting unimplemented signal, as the Routing Table Response is not implemented.

[quote user="Fernando Fontes"] I believe that all of them are in the range of the coordinator.[/quote]

I see all of them in the Link Status command of the coordinator. This means that all of them are neighbors of the coordinator, and that they are in range of it. The outgoing cost of some of the coordinators links are high, but none are out of range.

[quote user="Fernando Fontes"] it seems that 0xf4ce36b839b9ac59 is being routed[/quote]

I could not see that packets to or from this node is being routed from the sniffer log. The cost of the outgoing link from the coordinator to 0xf4ce36b839b9ac59 is high, 6 on a scale from 1-7, but they are still neighbors. The router reports attributes which the coordinator responds to, and the packets are not being routed through another node. However, I do see that 0xf4ce363a823b69fd does not have 0xf4ce36b839b9ac59 as a neighbor, as it does not show up in the Link Status command of 0xf4ce363a823b69fd. The node does show up in the link status command of 0xf4ce36b839b9ac59 though.

Best regards,

Marte

RE: NRF52840 Zigbee Meshing Capabilities

Fernando Fontes — Tue, 26 Oct 2021 12:06:11 GMT

Hello Marte,

Sorry for forgetting about the network key. The network key is: 01:03:05:07:09:0B:0D:0F:00:02:04:06:08:0A:0C:0D.

Regarding the Unimplemented signal, yes, generally it appears after the routing table request. But it could be for some other reason that I'm not getting.

[quote userid="92402" url="~/f/nordic-q-a/80449/nrf52840-zigbee-meshing-capabilities/335892#335892"]Am I understanding your figure correctly that nodes 0xf4ce363a823b69fd and 0xf4ce3686907ea954 send directly to the coordinator, while packets from or to 0xf4ce36b839b9ac59 is routed through 0xf4ce363a823b69fd? If so, this would make sense if both 0xf4ce363a823b69fd and 0xf4ce3686907ea954 are still in range of the coordinator, while 0xf4ce36b839b9ac59 is out of it's range, but still in range of the router that is furthest away, 0xf4ce363a823b69fd.[/quote]

Well, I believe that all of them are in the range of the coordinator. But it seems that 0xf4ce36b839b9ac59 is being routed. From your answer, I don't know if that is expected...

RE: NRF52840 Zigbee Meshing Capabilities

Marte Myrvold — Tue, 26 Oct 2021 09:20:57 GMT

Hi Fernando,

The packets are encrypted in the sniffer log, so I am unable to see their content. Could you please share the network key so I can decrypt them or start the sniffer before starting the network so the sniffer has the network key?

[quote user="Fernando Fontes"]Could this warning be triggered because of this? You said that this message indicates no route available, but could this be related to the request and not to the fact of a non-existing route to the coordinator?[/quote]

That could be the reason for it. Getting "Unimplemented signal" does not necessarily mean that there is anything wrong. It might just mean that the command is not implemented on the device. As for Routing Table Request and Routing Table Response commands, these are optional according to the specification, so it is not required for devices to support these commands. I did a test myself by sending the Routing Table Request command to a device implemented with our stack. From the sniffer log I could see the device respond with an APS Ack, but it did not send a Routing Table Response back.

Do you get "Unimplemented signal" directly after the Routing Table Request? Or when issuing another command?

[quote user="Fernando Fontes"]I was expecting to see something like 0xf4ce36b839b9ac59 -> 0xf4ce3686907ea954 -> 0xf4ce363a823b69fd -> 0x00124b002393413e.[/quote]

Sending packets directly is better than sending it via routing. So if the devices are in range of each other and have the destination node in their neighbor table, they will prioritize this over using the routing table and sending a packet using routing.

Am I understanding your figure correctly that nodes 0xf4ce363a823b69fd and 0xf4ce3686907ea954 send directly to the coordinator, while packets from or to 0xf4ce36b839b9ac59 is routed through 0xf4ce363a823b69fd? If so, this would make sense if both 0xf4ce363a823b69fd and 0xf4ce3686907ea954 are still in range of the coordinator, while 0xf4ce36b839b9ac59 is out of it's range, but still in range of the router that is furthest away, 0xf4ce363a823b69fd.

Best regards,

Marte

RE: NRF52840 Zigbee Meshing Capabilities

Fernando Fontes — Mon, 25 Oct 2021 10:15:22 GMT

Hello Marte,

Thank you very much for the support and for the explanation.

During the past weeks, I was busy with other tasks and I haven't had the time to do further investigation.

I have created a simple network with 3 nodes (all of them paired to zigbee2mqtt coordinator), and I have placed them in strategic positions.

Node: 0xf4ce36b839b9ac59 is the longest node.

Node: 0xf4ce3686907ea954 is placed in-between node 0xf4ce36b839b9ac59 and 0xf4ce363a823b69fd.

Node: 0xf4ce363a823b69fd is placed less then 10 cm of the coordinator.

I was expecting to see something like 0xf4ce36b839b9ac59 -> 0xf4ce3686907ea954 -> 0xf4ce363a823b69fd -> 0x00124b002393413e. However, I also understand that depending on some environment variables, and difference between antennas that this can change and not behave as expected.

Based on the output from the zigbee2mqtt it seems that indeed the nordic nodes can't share their routing table, therefore they start to send the "Unimplemented signal (signal: 21, status: 0)" through the serial port. Could this warning be triggered because of this? You said that this message indicates no route available, but could this be related to the request and not to the fact of a non-existing route to the coordinator?

I was able to generate a simple graphviz routing table from the coordinator:

Can you tell me if that makes sense? Note that all of the nodes have failed to answer the routing table request (see pcap attached).

Best regards,

Fernando

devzone.nordicsemi.com/.../3_5F00_nodes_5F00_sniff.pcap

devzone.nordicsemi.com/.../0x30a3_5F00_serial_5F00_logs.log

RE: NRF52840 Zigbee Meshing Capabilities

Marte Myrvold — Fri, 08 Oct 2021 12:28:06 GMT

Hi Fernando,

The Zigbee network is already a mesh network, and is usually created by the coordinator. However, unlike end devices, routers have mesh capabilities and can to route packets, which can extend the network. In a mesh network, the routers are able to discover routes to other nodes in the network, and save this routes in a routing table. All of this is handled internally by the stack in our Zigbee stack, so the routing table is unfortunately not available to the application. If you have multiple devices in your network you can test the mesh networking by sending packets from one node to another node in the network that is out of range of the first node, and see that it goes through one or more routers on the way.

You are correct that signal 21 is ZB_NLME_STATUS_INDICATION. Status 0 indicates that there is no route available, so this means that the device is not able to find a route to the node it is trying to send a packet to. Having multiple routers on the network should not cause this. Could you please give some more information about your set up? What device is trying to send a packet when they get this, what are they trying to send, and to which device? Could you also get a sniffer log of this and upload it here as a pcap file?

Best regards,

Marte