JN5168 - long RX periods before transmission

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

JN5168 - long RX periods before transmission

642 Views
witoldsowa
Contributor II

Hi,

I run an application based on JN-AN-1220, a motion sensor (End device) on a JN5168 M00 module. I tried to examine the power consumption in a scenario when the device is woken up, sends an attribute report update and goes back to sleep. I've expected to get results similar to these from JN-AN-1001 but it turned out that the active period is much longer (c.a. 20 ms) to transmit just one frame (verified with the sniffer that only one frame is actually transmitted). So I started to dig deeper and found that in other scenarios I can see the same behavior. I've put the device in permanent polling more in which it stay awake and sends Poll Request every 100ms and I've captured with the oscilloscope a current consumption for over 600 pull requests (over a minute of permanent polling). Please see three different examples of current consumption plot attached captured within the same persistent polling session just a few 100s of ms apart:

SDS00066.pngSDS00067.pngSDS00068.png

As you can see the time of elevated current consumption due to radio activity varies a lot. According to the datasheet the device pulls c.a. 17mA and 15mA when receiving and transmitting respectively.

You can see in all three cases that in the end of the period of elevated power consumption it drops a bit which I believe is the transmitting of Poll Request (it should transmit c.a 0.5ms).

However before it there is a period of variable length where I believe the device is receiving. It can easily get over 10ms which is definitely not great for battery operated device. The behavior seems consistent regardless of channel used. Above cases are captured when using channel 26 which should be quite silent.

My questions are:

1. Why is the device receiving for so long and so varied period of time before transmission? First CSMA/CA backoff should last at most 7*0.320ms and I believe should be with receiver disabled. CCA should last c.a. 0.1ms. So where so long receiving period comes from?

2. Is there any configuration that can impact the behavior?

3. How can I debug it further i.e. find out what the chip is actually doing in these few ms periods of receiving?

Thanks,

Witek

Labels (3)
0 Kudos
2 Replies

536 Views
witoldsowa
Contributor II

Sure, but...

Zigbee is based on IEEE 802.15.4, right? So the conclusions about RF and power consumption should apply. In other words why do you expect Zigbee stack to not power down receiver in backoff periods?

As wrote I run the exemple code on bare JN5168-M00 module. I don't have any other sensors or components connected. I see no extra power drawn. I am not sure what other factors do you mean...

0 Kudos

536 Views
mario_castaneda
NXP TechSupport
NXP TechSupport

Hi Witold,

You are measuring the JN-AN-1220 that supports Zigbee Stack. The JN-AN-1001 is based on  IEEE 802.15.4.

You have some other factors that you have to be the case.

Then, the AN has some sensors connected to the board, how are you measuring these values?

Regards,

Mario

0 Kudos