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

ZIGBEE association problem

HI,

I'm using the zigbee CLI example as coordinator and have another CLI device for reference as router. With my sniffer I can log the association sequence with the cli router and everything works fine. But with my device under development (not using the nRF-IEEE- 802.15.4-radio-driver but another 3rd party radio driver) everything works until the coordinator sends the association response, which I send an ACK within 1ms but the coordinator keeps sending the association response. The ACK I send is shown in the sniffer, and has the right sequence number. Could there be any reason why the coordinator doesn't receive the ACK? I'm using DEBUG_TRACE in the coordinator and since the dump tools are no longer there, I manual looked to the dump data and I can see the ACK from the association request, the association response, but not the ACK from the association response. The attached pictures show the sniffer log from the failing association and the good one from the reference device.

Do you have any idea why the ACK might not be received?

BR, Hardy

  • Hello Hardy,

    What does the sniffer trace look like in your case? Is it like mine? Can you please try to open it on another computer than it was captured?

    Either way, what packet number (since I am not able to display it properly) is the ACK that you are curious about? What ACK is not received properly?

    What device is the coordinator? Is it an nRF? What IEEE stack is that one using?

    Please understand that this is not the typical questions we get, since the 802.15.4 driver is usually handling these kind of things, which is why I am not certain of what delay that is expected. 

    Hardy Bismark said:
    The original stack responds with an ACK in 544 µs but my stack can only respond with 1045 µs. Now this shouldn't be a problem anymore.

    Does that mean that you figured out, and solved the issue? Was it only because the ACK was "too slow"?  

    Best regards,

    Edvin

  • Hi Edvin!

    Yes, it seems so that the ACK was just too slow and I actually did not use the driver library bu compiled the driver to be able to debug. I took in the nrf_802154_precise_ack_timeout.c because of a function needed in there which not exist in nrf_802154_ack_timeout.c. Now I fixed the problem and it worked.

    You don't need to spend more time with it, thanks anyway.

    BR, Hardy

Related