Application Report

SWRA462 – September 2014

SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™

Networking Sub-system Power Management

Ben Gilboa ....................................................................................... Embedded Processing Applications

1 Introduction
Power management and extended battery life are primary focus areas for embedded low-power Wi-Fi
devices such as the SimpleLink Wi-Fi Internet-on-a-chip solution. Handling power regimes effectively is
fundamental for any battery-operated device. This problem is especially challenging for standards-based
wireless devices that need to comply with certain requirements for Transmit power, Beacon interval, and
data rates, as is the case with embedded Wi-Fi devices. This application note covers CC3100/CC3200
Wi-Fi Internet-on-a-chip Networking sub-system power management (PM) capabilities, describes the
basics of system behavior, and provides the basic toolbox for developers to design an optimal system.
The CC3100 contains the Networking sub-system only and is driven by an external MCU host. The
CC3200 contains the same Networking sub-system along with an internal MCU application processor.
This document describes the Wi-Fi sub-system power management aspects, making it applicable for both
devices.

1.1 Terminology
This document refers to several power related measurement units:
• Current [ampere] – Refers to average current at 3.3 V, unless otherwise specified.
• Charge [coulomb] – [1C = 1 ampere × 1 second], refers to 3.3 V unless otherwise specified. Charge is
used when discussing finite processes (such as connection). Battery capacity is referred as mA × hour.
• Energy [joule] – [1 joule = 1 coulomb × 1 volt]

2 Low Power Internet Systems Considerations

When designing a low power networking system specifically based on 802.11 protocols, a designer should
consider several key aspects.

2.1 Power Supply

Lined-power or battery-powered device: line-powered systems are typically less sensitive to power
consumption than battery-operated systems. Battery-operated systems must consider the battery capacity,
along with the average usage profile against the lifetime target. However, there are cases where power
considerations apply to line-powered systems, such as when an energy budget is associated with each
endpoint. This is more common in managed deployment scenarios, such as enterprise environments.

2.2 Traffic Properties

• Traffic Model – The payload to be transmitted or received and the frequency of this activity. For
example, a sensor may typically deliver 100B every few minutes; alternatively, a video camera may
stream a throughput of 4 mbps on average, delivering 1500B every ~3 ms.
• Protocol Properties – This includes the transport protocol (UDP/TCP), the application protocol running
on top, and associated overheads.
• Type of Connection – The security protocols at the link layer and the transport layer, if any.
• System Latency – The expected latency time responding to incoming traffic. This parameter is
dominant in determining the sleep policy of the networking device.
All trademarks are the property of their respective owners.

SWRA462 – September 2014 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- 1

Submit Documentation Feedback system Power Management
Copyright © 2014, Texas Instruments Incorporated
Low Power Internet Systems Considerations www.ti.com

2.3 Network Topology

The following questions should be answered when approaching a low power networking system design.
These considerations apply to the specific problem the system will solve, before any specific
considerations of the networking device.
• Is the system expected to work as a server or a client? As a server, it might be expected to be always
responsive, while as a client it may initiate the communication events on its own timing, and may be off
for a defined period of time.
• Does the system always need to be connected to the Access Point? Maintaining the connection with
the AP enables the system to receive messages with low latency. However, maintaining the connection
usually consumes a significant amount of energy.
• Does the system always need to be connected to the server? Maintaining a TCP or SSL connection
with periodic keep alive messages consumes significant amounts of energy. The alternative of initiating
a TCP/ SSL connection every time implies overhead energy for the connection setup.
• Does the system communicate with a remote server or with a local one? In case of a local system
(client or server), consider all related background processes. For instance, service discovery protocols
such as mDNS tend to create excessive current draw owing to their defined nature.
• Is the IP acquisition method static IP or DHCP? DHCP processes may consume a significant amount
of energy.
• AP provisioning is the method used to obtain initial connection between the device and the AP. One
popular method is using the device as an AP, accessing from a mobile device, or using a PC to the
device as an AP for its configuration. Although provisioning is an infrequent event, the power
consumed during the process may be much higher than the power in regular device operation.
• What is the Round Trip Time (RTT), the typical delay between the end device and its peer? This delay
affects the maximum throughput of the system and the power consumption required per KB.
For example, consider a sensor system that both communicates with a server for a remote on line
capabilities (configuration, observation and alert indications), and provides the option for local access
directly from smartphone or PC while at home. The first requirement can be supported by a system that is
off for long period of times (minutes), checks the server periodically, or accesses the server whenever it
detects an environmental change. The second requirement of local accessibility is more challenging from
a power perspective. The system must always be responsive, thus it must be connected to the AP at all
times.

2.4 Solution Specific Parameters

This section describes some of the critical factors and parameters of the networking system that become
the building blocks of a use case, and defines the total power consumption.
• Maximum throughput – This factor corresponds to the time it takes the system to receive or transmit a
fixed amount of data, and thus the power consumption required per KB. This number should reflect the
lowest common denominator in the system. For example, assume host IF capable of delivering 12
mbps and a WiFi connection able to deliver 60 mbps. For UDP TX, expect to get closer to 12 mbps.
For a TCP connection with very long RTT, the maximum TP may be lowered to 2 mbps or lower.
• Initialization time and energy – For periodic use cases that involve frequent short activity cycles with a
long off-time in between, energy consumed during initialization may become a major contributor.
• Static current consumption – Any system use case is constructed from several building blocks, such as
RX current, TX current, sleep current, and so forth.
• Dynamic energy consumption – System optimization for low power, and the system's efficiency with
respect to power consumption while performing a specific activity. For example, connecting to an AP,
initiating TCP connection, maintaining a connection with AP, and sending or receiving a fixed amount
of data.

