Using TI's SLUC461 spreadsheet to design a system using a BQ25570 energy harvester

15 Jun 2019

About

Texas Instrument's BQ25570 chip is an energy harvester. Its datasheet explains how to size system elements e.g. storage and solar cells. The datasheet gives many formulas for sizing. The datasheet refers to spreadsheet SLUC461 http://www.ti.com/lit/zip/sluc461. The spreadsheet encapsulates the formulas. I can't find an explanation of the spreadsheet. This is my interpretation of the spreadsheet.

Disclaimer: I could be mistaken. This was written quickly, without review.

The example

This is for my particular example using:

As explained in my previous post, this configuration suffers long coldstart. The MCU is programmed to monitor its own voltages and not use much power to prevent exhausting energy and going back through coldstart.

Obvious generalities about the spreadsheet

The spreadsheet has green boxes for your data entry. The yellow boxes are constants or computed.

You enter data in the top, the bottom right corner shows the pertinent results, suggested/required:

The original example in the spreadsheet

When you first open the spreadsheet, it has data for a system shown on the second "block diagram" sheet. That system uses two power rails. It has two active modes: radio and computing, plus sleep. I won't discuss that example. In this example, there is one power rail, and one activity (neglecting miscellaneous computing.)

Prelude

You will soon see that certain things may dominate (supercapacitor leakage in this case.) Also, the activity (LED at 8mA) dominates any brief computing say at 1mA. So don't sweat any parameters until you get a sense of what is important in your system.

This example system sleeps mostly with extreme low power (duty-cycled.) The sleeping system requires tens of nA.

With any solar powered system, without battery backup, the behaviour is statistical. You plan for the average case, but in the extreme, for outliers, the system won't do what it is supposed to do. (In this case, blink an LED.) If you can't live with that (for example a sensor network providing important data), use a battery.

The system won't fail completely, it should start back up. Even a solar powered system with battery backup will fail in that sense when the battery dies. Here, the system may be expected to function for decades of years, in the same way (with occasional coldstart, but basically functioning.) Since supercaps are rated for decades of use.

As seen below, some parameters concern extremes of the weather and solar illumination or lighting.

The parameters (labels of green boxes on the spreadsheet)

VSTOR nominal: the max voltage to which VSTOR and VBAT will be charged.
I am not going to program the Vbat_ov resistors, so VBAT will charge to the max that the BQ will provide (about 5.25V). This is less than the rated WVDC (working, max voltage) of the supercap, 5.5V. I think "nominal" just means it won't always be at this voltage, when it is partially discharged.

VOUT: the voltage to which the buck converter regulates. Converter is step-down, this is max. Again, under certain conditions, the buck converter is in pass-through mode and the voltage will be less.

IOUT: the current drawn by the load in active mode 1. Here, suppose it is lighting an LED at 8 mA.

Est Buck Effcy per datasheet: the efficiency (fraction of 1) of the step-down converter. Look in the datasheet for curves say Fig. 12 in section 6.6 and extrapolate.

Active Mode 1 - bq25570 VSTOR: this is the load on VSTOR (when there are two power rails.) Since there is only one power rail, enter zero. The load IS on the VSTOR net, but on the VOUT pin via the buck converter.

Mode Duration: how long we will be drawing the IOUT current, i.e. lighting the LED. I entered 0.010 second (10 mSec) which is enough for a visible blink. (The human eye can actually see a much shorter blink.)

Mode Period: how often the activity will take place. I entered 40 seconds. I will actually blink more frequently, but not in a regular pattern. That is 2160 blinks per day.

Active Mode 2... (several boxes): In this example there is no second activity. Enter 0 in the IOUT box, and 0 in the VSTOR box. The other boxes don't matter, the calculated mwHr/Day will be zero regardless.

Sleep Mode - bq25570 VSTOR (1.8V rail off): This is the system load while the activity is not taking place, i.e. while sleeping. The spreadsheet assumes the configuration where this load is on the VSTOR pin. In my example, the load is still there, and on the VSTOR net, but via the buck converter. I entered 0.001mA, since the sleeping system has the MSP430 off and only the RTC on, with a total current much below 1uA (say 50 nA !!!)

bq25570 quiescent current + storage element leakage current : the leakage current of the supercapacitor plus the operating current of the BQ. The BQ25570 uses about 0.5uA when operating. The datasheet for the DGH504Q5R5 0.5F specifies leakage current of "8uA after 72 hours". I take this to be the max, not typical. I measured it myself once on one instance, and measured about 2uA. Enter some number, you will see that this dominates the power required (mwHr/Day.) For the value 4uA, the power is about 50% of all power required.

...max consec dark days... : the worst case expected period where there is no solar energy at all. I assume they mean when the illumination is less then the amount that yields the power supplied by the solar cell as specified in "...panel power per panel..." box. I.E. a completely dark day. Even an overcast day may have an illumination of 1k lux, which may yield some current from a solar cell, say 200uA @ 0.5V in this example. The storage must carry the system through this many days without any recharge. This parameter has a large effect. This parameter is correlated with the parameter "...panel power per panel..." which describes illumination. If you specify greater minimum illumination, you can expect more days when that illumination is not available due to weather. You might say these two parameters are educated guesses, based on weather patterns.

Mininum super capacitor voltage: the voltage to which the supercapacitor can or will be discharged. The Vbat_uv is hardcoded in the BQ to 1.95V. Thus the BQ will disable the buck converter at this voltage, and mostly stop discharging the storage (except for leakage.) I entered 2.0V. The load itself, in this case an MCU, could shut itself off at a higher voltage and then you might enter that voltage. (I think the comments in the spreadsheet are in error: should be Vbat_uv < min super cap < Vstor nominal)

Maximum super capacitor voltage: the rating of the supercap. You can also program the BQ's Vbat_ov threshold to prevent the supercap from overcharging. Here the supercap is rated higher (5.5V WVDC) than the BQ can possible produce (5.25V). I entered 5V.

Operating days per week: I entered 7. The example system works all week, not just workdays (5) or weekends (2).

Charging hours per day: this depend on the latitude and season, for an outdoor, sun illuminated system. I entered 8 hours, which is approximately the minimum hours of daylight (full bright-sky illumination) in the winter at mid-latitudes.

Divide by panel power per panel datasheet: extrapolated (possibly) from the solar cell datasheet. In my case, the KXOB25-14x1 only specifies this parameter for full, direct sun illumination (one standard sun?) So I extrapolated for much less illumination (1K lux) which is less than a typical overcast day. I used a lower value because the system might be installed where a total hemisphere of bright sky would NOT be seen by the solar panel. I used 0.058mW/squarecm. At full sun, the datasheet gives 41mA/squarecm in direct sunlight at approximately 0.6V (25mW/squarecm.) But the difference in power for overcast day is at least 100x less. My extrapolation could be way off. I should do experiments with part instances instead.

Again, this is correlated with other parameters. If you use a higher value here, you might need to use a lower value for "max consec dark days."

Results

Very loosely speaking (because this is a quick narrative, not a copy of the spreadsheet instance):

You can easily cheat by tweaking the parameters to get the result you want. You still need to test and characterize using many instances of a real system in real conditions.