ZIGBEE association problem

RE: ZIGBEE association problem

Hardy Bismark — Tue, 16 Mar 2021 08:39:12 GMT

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

RE: ZIGBEE association problem

Edvin — Mon, 15 Mar 2021 16:15:26 GMT

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.

[quote user="Hardy Bismark"]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.[/quote]

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

Best regards,

Edvin

RE: ZIGBEE association problem

Hardy Bismark — Mon, 15 Mar 2021 13:56:49 GMT

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

RE: ZIGBEE association problem

Hardy Bismark — Mon, 15 Mar 2021 12:05:04 GMT

Hi Edvin,

since I was testing the original driver with another CLI device, I'm sure it would work. And even I'm using my own driver, I send the ACK in right time with right sequence number.

My question is why would the coordinator not receive the ACK? Is there a certain time window for the ACK being received? Not too fast, not after timeout? So I'm sending the ACK right after receiving the association response, but the coordinator doesn't get it. This is the actually problem. The screen shots in the first post shows clearly the different behavior for my custom unit and the reference unit. I might delay the transmission of the ACK and see what's happen.

I don't use special keys, just the keys from the instruction on the sniffer documentation pages.

Key: 5A:69:67:42:65:65:41:6C:6C:69:61:6E:63:65:30:39, Byte Order: Normal, Label: ZigbeeAlliance09
Key: ab:cd:ef:01:23:45:67:89:00:00:00:00:00:00:00:00, Byte Order: Normal, Label: Nordic Examples

BR, Hardy

RE: ZIGBEE association problem

Edvin — Mon, 15 Mar 2021 11:22:21 GMT

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

RE: ZIGBEE association problem

Hardy Bismark — Thu, 11 Mar 2021 14:53:42 GMT

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.devzone.nordicsemi.com/.../zigbee_5F00_20210310_5F00_-join_5F00_procedure_5F00_fail.pcapng devzone.nordicsemi.com/.../zigbee_5F00_20210310_5F00_-join_5F00_procedure_5F00_ok.pcapng

BR, Hardy

RE: ZIGBEE association problem

Edvin — Thu, 11 Mar 2021 12:25:04 GMT

Hello Hardy,

[quote user=""]But with my device under development (not using the nRF-IEEE- 802.15.4-radio-driver but another 3rd party radio driver)[/quote]

So is this device under development an nRF? Why is it not using the radio driver from the SDK? Is it an option to test using the nRF-IEEE driver if it is an nRF device? If only for debugging purposes, to check whether the issue is radio driver related or application level related?

And in case I need to run this by our zigbee team, can you please upload the .pcapng sniffer trace here? If you need to capture a new sniffer trace because the old one isn't saved, can you please write a short description of the relevant packets?

Best regards,

Edvin