2 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- SWRA462 – September 2014

system Power Management Submit Documentation Feedback
Copyright © 2014, Texas Instruments Incorporated
www.ti.com Networking Sub-system Quick Overview

3 Networking Sub-system Quick Overview

The CC3100/CC3200 belong to a family of wireless networking devices for the deeply-embedded market.
Devices that belong to this product line consist of a full network stack over 802.11bgn. These devices are
highly-integrated solutions both from the hardware and software standpoint, including internal PA and
DC2DC circuit hardware accelerators for software offloading. The device supports industry-standard BSD
socket API, internal SSL/TLS security protocols, very low footprint driver requirements, and advanced low
power modes.
The two main variants for Simplelink™ Internet-on-a-chip device are:
• CC3100 – Full networking device controlled by an external host MCU.
• CC3200 – Full system containing a networking sub-system, along with CM4 MCU and peripherals.
In the CC3200, the user programming the CM4 controls the power mode of the CM4 sub system, however
in the Networking sub-system, the power management cannot be directly controlled by the user. Once
enabled, it always seeks to consume as little power as possible. The focus in this document is on the
Networking sub-system to better equip the programmer of CM4 in CC3200 or external host MCU in
CC3100 with the required knowledge to build an optimal power efficient system.

3.1 CC3100/CC3200 Main Blocks

Figure 1. CC3100/CC3200 Block Diagram

CC3200
Networking Subsystem - CC3100

NWP WiFi
SF

HOST
HOST IF Processor MAC PHY RADIO
MCU

peripherals

The Networking sub-system contains two main blocks:

• Wi-Fi block
• NWP (network processor) block

4 3100 Power Modes

The CC3100 device contains only the Networking sub-system and is self-contained in terms of power
optimization. The CC3100 may be in one of three modes:
• Hibernate – Lowest power mode. Memories are not retained. Requires cold boot initialization. RTC
clock keeps running and RTC counter keeps counting. Device is powered off except the hibernate
logic.
• Low Power Deep Sleep (LPDS) – Voltage levels are lowered, fast clocks (40 MHz XTAL and internal
PLL) are off. Memories are in retention mode. Device stays in low power deep sleep mode if the Wi-Fi
and NWP blocks have no immediate activity. Each of them manages its own sleep and wakeup events,
and when both are in their low power mode, the entire Networking sub-system is in LPDS mode.

SWRA462 – September 2014 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- 3

Submit Documentation Feedback system Power Management
Copyright © 2014, Texas Instruments Incorporated
3200 Power Modes www.ti.com

• Active – Device is fully active, voltage levels are at their operational value, and all clocks are ticking.
At least one block (NWP / Wi-Fi) is running. This mode may represent a wide variety of intermediate
power states which are of transient nature and not explicitly controlled by the system.

Table 1. 3100 Power Modes

Networking Subsystem CC3100 Block State

CC3100 Device Power Mode
Power Mode NWP WiFi
Disabled / OFF Hibernate Off Off
LPDS LPDS Retention Retention
Active Retention
Active (1) Active Retention Active
Active Active
(1)
In Active mode, NWP and WiFi can be in active or retention mode separately. If both are in retention, then the system is in LPDS
mode.

5 3200 Power Modes

For complete understanding of the CC3200 power modes, consider these three aspects:
• MCU subsystem power mode – Controlled by the MCU application.
• Networking sub-system power mode – Maintains power modes automatically when enabled.
• Device level (chip) power mode – Derived from a combination of MCU subsystem and Networking
subsystem power modes.

5.1 Device Power Modes

The device can be in one of three modes:
• Hibernate – Lowest power mode. Memories are not retained. Requires cold boot initialization. RTC
clock keeps running and RTC counter keeps counting. Device is powered off except the hibernate
logic.
• Low Power Deep Sleep (LPDS) – Voltage levels are lowered, fast clocks (40 MHz XTAL and internal
PLL) are off. Memories are in retention mode. Most of device logic is power-gated except for hibernate
logic and top level logic.On wake-up, the MCU starts from the reset vector.
• Active – Device is fully active, voltage levels are at their operational value and all clocks are ticking.

5.2 Networking Sub-system Power Modes

Networking sub-system may be in one of three modes:
• Disabled – NWP is off and requires a cold boot when enabled.
• Low Power Deep Sleep (LPDS) – Networking sub-system is in LPDS mode if the Wi-Fi and NWP
blocks have no immediate activity. Each of them manages its own sleep and wakeup events, and
when both are in their low power mode, the entire networking sub-system is in LPDS mode.
• Active – At least one block (NWP / Wi-Fi) is running. This mode may represent a wide variety of
intermediate power states which are of transient nature and not explicitly controlled by the system.

5.3 MCU Power Modes

