CC2530: Data Requests with No Acknowledgement

Jack Loop

Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK

Hi,

I have been testing some devices with SampleLight on them, and I noticed that at some point, they all do a bunch of Data Requests with no acknowledgement. This runs from packet 639245 to 639304; then the devices go back to data requests and acknowledgements again. What might be causing this? Is this a problem from the coordinator or from my device? What exactly does all this mean?

over 7 years ago

0 YiKai Chen over 7 years ago

Guru 735695 points

This issue is caused by device’s parent doesn’t have network response to data request so device doing retries. If it keeps no ack, device would turn orphan status and start to look for new parent to rejoin.

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

How come each device does ~5 data requests, then the next device does ~5 data requests, and so on - INSTEAD of each device doing 1 data request, then the next device, and so on?

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735695 points

That's MAC retries defined in Z-Stack.

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

Thanks. I also have an issue where 1 of my devices, 0x6CD5, dies after doing a bunch of data requests with no acknowledgments. None of my other devices have this problem What is the cause of this?

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735695 points

According to screenshot, it’s coordinator doesn’t respond mac ack so I think the issue is on coordinator.

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

Why would it be the coordinator's problem if it gives acknowledgements to my other 4 devices?

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735695 points

You already said that coordinator gives ack to other 4 devices but not this one and you can see your device sending beacon requests in sniffer. Doens't it mean coordinator acts incorrectly?

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

I checked again and I see that it is the coordinator's fault now. Now I have another issue where my device, 0x16FB, doesn't do any POLL_FAILURE_RETRIES, and suddenly restarts itself, and does a beacon request to rejoin the coordinator. And when the device rejoins, the RSSI jumps from 30 to 55. This device does this multiple times. Why is this happening?

0 Jack Loop over 7 years ago in reply to Jack Loop

Guru 17870 points

I think this may be caused by the osal timers on my program. I am using the below osal timers for my own purposes. Can you tell me which ones I shouldn't use? And what osal timers I should I use instead?

0x0001
0x0002
0x0080
0x0040
0x0800
0x1000

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735695 points

All the event ID looks OK to me. It should not be the problem.

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

Then what may be the cause of the issue, mentioned in my previous reply?

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735695 points

As you said, your device seems reboot. Do you enable watchdog in your application?

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

I use SampleLight. So I think watchdog is used.

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735695 points

Default SampleLight doesn’t use watchdog. Do you enable watchdog by yourself.

0 Jack Loop over 7 years ago in reply to YiKai Chen

Guru 17870 points

I did not enable watchdog by myself.

0 YiKai Chen over 7 years ago in reply to Jack Loop

Guru 735695 points

Then, you should check if there’s somewhere in your application code would cause reset.

Zigbee & Thread

Zigbee & Thread forum

CC2530: Data Requests with No Acknowledgement