Coordinator sending duplicate packets to sleepy device

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Coordinator sending duplicate packets to sleepy device

Jump to solution
921 Views
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???

Labels (1)
0 Kudos
1 Solution
491 Views
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

View solution in original post

2 Replies
492 Views
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

491 Views
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