MCU can be in one of four power modes, as dictated by the MCU programmer:
• Hibernate mode – The device is in hibernate mode.
• Low Power Deep Sleep mode (LPDS) – While the MCU in this mode, two scenarios may occur:
– The networking sub-system is disabled and the device mode is LPDS.
– The networking sub-system is enabled and the device mode is LPDS (if networking sub-system is
in LPDS mode) or active (if networking subsystem is active).

4 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- SWRA462 – September 2014

system Power Management Submit Documentation Feedback
Copyright © 2014, Texas Instruments Incorporated
www.ti.com Networking Sub-system Mode Switching

• Sleep mode – The MCU clocks are gated off in sleep mode and the entire state is retained. Device
mode is active. The MCU application exercises this mode using CM4 instructions, such as WFI or
WFE.
• Active mode – MCU is running and the device mode is active.
The following table describes the device power mode according to the MCU power mode and the
networking sub-system power mode.

Table 2. CC3200 Power Modes

Networking Sub-system
MCU Power Mode
Disabled LPDS Active
Hibernate Hibernate N/A N/A
LPDS LPDS LPDS Active
Sleep Active Active Active
Active Active Active Active

6 Networking Sub-system Mode Switching

There are three modes that the networking sub-system may be in during normal operation: Active, LPDS
and disabled (OFF).
• Transitioning from OFF to active mode and from active mode to OFF mode is controlled by a host
application using SimpleLink APIs.
– sl_Start API takes the networking sub-system immediately to active mode.
– sl_Stop API puts the networking sub-system in disable mode no later than the timeout parameter
specified by the API.
In the CC3100, sl_Start asserts the nHIB pin of the device, and sl_Stop de-asserts this pin after
sending a stop command to device. In the CC3200, sl_Start configures the internal register that
enables the NWP. sl_Start initiates the cold boot initialization process of the networking sub-system.
Initialization is finished when the networking sub-system asserts the IRQ line and the SL driver reads
the sl_Start API status.
• Transitioning between LPDS and Active modes: in the context of the networking sub-system, entry and
exit of LPDS mode is dictated by activity. There is no direct intervention of the host application. Both
Wi-Fi IP and NWP IP manage their activity according to their state (such as connected to AP,
connected to server, and so forth). When one of the IPs has no immediate activity (within a near
specific threshold) it may go to lower power mode. When both IPs are in their lower power mode, the
entire networking sub-system is in the LPDS mode. Neither the host application nor the SL driver know
whether the networking sub-system is in active mode or LPDS mode. When the host application wants
to communicate with the NWP (assuming it is not disabled) it simply sends a command. If it is in LPDS
mode when the command is sent, then NWP wakes up and handles the command thereafter. Note that
the networking sub-system does not enter LPDS mode while the IRQ line signaling an event to the
host is active. The IRQ line is cleared once the host driver reads the event status back from the NWP.
Therefore it is advised that power consumption-sensitive systems respond to NWP IRQ interrupts as
quickly as possible.

SWRA462 – September 2014 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- 5

Submit Documentation Feedback system Power Management
Copyright © 2014, Texas Instruments Incorporated
Power Policies www.ti.com

The following diagram presents the possible transitions between states, and the trigger for the transition.

Figure 2. Transitions Between States

7 Power Policies
From the host application perspective, there are only two modes of operation explicitly selected by the
host: NWP disabled (OFF) or NWP enabled (ON). Selection between Active or LPDS states is managed
internally by the NWP, using power management algorithms.
The networking sub-system is equipped with a policy management entity which allows a developer (host
application programmer) to guide the behavior of the power management algorithm through pre-defined
power policies. The sl_PolicySet API configures the device power management policy. The available
policies are:
• Normal (Default) – Best tradeoff between traffic delivery time and power performance. When
connected to an AP, the Wi-Fi module wakes up for every beacon reception. Wi-Fi and NWP modules
enter their low power mode after considering current activities and predict future activities.
• Low power – The NWP power management algorithm is more opportunistic, exploiting opportunities to
lower the power mode. Tradeoff tends toward power conservation performance (for example, tag
application). The networking sub-system enters LPDS immediately once the activity is over, without
predicting future activities. Almost every communication between the host and NWP takes the
overhead of waking up the subsystem, without any time in idle mode predicting future events. Low
Power policy is suitable primarily for unconnected applications (such as applications that use
transceiver mode, and not connecting to AP). When used in a connected scenario, behavior and
service is not guaranteed.
• Long Sleep Interval (LSI) – When an 802.11 station is connected to the access point, it must receive
the beacons transmitted by the AP. APs generally transmit a beacon every 102.4 ms. 802.11
standards define the DTIM (Delivery Traffic Indication Map) as a specific beacon that contains
information regarding incoming packets for the STA. The AP may choose its DTIM interval (such as 1-
every beacon, 2-every other beacon, and so forth). This special low-power policy instructs the
networking sub-system to skip beacons and DTIM packets, and comes with a desired max sleep time
parameter. The parameter reflects the desired sleep interval between two consecutive wakeups for
beacon reception. The Wi-Fi module computes the desired time and wakes up to the next DTIM that
does not exceed the specified time (see Table 3 for examples). The maximum-allowed desired max
sleep time parameter is 2 seconds. It is strongly recommended to set the LSI parameter below 1
second to ensure reliable service while current consumption is lowered significantly. Note that this
policy only works in client mode and external connection (internet connection via gateway). It
automatically terminates mDNS and internal HTTP server running on the device. TCP/UDP servers
initiated by the user application lead to unpredictable system behavior and performance.

