Experimental analysis RIGADO R41Z Eval Board in industrial environment

[diegocomin]

Hello everybody,

I am inmerged in a project that involves the experimental analysis of Thread protocol thorugh the Rigado R41Z Eval Board in industrial environments where we have face inmmunity and interference issues.

I know how to handle the board at user level with CoAP, manage UART consol, program periphericals, etc. At this point I am able to send though CoAP protocol a message froma node to another. But in order to obtain the needed experimental results of the communication performed, I need to know some data from the board and network:

• The full frame of the message sent between nodes.
• The number of hops performed when I send a message from a node to another.
• Path routing of the message sent between nodes.
• What topology or routing path have the Thread architecture at the moment.
• The MLE advertisement containing the path costs between routers.
• The RSSI between nodes.

To sum up all the relevant information used to characterizate the communication in Thread.

The idea is to place some kind of instrument emitting interference near a node and see in real time the new routing path choosed in the Thread network to solve the interference problem, how many hops performs the node now, the new path costs, etc.

Can I obtain this information from the user application? Is the info located somewhere of the R41Z's Thread Stack? Do I need to use Wireshark to analyze the network? What I need to do to obtain the info?

Thanks in advance,

Diego Comin

[jc_pacheco · Accepted solution]

Hi Diego,

Here's some feedback.

- At PHY level in code, you can debug the actual frame to be sent OTA (Over The Air) in the "PhyPdDataRequest()" from the PhyPlmeData.c file. But it will probably be hard to analyze as it will be encrypted by the network layer from Thread.

I'd recommend you to look at a sniffer capture using Ubiqua Protocol Analyzer or Wireshark. You will also require an sniffer like the USB-KW41Z. You should be able to see something like this:

- You can verify the number of hops left from a packet in the 6LoWPAN header. See below an ICMPv6 echo request from a node that will require 2 hops to reach its destination:

- The path a packet takes to reach its destination is dynamic and will depend on Thread topology and link costs, you can also use the sniffer to trace the route taken by a packet to reach its destination. Just follow the IP address and MAC address to identify the hops that the packet will be taking. See image for reference.

- Thread uses a MESH topology.

- See the sniffer logs to analyze MLE advertisements or use the shell and type "thr get neighbors" and "thr get routes" to see the L2 links of the current device.

- The RSSI of a given packet can be seen in the sniffer capture from Ubiqua, see the Frame Information section (see first image). In code, you can obtain the RSSI of the last received packet with the PhyGetLastRxRssiValue() function.

Please refer to Thread 1.1 Specifications for details about Thread stack's expected behavior.

Hope this helps.

Regards,

JC

[diegocomin]

Thanks a lot JC! I am now using the USB-KW41Z as sniffer and I am able to trace all the Thread variables I need. 

In my case I used a Host_controlled_device connected to my Raspberry Pi with a TAP interface to perform as a Border Router but Ubiqua does not recognize it as the Border Router (it actually recognize it as a normal Router), it is normal?

Regards,

Diego Comin

[jc_pacheco]

Yes, it's expected