• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 56 subscribers
  • Views 194 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2652P: Data cannot be parsed during packet capture

liu minghui
Prodigy 30 points
Part Number: CC2652P
Other Parts Discussed in Thread: Z-STACK

When the device communicates with the gateway, the packet catcher will catch this data. What is the reason

  • 0
    Guru 735515 points

    What SDK/Z-Stack version and example do you use and see such packets? Do you use default example and see this?

  • 0 in reply to YiKai Chen
    Prodigy 30 points

    SDK version ：simplelink_cc13x2_26x2_sdk_5_10_00_48

    I can't use default example and see this.The sdk runs on our hardware, which is not always the case.

  • 0 in reply to liu minghui
    Guru 735515 points

    Can you attach your sniffer log instead of screenshot? By the way, I would suggest you to use latest  simplelink_cc13xx_cc26xx_sdk_7_10_01_24 to test again and check if you see the same issue.

  • 0
    TI__Guru**** 208667 points

    Hi liu,

    Given that this cannot be replicated on a default example, I recommend that you further investigate what is necessary to cause the behavior and which change to the stack is making the packets appear.  I see some inconsistencies from the screenshot such as ZC Transport Key messages before a ZED Data Request (as though the end device associated as non-sleepy or with FFD capabilities) and a Beacon being sent from the ZED although this should not be enabled on a RFD.  There are also MAC Sequence numbers missing for the ZED which represents packets not shown by the sniffer log.  Please make sure that there is no confusion in the project as to the device's determined role.

    Regards,
    Ryan