6 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- SWRA462 – September 2014

system Power Management Submit Documentation Feedback
Copyright © 2014, Texas Instruments Incorporated
www.ti.com Low Power Design with CC3100/CC3200

Table 3. Power Policies

Desired Max Sleep Time Actual Wi-Fi Sleep Time
AP Beacon Interval [T.U] (1) AP DTIM Configuration
[Msec] [Msec]
100 DTIM=1 200 204.8
100 DTIM=2 500 409.6
100 DTIM=1 500 512
100 DTIM=3 1400 1228.8
100 DTIM=1 2000 2048
100 DTIM=4 800 819.2
(1)
T.U = Time Unit = 1.024Msec

Idle connected current consumption is specified in the Idle Connection Current section.
• Always On – Both Wi-Fi and NWP modules remain active and do enter their low power modes. WiFi
does not enter 802.11 power save mode.

8 Low Power Design with CC3100/CC3200

This section merges the low power considerations from the first chapter with the detailed characteristics of
CC3100/CC3200 products. The section introduces key features in the networking sub-system targeted to
save power and explains the key tradeoffs that a designer should consider and resolve while working with
this product.

8.1 Connection Policies

The networking sub-system is equipped with an advanced connection policy manager. The user may
define up to seven connection profiles stored in the device NVMEM.
A profile (set using sl_WlanProfileAdd ) is a structure of SSID, password, and a priority for the profile.
Whenever the networking sub-system is enabled and not connected to an AP, it strives to connect to the
AP with the higher priority profile. This behavior is enabled when the automatic connection policy is set
(using sl_WlanPolicySet). While connected to an AP, the networking sub-system does not switch to
another AP with higher priority.
A key feature of the connection manager is the fast connect feature (also set using sl_WlanPolicySet).
Fast connect policy dictates that upon initialization (transition from NWP disabled to NWP enabled modes)
or in the event of a disconnect, the networking sub-system immediately tries to connect to the last AP that
it was connected to. It remembers the SSID, security credentials, and the channel of the last AP and
automatically tries to connect to that network. The main advantage of fast connect over auto connection is
that the system skips the scan. When both auto connection and fast connection are configured, the
system first tries to connect to last AP according to fast connect policy; if it fails, it runs the scan process
and looks for the highest priority profile, then connects to it.
By skipping the scan process, a significant amount of energy is preserved. The scan process may be long
(few hundreds of milliseconds), during which the modem is active, switching between channels, sending
probe request packets, and listening for responses. Therefore, for every system use case that contains
multiple connections, using the fast connect feature is recommended.

8.2 Service Discovery

Upon connection to an AP, NWP automatically starts advertising itself by sending mDNS packets. Stop
the mDNS feature when it is not required by the system application. Stopping the mDNS feature is done
using the sl_NetAppStop API, and can be done once as an indication is stored in NVMEM.

SWRA462 – September 2014 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- 7

Submit Documentation Feedback system Power Management
Copyright © 2014, Texas Instruments Incorporated
Low Power Design with CC3100/CC3200 www.ti.com

8.3 Host Interrupt (IRQ) Handling

The networking sub-system handles its own power states, seeking to move to the lower power state
(LPDS) whenever possible. However, the NWP does not move to LPDS mode while the host IRQ line is
high. NWP asserts the IRQ toward the host to indicate on a command response or asynchronous event.
The host is then expected to read the event from the NWP, and the NWP clears the IRQ line. Since the
the NWP does not enter LPDS with the IRQ line asserted and it does not clear it until the host reads the
status, ensure that the host handled the IRQ line as soon as possible.

8.4 Reducing Host Wakeups using Device Built-in System Filters

The device is equipped with an advanced and configurable filtering mechanism in different layers. Smart
usage of the filters can reduce the amount of unwanted packets transferred to the host, and cause host
unwanted wakeup. By default, the device filters MAC layer broadcast and multicast and IP layer multicast
(that are not for the mDNS application).

8.5 Serial Flash Handling

The CC3100 and CC3200 use the serial flash (SF) for nonvolatile storage. With respect to power
management, verify that the SF does not become a system bottleneck. SF may be in one of three modes:
• Active – When the device reads from the SF or writes to the SF. NWP uses the SF to store internal
data and may write to SF asynchronously or to any other event.
• Standby – When the device does not use the SF, the CS (chip select) line is held high. This is also the
SF status during LPDS mode.
• Power Down – Before the CC3100/CC3200 enters hibernate, it sends the power down command to
the SF. This command is handled by the NWP in the CC3100, and by the hibernate driver in the
CC3200. For the CC3100, use the timeout parameter along with the sl_Stop command to allow the
NWP to send the power down command.
SF standby current should be added to the LPDS current specified for the CC3100/CC3200, and the
power down current should be added to the hibernate current. Check the operating voltage of the serial
flash and ensure it meets the overall system targets.

8.6 TX Output Power

