cc2530 power lines for energy harvesting

Hi Pedro,

I think that the analog part and the digital part of the SoC can be powered from different source.

However the issue here is the power consumption of CC2530 when digital core is awake, it

should be around 6mA with medium CPU activity, which exceeds the current supplied by line one!

Hi Igor:

Tks for your answer.

I can handle 10 mA bursts for about 30 ms. Just as long as I put my cc2530 to sleep before harvesting system exhaustion.

If I increase capacitor values the 30ms can be longer (tested up to 500ms) at the exchange of reload time.

I believe I can control zstack configuration code in zmain.c. All functions before osal_start_system() can be executed one at a time so that the processor can be put to sleep waiting for my system to recharge (no hurries here). 

Controlling zigbee stack is another matter but I always require to turn radio on and for that I need 30mA available at power number 2).

I can use another microcontroller just to wake up the cc2530 but a solution with just one processor is preferable.

One more important question:  The radio module is powered from which power line?

Pedro

Hi Pedro,

Pedro Amaro said:

I believe I can control zstack configuration code in zmain.c. All functions before osal_start_system() can be executed one at a time so that the processor can be put to sleep waiting for my system to recharge (no hurries here). 

Well, this must be checked through and through.

Here are some values to start with:

1. Typical current consumed by the cc2530 in deep sleep mode (PM3) is ~0.1uA where the power consumption
   in PM2 is ~1uA, which is way less then your power line 1 is capable of.
2. These numbers are true if no additional current is drown from the IO pins 

So the solution of putting 2530 into PM2 or PM3 before initializing the Z-stack and then waiting for some sort

of external interrupt to wake the SoC and proceed with the stack, sounds feasible.

However, I strongly suggest you to hear at least one more opinion regarding this whole scenario (preferably from TI guy/s).

Pedro Amaro said:

One more important question:  The radio module is powered from which power line?

It uses both the DVDD and AVDD lines. Section 1.1.4 in CC253x User's Guide

Hi Pedro

Strongly suggest keeping al supply pins at approximately same level. Different levels can possibly forward bias internal ESD protection circuitry resulting in un-predictable operation. Depending on your supply voltage it might be possible to combine the two supplies using a circuit where diodes block reverse current.

Strategy of charging a capacitor prior to activating CC2530 is interesting. However, there are some challenges. How will you awake CC2530? If the CC2530 is to be awaken by its internal power on reset POR circuitry. The POR event will occur during capacitor charging when at the POR voltage. If source is not capable to provide sufficient current CC2530 will immediately start to drain capacitor charge and hence trigger a new POR when reaching critical voltage.

One suggestion
Leave CC2530 operating on RC oscillator after initial POR (typ ~3.4mA). In this mode enable the 300mA power source by a general purpose IO and only then enter normal operation. (typ ~6.5mA)

Note, I have never implemented anything like this my selves.  If you don’t find any principal errors in the suggestions above, I would start testing on CC2530 development kit to reveal if there are any issues.

Tor-Inge

Hello:

Tks both Igor and Tor-Inge for your kind answers.

As to Tor remarks 

Tor-inge said:

Strongly suggest keeping al supply pins at approximately same level. Different levels can possibly forward bias internal ESD protection circuitry resulting in un-predictable operation. Depending on your supply voltage it might be possible to combine the two supplies using a circuit where diodes block reverse current.

This will in fact be a crucial problem. The idea of having two power lines is that one of them will be near ground most time (disabled). I was expecting to be able to power Dvdd (digital power lines) from one power line and AVdd (analog power lines) from power line n2. This entails different levels for DVdd and AVdd most of the time. Note that when power line two is enabled both lines have the same level. I understand from your answer that it can be done just as long as I protect the CC2530 power lines with diodes. 

I have a custom board. But power lines project was done in accordance with TI demo boards. I’m evaluating the possibility of developing a new board with different power line design L…

Tor-inge said:

Strategy of charging a capacitor prior to activating CC2530 is interesting. However, there are some challenges. How will you awake CC2530? If the CC2530 is to be awaken by its internal power on reset POR circuitry. The POR event will occur during capacitor charging when at the POR voltage. If source is not capable to provide sufficient current CC2530 will immediately start to drain capacitor charge and hence trigger a new POR when reaching critical voltage.

For my system If capacitors have small leakage currents, lab pre charging is possible before land placing of nodes. So no real problem here…

Tor-inge said:

One suggestion
Leave CC2530 operating on RC oscillator after initial POR (typ ~3.4mA). In this mode enable the 300mA power source by a general purpose IO and only then enter normal operation. (typ ~6.5mA)

This suggestion worked fine. I managed to make all zstack initialization on harvested power. Mind that   ZMacInit(); function requires 32Mhz Oscilator.

There is still one problem. It is related with network discovery and join. Zstack performs these two actions at once. It takes about 5 seconds to terminate and return to sleep. My system can afford all this time on full power. These two operations seem to be performed before ZDO_STATE_CHANGE event is generated.

Can you tell me where in zstack code are these two operations being done?

Pedro Amaro said:

There is still one problem. It is related with network discovery and join. Zstack performs these two actions at once. It takes about 5 seconds to terminate and return to sleep. My system can afford all this time on full power. These two operations seem to be performed before ZDO_STATE_CHANGE event is generated.

Can you tell me where in zstack code are these two operations being done?

What is exactly the problem here?

Assume i'm using genericApp

I can power my battery less nodes during zstack startup code until it enters  osal_start_system(); (in zmain.c).

That is: all code up to this point can be sustained by my power module.

Then after entering osal_run_system(), where tasks are processed, nodes (end devices) start discovery and join procedures.

After discovery and joining  nodes sleep.

Then messages can be started (Hello World). To send a message nodes must wakeup, send the message and return to sleep.

This procedure can also be sustained my harvesting system because it take little time to send the message and receive an ack.

The problem is that during discovery and join procedures, I cannot make my nodes sleep. And because these two procedures take too long my power module is unable to sustain energy supply during this phase. 

I must be able to make my nodes sleep during discovery and join procedures as I did already during the send message phase. 

The problem is I can't find where exactly in the code this is happening.