• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 55 subscribers
  • Views 260 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2652P7: Packet loss even with network have only 2 device and short distance

Buong Vo
Prodigy 70 points
Part Number: CC2652P7
Other Parts Discussed in Thread: Z-STACK, SYSCONFIG

Tool/software:

Hi,

My team are doing some range test with CC2652P7 module with Z-Stack SDK version 8.31.

One CC2652P7 is running zc_thermostat sample, the other is running zed_temperature sample. the Power mode of temperature end device is set to alway on. All Z-Stack network configuration are kept as default.
The end device will report the temperature manually (without configuration report) every 5 seconds. The send device has 2 counter: total send and total success (receive default response with correct sequence number)
The coordinator has 1 counter that increases when receiving report.

The test is running in a chamber and open air.

After long run, somehow there are few packet loss and my boss asks why the packet loss still happen in such these conditions.

Can we achive 0% packet loss in this set up? How do I explain if it happen? Below is the result from my test

The result from terminal

The result summary

Thanks

  • +1
    TI__Guru**** 219127 points

    Hi Van,

    There are several reasons and mitigations for packet loss:

    • CSMA/CA backoff due to a noisy channel, see the MAC_DEFAULT_MIN_BE/MAC_DEFAULT_MAX_BE and maxCsmaBackoffs in macPibDefaults from mac_cfg.c
    • Low incoming RSSI, for which you could lower the LBT RSSI Threshold (macPibDefaults in mac_cfg.c again) and increase the output TX power (SysConfig -> Z-Stack -> Radio -> Transmit Power)
    • The receiving radio was busy and missed these messages, for which you could try increasing Retries (SysConfig -> Z-Stack -> Advanced -> Packet Sending)

    We would know more about the nature behind the missed packet with a sniffer log.  Please see the End to End Acknowledgements documentation from the Z-Stack User's Guide to further understand how to identify such missed packets in the stack and thus work around such instances by resending the packets in question.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 70 points

    Hi Ryan,

    Thank you for your response.

    About sniffer log, somehow I cannot see the decrypted message. I'm using Wireshark and https://github.com/NordicSemiconductor/nRF-Sniffer-for-802.15.4. I add the TC default key and start sniffer from beginning when end device join network but cannot decrypt later messages. It worked in the past when I used the Coordinator ZNP sample in SDK v8.30

    About increasing retries, how can I calculate the maximum number messages will be sent with retries. Example, when the error happen at high layer (APS layer), when it retries to send, does the retries number of lower level reset to 0 or continue counting from current value.

    As you see in the attached photo, 2 devices were setup in a chamber and very close to each other, so i dont think noisy channel and low RSSI can happen. About receiving radio is busy, the end device send the message with 5 seconds interval, MAC retries =3, nwk retries=2, aps retries=3. With these setup, i dont figure out what make receiving radio busy and miss message.

    About APS retries, Does it relate to TxOptions: 0x04 = Acknowledged transmission in APSDE-DATA.request and value in syscfg "APS ACK Wait Duration (ms) = 6000"?

    . In the source code, this option can be set with function zcl_registerClusterOptionList() but dont see it's called anywhere. If this option isn't set, does APS retries still work?

  • +1 in reply to Buong Vo
    TI__Guru**** 219127 points

    I can't help with the nRF Sniffer device, here are TI resources for sniffing solutions.  It sounds like you have the correct tools and setup, perhaps the NWK key transport was not correctly detected by the sniffer device or Wireshark software.  You can continue to debug this for further packet insight.

    Here is a previous breakdown of retries (not applying to APS), if APS ACK is enabled then you can expect a retry if a MAC ACK is returned but no APS ACK is delivered withing APS ACK Wait Duration (APSC_ACK_WAIT_DURATION_POLLED) up to the APS Retries (APSC_MAX_FRAME_RETRIES).

    You can create an if statement inside of zstackmsg_CmdIDs_AF_DATA_CONFIRM_IND for when the zstack_afdataconfirmind_t status is not equivalent to zstack_ZStatusValues_ZSuccess, and thus understand more about the fail state.  You can also capture sequence numbers which will be helpful when comparing to your working sniffer setup.

    Regards,
    Ryan