The networking sub-system transmits with its maximum output power by default. The programmer may
reduce this parameter by setting a back off parameter using the sl_WlanSet API. This parameter defines
the additional back off (in dB) that the radio takes. If the user sets the value to four or above, the
networking sub-system radio switches to use a low power PA, and TX current is reduced significantly.
Note that the output power is reduced by the same factor to all rates. For example, a maximum output
power for 1 mbps is 18 dBm, and 14.5 dBm for 54 mbps. If the value is set to 4, the output power of 1
mbps is reduced to 14 dBm and the 54 mbps to 10.5 dBm. Therefore, if the user decides to reduce the
maximum output power to reduce overall power consumption, the transmission rate drops, the
transmission length is higher, and overall power consumption may increase.

8.7 CC3100 (Networking Subsystem) Current Consumption

The datasheet (SWAS031C) should be used as the main source of current consumption numbers.
Figure 3 is a reference for use case estimation.

8 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- SWRA462 – September 2014

system Power Management Submit Documentation Feedback
Copyright © 2014, Texas Instruments Incorporated
www.ti.com Low Power Design with CC3100/CC3200

Figure 3. CC3100 Current Consumption

The current numbers indicate that system peak current is dictated by calibration. Calibration may happen
occasionally (only during NWP initialization, and in case the temperature significantly changed, or 24
hours elapsed from the last calibration). Calibration adds around 200 ms to initialization. For a system that
enables the NWP once a minute, for example, the current consumption due to calibration occuring once a
day is negligible.

SWRA462 – September 2014 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- 9

Submit Documentation Feedback system Power Management
Copyright © 2014, Texas Instruments Incorporated
Low Power Design with CC3100/CC3200 www.ti.com

8.8 CC3200 Current Consumption

The datasheet (SWAS032E) should be used as the main source of current consumption numbers.
Figure 4 is a reference for use case estimation.

Figure 4. CC3200 Current Consumption

Comparing the CC3200 current consumption in different modes produces these conclusions:
• When the MCU is active and the networking sub-system is in sleep mode (or idle connected), the MCU
consumes ~15 mA. This reflects the consumption by the MCU while the device would otherwise have
been in LPDS mode.

10 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- SWRA462 – September 2014

system Power Management Submit Documentation Feedback
Copyright © 2014, Texas Instruments Incorporated
www.ti.com Low Power Design with CC3100/CC3200

• When the MCU is sleep and the networking sub-system is in LPDS mode (or idle connected), the MCU
consumes ~12 mA. This reflects the consumption by the MCU while the device would otherwise have
been in LPDS mode.
• When the MCU is active and the networking sub-system is in active mode (TX or RX), the MCU adds 6
mA. This reflects the consumption by the MCU while the device would have been in active mode due
to the networking sub-system activity.
• When the MCU is in sleep and the networking sub-system is in active mode (TX or RX), the MCU adds
3 mA. This reflects the consumption by the MCU while the device would have been in active mode due
to the networking sub-system activity.

8.9 Always Connected Current

Idle connected current is an important parameter, especially for always-connected systems. This is the
average current that the entire system consumes while connected to the access point without any traffic
exchange. The Wi-Fi uses the 802.11 power save to reduce its power and only receive beacons. While in
this mode, the networking sub-system is in LPDS mode most of the time. The Wi-Fi block wakes up to
receive a beacon, and goes back to sleep. If the beacon carries an indication that the AP holds a packet
for the device or an indication for a broadcast packet that follows the beacon, the system fully wakes up to
handle the traffic. By default, the Wi-Fi IP wakes up for every beacon according to the AP TBTT
parameter, and transmits a keep alive packet to the access point every 55 sec while in this mode.
As mentioned in Section 7, the networking sub-system introduces an advanced feature of (LSI) Long
Sleep Interval. In this mode the programmer sets the desired sleep time between beacons, understanding
that beacons are missed in between. Table 4 presents the expected average current consumption per
sleep interval.

Table 4. Expected Average Current Consumption Per Sleep Interval

Static IP Address Current DHCP IP Address Current
PM Mode Wakeup Interval Time [mSec]
[mA] [mA]
Default 102 0.690 0.725
LSI 204 0.419 0.484
LSI 510 0.284 0.314
LSI 1020 0.233 0.257
LSI 1530 0.208 0.233
LSI 2000 0.2 0.215

Notes:
• While working with DHCP, an additional 20 to 35 uA is consumed by the NWP.
• Serial flash current in standby mode is not included.
• 2 sec is the maximum allowed LSI.
• Tested in a clean environment
• Tested with Cisco 1250
• Measured at 3.3 V VBAT
• Measurements are based on an R1 SP1 device.
Referring to the default TBTT (102.4 ms), the CC3100 average current during idle connected period is
0.69 mA. This performance is a result of over of ten years of Wi-Fi experience. Note that this parameter
may vary between different access points. Some access points and networks send many broadcast
packets that force the networking sub-system to stay active longer. Some access points do not send their
beacons with exact timing, missing beacons and other phenomena. Networking sub-system algorithms try
to overcome many of the above phenomena, but the average current consumption may still vary.

SWRA462 – September 2014 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- 11

Submit Documentation Feedback system Power Management
Copyright © 2014, Texas Instruments Incorporated
Low Power Design with CC3100/CC3200 www.ti.com

