RE: nRF Thread Topology Monitor: Issues Scanning Devices Flashed with Self-Generated .hex Files

gcb — Tue, 12 Nov 2024 14:03:22 GMT

I removed the low_power snippet from the build command, and now the network appears stable in the nRF OpenThread Topology Monitor. The low_power snippet puts the device into sleep mode, which likely causes it to be undetected during the next poll event from the network leader.

RE: nRF Thread Topology Monitor: Issues Scanning Devices Flashed with Self-Generated .hex Files

Kenneth — Tue, 12 Nov 2024 13:22:56 GMT

Hello,

Let me check internally if someone have a suggestion.

Kenneth

RE: nRF Thread Topology Monitor: Issues Scanning Devices Flashed with Self-Generated .hex Files

gcb — Mon, 11 Nov 2024 19:34:36 GMT

I successfully built and flashed the Thread CLI sample myself instead of using the pre-built .hex files. To specify the .hex file during the flash stage, I used the following command:

$ west flash --build-dir build/nrf52840dk --hex-file build/nrf52840dk/zephyr/zephyr.hex --erase

However, I'm now facing two issues:

OpenThread Shell not responding:

The OpenThread shell works smoothly when the device isn't yet connected to the network. However, after I run the following command in the OpenThread shell:

$ ot thread start

I see the device appear in the nRF Thread Topology Monitor, but the OpenThread shell becomes unresponsive and doesn’t allow me to enter any further commands. I would like to be able to check details like the parent and child IDs, routing tables, and change the device role, but I’m currently unable to do so once the device joins the network.

In nRF Thread Topology Monitor not stable:

Although I can now see multiple devices in the nRF Thread Topology Monitor, the devices are constantly appearing and disappearing. Is this a potential bug in the nRF Thread Topology Monitor, or could it indicate that the devices are actually disconnecting and reconnecting frequently on the network?