This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Can not see any CoAP packets on sniffer when Leader role

[development software, with versions]

  1. nRF5_SDK_for_Thread_and_Zigbee_v1.0.0
  2. RaspPi_OT_Border_Router_Demo_v1.0.0-1.alpha
  3. NCP example located in <InstallFolder>/examples/thread/ncp/uart/hex/nrf52840_xxaa.hex
  4. nRF52840-PDK
  5. Raspberry Pi connect through an Ethernet cable to my switch that provides IPv4 connectivity with the DHCP service.

I've asked this question before. I'd like to create similar application, using nRF5_SDK_for_Thread_and_Zigbee_v1.0.0. My application is based on ble_app_blinky_c. I've added Thread protocol support to it, referring to Adding dynamic multiprotocol Thread support to BLE examples, and called thread_coap_utils_cloud_data_update(...) function in on_adv_report(...) function. In thread_instance_init(...) function, I've set

.role                  = RX_OFF_WHEN_IDLE,

then (built and) run. After that, OT_DEVICE_ROLE become Child and it works (I can see CoAP packets on sniffer). So that, I've set

.role                  = RX_ON_WHEN_IDLE,

then (built and) run. After that, OT_DEVICE_ROLE become Child or Router or Leader. When OT_DEVICE_ROLE become Child or Router, my application works (I can see CoAP packets on sniffer). But when OT_DEVICE_ROLE become Leader, I can not see any CoAP packets on sniffer (Of course, thread_coap_utils_cloud_data_update(...) function is called many times). In this case, when my application starts from OT_DEVICE_ROLE_CHILD, (after a short time) OT_DEVICE_ROLE changes to Router, then (after a short time) OT_DEVICE_ROLE changes to Leader (and CoAP packets are disappeared on sniffer).

Is this behavior expected? Can anyone help me?

By the way, is there any way to limit OT_DEVICE_ROLE Child and Router? SetLeaderRoleEnabled = false, or something...
Thank you.

EDIT: I've uploaded ble_app_scan_c_th.zip .

EDIT2: I've uploaded main.c_20180831.zip .

  • I'm not exactly sure what could be causing this. Did you test with RX_ON or RX_OFF setting?

    I have tried to reproduce the CoAP issue, but I'm not able to see the same behavior. If testing with the address you set in your application, I can't see CoAP packets at all. If I test with the address off one of the other nodes, I'm able to see CoAP packets in all three states, and with both RX_ON and RX_OFF setting. Have you tested to send CoAP packets to another node?

  • Hi,

    Thank you for inspecting the behavior. I've confirmed I couldn't see CoAP packets at all when I've tested with unreachable IP address in my application. I'm sorry I couldn't notice this requirement.

    Per your advice, I've tested to send CoAP packets to another PC, but it gave the same result (CoAP issue is ongoing). Once the device is in the Leader role, this state usually last very long, so that I cannot post my data for a long time. It's big issue. What am I missing?

    Thank you.

  • I'm able to see CoAP packets in any role, with RX_ON_IDLE set. I'm not sure why you are not able to see the packets when in Leader role, but it could be that you are giving too much radio time to the softdevice/BLE part of your application. You have a scan interval of 100ms, and a scan window of 50 ms. This will affect the Thread stacks ability to send/receive packets correctly. As described in the documentation, the performance is reduced drastically even with 90% timeslot available for Thread. I had troubles getting two boards to join the same network when BLE scanning was enabled.

    Have you tried disabling BLE scanning, to see if you are still seeing the issue?

  • Per your suggestion, I've changed main.c for disabling BLE scanning, and observed the response. Unfortunately, I've got same CoAP issue. What could be the cause of this issue?

    This main.c is supposed to do "BLE scan is stopped after first Advertising report was obtained, then call thread_coap_utils_cloud_data_update(...) function periodically (5[s] period)". Do you have time to review this main.c? I've uploaded main.c_20180831.zip.

  • Is the node running this FW still a part of a larger thread network when it is in the leader state (i.e., are you seeing other routers/childs when you run the 'router list'/'child list' CLI commands)? I can't get two boards running your FW to form one network, without involving other nodes. They either stay both in leader state, or in router/child state when I involve one node running the CLI FW from SDK. If the node is no longer part of the Thread network when you try to send the CoAP packet, it might be the reason you can't sniff the CoAP packets anymore (the receiver is in another network, and the packets is not transmitted as there is no receiver).

    If you can confirm/reject that you are seeing the same behavior, I can try to debug this further.

Related