8.10 NWP Initialization Time

This parameter is critical for several use cases that frequently enable and disable the networking sub-
system. For example, a system that spends most of the time in hibernate mode and every T min initiates a
connection to the cloud. Init time is measured from the point the NWP was enabled, using the sl_Start
command to the time the NWP asserts the IRQ line. This time may vary based on the following:
• Size of the service pack loaded from serial flash.
• Number of configurations stored in the serial flash. For example, connection profiles, static IP, MAC
address and so forth.
• Calibration adds around 200 ms to the NWP init time.
The typical initialization time for the NWP is 75 ms, with a charge of approximately 1700 uC @3.3 V
(measured on R1 SP1).

8.11 Wi-Fi Connection Charge

When using the fast connect feature (skipping the scan process), the networking sub-system automatically
connects to the access point. The charge that connection process consumes is an important parameter for
systems that are not in always-connected use case. Connection time and charge may vary significantly
from one access point to another, and can also vary within the same access point from one connection
attempt to another based on the access point load and activity.
The typical charge for WPA2 connection is 1000 uC to 2000 uC @3.3 V, and is highly depending on the
AP used. The following measurements were done on CC3100 device R1 SP1 and MSP430 host using
fast connect feature.

Table 5. Wi-Fi Connection Charge

AP WPA2 Connection Charge [uC]
Cisco 1250 1000
Netgear 3500 1400
TP-Link WR2041 1300

8.12 TCP and SSL/TLS Connection Charge

This parameter varies significantly from one server to another and according to the selected cypher suite.
The typical connection time and charge to a server that responds quickly are presented in .

Table 6. TCP and SSL/TLS Connection Charge

Cipher Suite Connection Charge [uC]
Open (non secure TCP) 3500
SSL/TLS (RSA RC4-128 MD5) 4500
SSL/TLS (RSA RC4-128 SHA) 4200
SSL/TLS (RSA AES-256 CBC SHA) 4000
SSL/TLS (DHE RSA AES-256 CBC SHA) 9700
TLS (ECDHE RSA RC4/AES SHA) 44500

Notes:
• A PC server was used for the measurement.
• Zero roundtrip delay time assumed. Larger roundtrip delay time increases the connection time
significantly. However, the charge per connection may remain closer to the specified result here since
most of the time increase is spent in power save mode.
• Measurements are taken on a R1 SP1 device.

12 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- SWRA462 – September 2014

system Power Management Submit Documentation Feedback
Copyright © 2014, Texas Instruments Incorporated
www.ti.com Low Power Design with CC3100/CC3200

8.13 Traffic Exchange Charge and Considerations

Application traffic patterns vary from one use case to another. From a power consumption perspective, the
characteristics of the traffic make a great difference.
While there is no traffic, the system is in idle connected mode. The system inspires to stay in low power
mode as long as possible, and every traffic event initiated by the host (TX) or by the AP (RX) takes the
system out of idle connected mode.
The overhead when waking the system for traffic and exiting 802.11 power save mode is not negligible.
Therefore, the amount of times the system wakes up for traffic should be minimized. Minimize the amount
of wakeups over the duration of each wakeup. For example, sending 10 packets as fast as possible is
much better than sending same packets with 30 ms delay between them.
The following guidelines improve overall power consumption:
• Use large packets.
• Concentrating traffic in bursts is better than uniform distribution of the traffic.
• If a system includes the server, than the server should also concentrate the traffic in bursts.
UDP TX is an exception to the above guidelines. If the use case requires transmission of a small amount
of packets at each time (up to 5), better results are achieved when delay between packets is greater than
50 ms.
Table 7 presents the average current consumption of TX/RX in UDP/TCP use cases when traffic is
transmitted and received as burst. The specified payload is transmitted or received as a burst, then the
device is in idle for the remaining time of the second. The process repeats every second.

Table 7. Av Current for TX/RX in Burst

UDP TCP
TP [mbps]
TX[mA] RX[mA] TX[mA] RX[mA]
0.1 5.8 5.6 6.5 6
0.5 9.1 8.05 9.5 10
1 13.5 11.5 14 15.5
2 22 18 22 26
3 30 24 31 36
5 46.5 36.5 47.5 57
12 105 80 107 94

Note:
• 1460B packet length
• Excellent link quality assumed
• Cisco 1250 AP
• Clean environment

9 Battery Powered System Considerations

For battery-operated systems, some considerations should be understood.

9.1 Minimum Operating Voltage

The CC3100/CC3200 specifies that the minimum operating voltage is 2.1 V. To ensure proper operation,
the battery voltage should always be above this threshold. Battery voltage tends to drop while the battery
discharges, according to battery specification and chemistry. The battery voltage also drops when a high
current is drawn from it, according to its internal resistance. Typical internal resistance for an AA battery is
1 ohm. Considering the TX current and the calibration peak current, the voltage drop can reach 400 mV
on alkaline batteries. Based on this system characteristic, the minimum operational for an AA battery is
2.5 V for 2AA on alkaline baterries.

SWRA462 – September 2014 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- 13

Submit Documentation Feedback system Power Management
Copyright © 2014, Texas Instruments Incorporated
Battery Powered System Considerations www.ti.com

