Coordinator sending duplicate packets to sleepy device

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Coordinator sending duplicate packets to sleepy device

跳至解决方案
937 次查看
hasmukhtapaniya
Contributor I

Hi,

I am using SE Profile JN-SW-4164-ZigBee-SmartEnergy1.x-v1432 and Application Note JN-AN-1135-Smart-Energy-HAN-Solutions.I have configured ESP_METER_NODE(Coordinator) on JN5168 hardware.
Communication between ESP_METER_NODE and non sleepy end device working ok.When ESP_METER_NODE starts communication with sleepy end device,
ESP_METER_NODE is sending duplicate packets of responses like match descriptor response,Initiate key Establishment response,Confirm key Response,IEEE response to GSME sleepy device.
In packets APS counter remains same but Network counter is incremented for each packet.This scenario is not happening with non sleepy device communication.

Any configuration required for sleepy device???

标签 (1)
0 项奖励
1 解答
507 次查看
mario_castaneda
NXP TechSupport
NXP TechSupport

Hi Hasmukh,

Could you please provide a sniffer capture for this sleep end device?

The device then enters sleep mode, waking up every 7 seconds to request instantaneous demand

Also, you can check the 6.4.2 A Typical Wake-up Cycle for more information. Application Note: JN-AN-1135

Best Regards,

Mario

在原帖中查看解决方案

2 回复数
508 次查看
mario_castaneda
NXP TechSupport
NXP TechSupport

Hi Hasmukh,

Could you please provide a sniffer capture for this sleep end device?

The device then enters sleep mode, waking up every 7 seconds to request instantaneous demand

Also, you can check the 6.4.2 A Typical Wake-up Cycle for more information. Application Note: JN-AN-1135

Best Regards,

Mario

507 次查看
hasmukhtapaniya
Contributor I

Hi Mario,

Thanks,

This issue is resolved, the issue was with sleepy end device which was not polling fast enough. So end device does not receive the packet and not sending the ACK within 1.6 seconds, due to that co-ordinator was retransmitting the packet that is expected. We have modified the end device polling time from 1 second to 500 ms. After these changes we did not face this issue.

Regards,

Hasmukh