• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 55 subscribers
  • Views 224 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: ZNP Confirm Key timing

Gustavo Vasoin
Prodigy 20 points
Part Number: CC2652P
Other Parts Discussed in Thread: Z-STACK

Hi, we are developing a ZigBee coordinator using the ZNP package. We have some trouble pairing with 3rd party devices, and talking with their developers, they suggested changing the time a Confirm Key for the Trust center is sent after Verify to lower than 1 second, since their custom Hub sends the Confirmation inmediately. Is this possible to change in the ZNP. I have seen Confirm time between 2 and 3 seconds, but don't know where this time could be determined. We will keep searching for other alternatives, but would like to try this if it's possible.

  • 0
    TI__Guru**** 207107 points

    Hi Gustavo,

    Can you please provide a sniffer log of the joining process?  Typically the Confirm Key is sent immediately after the Verify Key packet and delays of a couple seconds is unexpected.  If the joining device is a sleepy ZED then ensure that it is polling frequently.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 20 points

    Hello Ryan, thanks for answering.

    5b0fleave.zip Here's an example of the end device receiving Confirm Key after 2 seconds.

    Packet 46 requests the key, 53 sends the transport key, the verify in packet 55,and the confirm is sent in packet 67.

  • +1 in reply to Gustavo Vasoin
    TI__Guru**** 207107 points

    Thanks!  The first Data Request from the 0x5b0f ZED (packet 59) after the Verify Key data packet (55) is MAC ACKed (packet 60 with the Frame Pending bit set) by the ZC and is immediately followed up with the APS ACK (packet 61) because the Verify Key APS Acknowledgement Request is set to true.  During the next Data Request (packet 65) the Confirm Key (packet 67) is sent by the ZC immediately.  Thus the ZC sends the required APS ACK (as requested by the ZED) and Confirm Key packets as quickly as ZED is supplying Data Requests.  You can speak with the 3rd party devices developers to figure out whether the Verify Key APS Acknowledgement Request can be sent to false or another Data Requests can be supplied afterwards more quickly so the ZC knows when to send the Confirm Key.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Prodigy 20 points

    Thanks a lot. will check again with them.

    Just to know, because I expect them to ask me, would it be possible to send the APS Ack or Confirm Key without waiting for the Data Request? Their hub doesn't wait, because they set the End Device to stay awake during pairing, but I guess this isn't standard.

  • 0 in reply to Gustavo Vasoin
    TI__Guru**** 207107 points

    The Z-Stack source code is not designed to send data packets to ZED children without first receiving a Data Request.  The Association Request from the 0x5b0f device has the Receive On When Idle bit set to False and is the RFD (Reduced Function Device) Type.  ZR neighbors are responded to immediately.

    Regards,
    Ryan