9.2 Usable Battery Capacity

The usable battery capacity is the battery capacity that the battery supplies before the voltage drops below
2.5 V. It depends on the battery discharge characteristics. For Alkaline batteries (analysis is done using
Duracell MN1500 AA) the capacity increases as the average current drops. From Battery DS indicates the
following capacity while the voltage remains above 2.5 V:

Table 8. Battery Capacity

Average Current Capacity Above 2.5V
50 mA 1550 mAh
25 mA 1850 mAh
10 mA 1990 mAh
5 mA 2090 mAh

The trend is expected to continue down to an average current of 1 mA and below. The usable capacity for
an average current below 1 mA reaches 2200 mAh for this specific battery.
Lithium batteries have better internal resistance (analysis based on the Energizer L91) and their voltage
and service hours curve is more flat. This gives an advantage to lithium batteries, as almost the entire
capacity can be used. With the analyzed battery, more than 3000 mAh can be used.

14 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- SWRA462 – September 2014

system Power Management Submit Documentation Feedback
Copyright © 2014, Texas Instruments Incorporated
www.ti.com Example Test Cases

10 Example Test Cases

10.1 Intermittently Connected Test Case

A CC3100-based system must transmit 100B and check messages on the server every few minutes. In
this test case, the system initiates the communication and is not responsive at all times. Therefore, the
system can initiate a new connection on every cycle and does not have to keep connection. If the cycle
time is long enough, the system conserves more power if it switches to hibernate mode between
transactions, and re-connects to the AP and server every time rather than maintain the connection.
Inthis test case, the total energy per activity cycle is a summation of the following activities:
• E1 – Energy spent during system initialization.
• E2 - Energy spent during re-connecting to the AP (802.11 association and authentication).
• E3 - Energy spent while re-connecting to the server (IP layer and transport layer protocols per
application requirements).
• E4 - Energy spent during application traffic.
• E5 - Energy spent by the CC3100 device between cycles while in hibernate mode.

Figure 5. Test Case

In this test case, the application enables the CC3100 device, the device automatically re-connects to the
AP, the application opens and binds a socket, initiates traffic and disables the device. While the CC3100
device is enabled, it manages its power state according to a defined policy. For example, it may be in
LPDS state while waiting for a server response, or if the host delays between commands.
The total energy spent and system life span are given by:
E = £5n=1 En (1)
T = V × B/E × C × 1/400 (2)

SWRA462 – September 2014 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- 15

Submit Documentation Feedback system Power Management
Copyright © 2014, Texas Instruments Incorporated
Example Test Cases www.ti.com

Where:
• E – Total energy per cycle [joule]
• B – Battery capacity [mAh]
• C – Cycle time [min]
• V – Voltage [volts]
• T – Device life span [days]

10.1.1 Example
Energy
• C – (Activity period) = 2 min
• Typical average current draw over a single activity period:
– E1 – 1700 uC @ 3.3 V = 5.6 mJ
– E2 – 2000 uC @ 3.3 V = 6.6 mJ
– E3 – 4000 uC @ 3.3 V = 13.2 mJ
– E4 – 5000 uC @ 3.3 V = 16.5 mJ
– E5 – 600 uC @ 3.3 V = 2 mJ
– ETotal – 44 mJ
– Average Current – 111 uA
Battery – 2AA alkaline battery rated at 1.5 V, each connected in series with capacity of 2000 mAh:
• B = 2000 mAh
• V = 3.0 V
T (device lifespan) = 3 x 2000 x 2 / 0.044 / 400 = 681 days

10.2 Always-Connected Test Case

In this test case, the application requires that the system maintain its connection. The system must stay
online and respond to notifications within certain latency (a few seconds). The traffic itself is scarce and
most of the time the system is idle. For example, a server waiting for clients to connect or a client
constantly connected to a cloud server. In this case, the host enables the NWP once and initiates a
connection to the AP. As long as there is no activity in the system, the system is in the lowest possible
mode (using the 802.11 power save protocol to handle low power at the link layer). The system manages
the following activities:
• Wakeup for beacons to check if an incoming traffic exists at AP buffers
• Upon indication of incoming traffic, the system exits low power mode, receives the traffic and transfers
to the host if necessary, according to configured filters.
• Manages keep alive handshake with the AP to maintain a connection.
The average energy consumed by the system is a summation of the following activities:
• E1 – Energy spent for connection maintenance
• E2 – Energy spent during application traffic

16 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- SWRA462 – September 2014

system Power Management Submit Documentation Feedback
Copyright © 2014, Texas Instruments Incorporated
www.ti.com Example Test Cases

Figure 6. Test Case

The total energy spent and the system life span is given by:
T = B × V / W1 + E2 / P2 (1 / 1000 × 24) days (3)
Where:
• B – Battery capacity [mAh]
• V – Voltage [volts]
• P2 – Period cycle for application traffic activity [sec]
• W1 – Power consumed during idle connection time [Watt].
• E2 - Energy spent during application traffic [Joule]
Energy spent during the initial phase of device initialization and connection establishment can be
neglected, since this is a one-time event.

