ZIGBEE association problem

[Hardy Bismark]

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

[Hardy Bismark]

Hi Edvin!

Yes, the device is a nRF52840. We're using a 3rd party mesh OS, which is using the softdevice for BLE in a multi-stack configuration. We're trying to run ZigBee together with this stack. The stack deliverer has supported us with a timeslot API, which makes sure we can use the radio the same way we would use the softdevice. Everything works great actually. Just the coordinator doesn't get the ACK even it is shown in the sniffer. The pcapng files are attached.zigbee_20210310_ join_procedure_fail.pcapngzigbee_20210310_ join_procedure_ok.pcapng

BR, Hardy

[Edvin]

Ok. Would it be a large job to port to our IEEE 802.15.4 driver, just to check whether the issue with the ACK is coming from the driver that you are using? 

Are you using some special encryption key? I can't decode your sniffer trace. Did you use the nRF Sniffer for 802.15.4 to capture this?

What does it say in your preferences -> protocols -> zigbeee -> pr-configured keys:

I can't see the sniffer trace properly.

BR,

Edvin

[Hardy Bismark]

Hi,

now I discovered, that the nrf driver used probably the ...precise_ack_timeout.c I use now the default timeout

#define NRF_802154_ACK_TIMEOUT_DEFAULT_TIMEOUT 7000

Now the coordinator receives the ACK from my node.

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.

BR, Hardy