CC2530ZNP Mini Kit

Try running the basic communications - end device example. What is the power consumption once the device gets on the network and once you sleep it?

You shouldn't have to do a znpReset() to get it to sleep. Maybe someone from TI can verify the ZNP's low power functionality.

--Derek

Thanks Derek,

I thought, if I didn't manage to send anything, CC2530 would get into deep sleep. So I turned off Polling (I set ZCD_NV_POLL_RATE, ZCD_NV_QUEUED_POLL_RATE, ZCD_NV_RESPONSE_POLL_RATE to zero, put msp430 into LPM3), sent only one message to make sure it on the network. After it's settled, I received a changing current between 0.44mA and 0.57mA every second (like a heart beet???). I happened the same on both Mini kit and a board I did (MSP430F5510 + Chinese Zigbee module TT2530), I used Z Stack image from mini kit example code folder (CC2530-MK-Pro.hex).

Derek, Do you have any idea on this?

I also tested energy with sensor monitor network code on mini kit and it worked very fine. What different between two code?

Thanks again.

Tuong

Hi Toung,

I believe even I am facing the same problem with the heartbeat. I think probably it is used by the Zstack to maintain Time (i.e. For internal Time Functions. I am not too sure, and maybe someone from TI can verify, and reply if there could be a way to turn it off, or we just need to live with it.

I have a thread posted in the forum, you may view to confirm if its the same issue of the heartbeat you are facing. If you actually check the current on the oscilloscope the consumption is about 5mA for a very short period during this heartbeat.

Regards

Royston

Sorry, Forgot to add a link to my thread

http://e2e.ti.com/support/low_power_rf/f/158/p/212483/764238.aspx#764238

Regards

Royston

Dear Toung

As well i believe you meant  0.44 uA and 0.57 uA not mA.

Did you manage to get any replies for the above

Regards

Royston

That once a second pulse is the Zigbee End Device polling its parent. It can be turned off by setting ZCD_NV_POLL_RATE to zero. When I did that the one second pulses went away. Make sure you're setting that parameter to zero before you start the application.

When using the End Device example I was able to get the measured sleep current of MSP430 + CC2530ZNP down to about 7uA. I could have probably gone further by cleaning the board, doing more analysis, etc. but that was good enough for me.

--Derek

Hi Derek,

I have already turned off the ZCD_NV_POLL_RATE. There are a few ways I have confirmed that this is not the end device polling its parent.

1. I have check the packet sniffer, and I see no data requests from the end device to the coordinator. Please note if I turn on the ZCD_NV_POLL_RATE to 2000 I can get the data request of the end device in the sniffer. The fact that I don't see any data request means that there is no RF transmission taking place.

2. I have checked the CC2530 current by placing a series resistor in VDD line. The CC2530 power is set to maximum, so I do get about 25mA when there is an RF transmission. I monitored the current during the 1 second wakeup and the current was only about 5mA. So it could not have been an RF transmission.

Will upload the oscilloscope recording here, with the ZCD_NV_POLL_RATE set to 0 as well as the ZCD_NV_POLL_RATE set to 2000.

The following is the code for the ZNP, in which I have set the 3 Poll Timers to 0 before starting the application.

/* Set the Poll rate to 0 so that we do not frequently poll the coordinator */
setPollRate(0);
handleReturnValue();

setQueuedPollRate(0);
handleReturnValue();

setResponsePollRate(0);
handleReturnValue();

setTransmitPower(4);
handleReturnValue();

setZigbeeDeviceType(END_DEVICE);
handleReturnValue();

afRegisterGenericApplication();
handleReturnValue();
delayMs(500);

zdoStartApplication();
handleReturnValue();

Regards

Royston

Hello,

I spent almost 2 weeks banging my head and trying to understand why the sensor monitor network goes to low power mode and I am glad to share what I found with you. More on this can be found in the topic I started http://e2e.ti.com/support/low_power_rf/f/158/t/223823.aspx .

The short answer is that your znpReset function probably toggles a DEBUG signal and you have to just leave it be (it is set to 0 in halInit). So, just comment out the debug lines like below and it should go to very low power. If it does, visit the topic I started where someone will hopefully explain what this signal is.

Best regards,

Florin.

unsigned char* znpReset()

{

    RADIO_OFF();

    //DEBUG_OFF();

    delayMs(1);

    RADIO_ON(); 

    //DEBUG_ON();

    znpResult = spiPoll();              //Note: this will be different if UART

    return (znpBuf+SRSP_PAYLOAD_START);  //the beginning of the reset indication string

}

Hi Florin,

I had already commented the DEBUG_OFF and DEBUG_ON statements. Even after doing so I found some activity performed by the stack periodically every second. This happens even if all the 3 poll timers are set to 0. Plus the RF section Transmit does not come on, it is just the CPU executing some code since the current is only 5mA. 

Did you check the current by placing a 10E resistor in series and monitoring the voltage drop accross it. You may notice the periodic wakeup of 1 second, even though your poll timers are off.

Regards

Royston

Hello,

I also get the periodic activity with all the poll timers set to 0. For now I am not very bothered by this since the mean current is reasonably low now. Before I commented the DEBUG lines I got 0.4mA current which was unacceptable so I am happy for now. In a short while I will move to the more advanced problem that you are facing and I will let you know my findings. Until then, let me tell you what I've got so far:

1. one of the function setPollRate or setResponsePollRate have an error, the check for bad parameters also excludes 0 which is not right because 0 is indeed what you want to use.

  if ((pollRate == 0) || (pollRate > 65000))  //should change 0 to 1

    {

        znpResult = -1;

        return;

    }

2. I found that if I shut down the coordinator while the device is in this very low power state (whith the periodic power spikes) the end device detects this and goest to 24mA, probably looking for a coordinator again. So i think that there is some radio activity after all even though you say that the current draw is only 5mA. I suppose you measured this with an oscilloscope, maybe the sampling rate was too small to catch a bigger spike?

So far I checked the current by removing the R3 resistor and wiring an in series ampermeter. This was good enough for my rough estimates. When I will need to get into more detail I will do as you say, measure the voltage drop across a resistor so I can use an oscilloscope.

I'll keep you informed of my progress and please do the same, having someone that faces what seems to be the exact same problem feels good, I almost lost all my faith working alone till I discovered the DEBUG thing.

Best regards,

Florin

I found the cause of the 1 second polling. Unfortunatelly the amount of typos in the provided code is  big enough to cause many headaches... I compared the #defines in my code that kept polling no matter what I did to the sensor network demo that does not poll and I found a different definition. ZCD_NV_POLLRATE was defined as 0x25 instead of 0x24. Very strange typo considering it is followed by ZCD_NV_QUEUED_POLL_RATE   which was also 0x25 and should have raised a warning to whoever wrote it. Anyway, setting to 0x24 stopped my code from constantly polling for messages from the coordinator. Now I can shut down the coordinator and the end device doesn't even notice it. Good luck and let me know if this worked for you.

#define ZCD_NV_POLL_RATE                0x24 //0x25

#define ZCD_NV_POLL_RATE_LEN            2

Best regards,

Florin.

Hi Florin,

I already had that figured out few months ago. 

#define ZCD_NV_POLL_RATE 0x24
#define ZCD_NV_POLL_RATE_LEN 2
#define ZCD_NV_QUEUED_POLL_RATE 0x25
#define ZCD_NV_QUEUED_POLL_RATE_LEN 2

#define ZCD_NV_RESPONSE_POLL_RATE 0x26
#define ZCD_NV_RESPONSE_POLL_RATE_LEN 2

As well I have made the other poll timers 0 and I am sure there is no transmission from the end device to the coordinator

But currently, even after doing this, if you check from a oscilloscope with a series resisitor, the CPU does wake up after 1 second, however there is no radio transmission. That is why the consumption is only 5mA instead of 27 mA during this period. I noticed this as I was developing an application using a microphone and the 1s wakeup was disturbing the output signal of the microphone. I tweaked some code in ZNP stack of the ZNP processor and am able to achieve 400nA sleep current for the ZNP processor.

Regards

Royston

Dear Florin,

I have confirmed my findings by checking the packets on the Packet analyser for the data request packet, since the poll rate is disabled there are no packets detected.

As well I am sure of my oscilloscope readings of 5mA and the trigger as I kept rechecking it for 2 days and finally tweaked some code in the ZNP. Had to do this since I needed extremely low power that the CC2530 can go into as specified in their data sheet, i.e. deep sleep.

Regards

Royston

Hello,

Sorry for not reading more carefully what you repeatedly said in your posts. I understand now that the polling and the ZNP wakeup were 2 different things. It's just that I was too happy I had solved my own problems and I thought I could help you too. I'm glad you have solved your hopefully final problem and maybe when I get that far I will ask you for a bit of guidance. Good luck with your project!

Best regards,

Florin Tufescu