10.2.1 Example
Energy
• P2 = 60 sec
• W1 = 233 uA x 3.0 V = 0.0007 W (assuming a long sleep interval of 1 sec)
• E2 = 25 mA x 200 msec x 3.0 V = 15 mJ (assuming part of the 200 ms is at RX current, very short time
at TX current, and part in LPDS current resulting in 25 mA average over the 200 ms)
Battery – 2AA alkaline battery rated at 1.5 V, each connected in series with a capacity of 2000 mAh:
• B = 2000 mAh
• V = 3.0 V
T (device lifespan) = 2000 x 3.0 / (0.0007 +0.015/60) / (1000 x 24) =~ 263 days

SWRA462 – September 2014 SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip™ Networking Sub- 17

Submit Documentation Feedback system Power Management
Copyright © 2014, Texas Instruments Incorporated
 IMPORTANT NOTICE

Texas Instruments Incorporated and its subsidiaries (TI) reserve the right to make corrections, enhancements, improvements and other
changes to its semiconductor products and services per JESD46, latest issue, and to discontinue any product or service per JESD48, latest
issue. Buyers should obtain the latest relevant information before placing orders and should verify that such information is current and
complete. All semiconductor products (also referred to herein as “components”) are sold subject to TI’s terms and conditions of sale
supplied at the time of order acknowledgment.
TI warrants performance of its components to the specifications applicable at the time of sale, in accordance with the warranty in TI’s terms
and conditions of sale of semiconductor products. Testing and other quality control techniques are used to the extent TI deems necessary
to support this warranty. Except where mandated by applicable law, testing of all parameters of each component is not necessarily
performed.
TI assumes no liability for applications assistance or the design of Buyers’ products. Buyers are responsible for their products and
applications using TI components. To minimize the risks associated with Buyers’ products and applications, Buyers should provide
adequate design and operating safeguards.
TI does not warrant or represent that any license, either express or implied, is granted under any patent right, copyright, mask work right, or
other intellectual property right relating to any combination, machine, or process in which TI components or services are used. Information
published by TI regarding third-party products or services does not constitute a license to use such products or services or a warranty or
endorsement thereof. Use of such information may require a license from a third party under the patents or other intellectual property of the
third party, or a license from TI under the patents or other intellectual property of TI.
Reproduction of significant portions of TI information in TI data books or data sheets is permissible only if reproduction is without alteration
and is accompanied by all associated warranties, conditions, limitations, and notices. TI is not responsible or liable for such altered
documentation. Information of third parties may be subject to additional restrictions.
Resale of TI components or services with statements different from or beyond the parameters stated by TI for that component or service
voids all express and any implied warranties for the associated TI component or service and is an unfair and deceptive business practice.
TI is not responsible or liable for any such statements.
Buyer acknowledges and agrees that it is solely responsible for compliance with all legal, regulatory and safety-related requirements
concerning its products, and any use of TI components in its applications, notwithstanding any applications-related information or support
that may be provided by TI. Buyer represents and agrees that it has all the necessary expertise to create and implement safeguards which
anticipate dangerous consequences of failures, monitor failures and their consequences, lessen the likelihood of failures that might cause
harm and take appropriate remedial actions. Buyer will fully indemnify TI and its representatives against any damages arising out of the use
of any TI components in safety-critical applications.
In some cases, TI components may be promoted specifically to facilitate safety-related applications. With such components, TI’s goal is to
help enable customers to design and create their own end-product solutions that meet applicable functional safety standards and
requirements. Nonetheless, such components are subject to these terms.
No TI components are authorized for use in FDA Class III (or similar life-critical medical equipment) unless authorized officers of the parties
have executed a special agreement specifically governing such use.
Only those TI components which TI has specifically designated as military grade or “enhanced plastic” are designed and intended for use in
military/aerospace applications or environments. Buyer acknowledges and agrees that any military or aerospace use of TI components
which have not been so designated is solely at the Buyer's risk, and that Buyer is solely responsible for compliance with all legal and
regulatory requirements in connection with such use.
TI has specifically designated certain components as meeting ISO/TS16949 requirements, mainly for automotive use. In any case of use of
non-designated products, TI will not be responsible for any failure to meet ISO/TS16949.

Products Applications
Audio www.ti.com/audio Automotive and Transportation www.ti.com/automotive
Amplifiers amplifier.ti.com Communications and Telecom www.ti.com/communications
Data Converters dataconverter.ti.com Computers and Peripherals www.ti.com/computers
DLP® Products www.dlp.com Consumer Electronics www.ti.com/consumer-apps
DSP dsp.ti.com Energy and Lighting www.ti.com/energy
Clocks and Timers www.ti.com/clocks Industrial www.ti.com/industrial
Interface interface.ti.com Medical www.ti.com/medical
Logic logic.ti.com Security www.ti.com/security
Power Mgmt power.ti.com Space, Avionics and Defense www.ti.com/space-avionics-defense
Microcontrollers microcontroller.ti.com Video and Imaging www.ti.com/video
RFID www.ti-rfid.com
OMAP Applications Processors www.ti.com/omap TI E2E Community e2e.ti.com
Wireless Connectivity www.ti.com/wirelessconnectivity

Mailing Address: Texas Instruments, Post Office Box 655303, Dallas, Texas 75265
Copyright © 2015, Texas Instruments Incorporated