The motivation for this question comes from the fact that some time ago I created a simple proof of concept (PoC) IoT edge device using a microcontroller and a CC3100 Wifi network processor. One of the problems with this prototype was that the configuration required a considerable amount power. Thus, it could not overcome the benefits of the existing lower power device which could last for over 2 to 10 years depending on choice of battery and usage frequency.

Depending on the application, the current product uses a 6V DC battery with a capacity between 1400 mAh and 2400 mAh. The device has a low power sensing element and an actuating mechanism. The payload most likely will be around 100 bytes. The frequency of communication will be about every two minutes during peak activity. With the advances in the IoT and market demands, this PoC has gained some attention.

Per the suggestion of few IOT platform providers I am looking at CC3200 wireless MCU from Texas Instrument primarily because it is the successor to the CC3100. At a system level when not in use the CC3100 power can be completely switched off. This is a significant advantage for low power at a systems level. When activity is detected the sensing element wakes up the microcontroller via an interrupt. There are other integrated wifi MCU’s such as ESP8266, BCM43362, ATWINC1500B, 88MC200 and many more. I use ULPBench Scores to do a first order analysis of low power microcontrollers followed by analysis such as described in How to select a micro controller for a low power application? to help select a low power microcontroller. I have used parameters such as active mode current draw per frequency, and current draw a different low power modes to make an informed selection. So in order to maintain the low power option and to add IoT capability, what are critical parameters (may related to wireless communication) that I should I pay close attention to when selecting an integrated wifi MCU?


  • 3
    I am not sure if I understand right, what components are you referring to (given that the CC3200 consists of Applications Microcontroller, Wi-Fi Network Processor, and Power-Management Subsystems - it seems to already include most that you need). – Ghanima Dec 11 '16 at 23:27
  • 1
    @Ghanima, Tektronix has a How to Select your Wi-Fi Module? guide. Are there any how to select Integrated Wifi module guide. I could find any. Other vendors have integrated wifi modules, At the time of writing I have not researched the CC3200. The benefit of being part of this community is to bounce questions and learn of each other experiences. So in short, What make A better over B for IOT applications for a low power IOT application. Is there something better than wifi, example sigfox or lora? – Mahendra Gunawardena Dec 12 '16 at 11:38
  • 3
    This seems too general to me. As a test, how would we identify a good answer from the possible ways to answer this question? – Sean Houlihane Dec 12 '16 at 16:57
  • 2
    I've read your question several times and I still don't understand what you're asking about. Your user story is fine, but which part of the setup are you asking about? All you talk about in your question is low power consumption, so what “critical parameters” are you after other than low power consumption? I'm sure there's a good question lurking here, but half of it is still only in your head. – Gilles Dec 12 '16 at 21:22
  • 2
    Is energy per instruction relevant for your use case? With the information in your question, that's not clear at all. If you don't do much computation then it could be dwarfed by power on idle and especially by the radio. – Gilles Dec 13 '16 at 10:45

As your most important constraint is having a low power consumption, I think you are already paying attention to the 2 most important parameters: active mode current draw per frequency, and current draw at the different low power modes.

Holding the communication as a constant (i.e. same communication protocol and EM frequency), then choosing the best MCU is just a matter of aggregating those two parameters properly. And here's how I would create a single numeric value I could compare across all options:

  1. Create a projected activity profile for the device (how often does it communicate and for how long) over a period - say over a week.
  2. Compute the current draw at the EM frequency used for the times over the selected period when communication is active - i.e. 10 uA draw (@ 900 MHz frequency) for a 2 s duration at 1000 x activity in a week would mean 20,000 uA-s / week.
  3. Compute the current draw for the times over the selected period when the device is at its default low power mode - i.e. 10 nA draw at [7 days x 24 hrs x 60 mins x 60 s - 1000 x 2 s activity] would mean 6,028 uA-s / week.
  4. Adding the 2 yields 26,028 uA-s / week current draw for this hypothetical MCU.
  5. This computed weekly current draw can then be compared for all MCUs.

I know this is a very simplistic way of viewing the MCU activity - i.e. just considered 2 states: idle and communicating... but I believe any other states will have proportional and minor contributions to one of these 2. For instance, power used up for computations (instruction cycles) can be bundled along with the communicating state and will most likely have a very small contribution in terms of power as compared to the communication sub-system. The point is that, looking at these 2 states is sufficient for the selection process.


There's no magic bullet, so I think the advice will be painfully obvious. Start chipping away at the biggest power consumers first.

Are you truly powering off all the chips and circuits when it's idle? I know some of the hobbyist boards and shields don't always completely turn off everything you'd expect.

If it's the actuator, can you use a lighter powered motor, or reduce friction in the drive train? Bigger picture, can you re-engineer the driven load to have less mass, or to be better balanced?

If it's the communication, start by looking at the frequency of communications. What factors drove the existing "two minute" decision? Can you make sacrifices to communicate less often? Can you switch to a pub-sub model, and respond with fewer bytes when conditions permit?

Reevaluate the protocol. Every byte you shave represents a savings of 1% of your current RF power budget. Sending any Boolean values? Use bit flags, not an ASCII 'Y' or 'N'. Make sure you're using the smallest possible container - don't transmit a 16-bit integer if the number has a permissible range of only 0-99. Most battery powered protocols try to squeeze it down as far as possible; e.g. if you're reporting on a 5x5 array of elements, the address only needs to be a 5-bit field, not an 8-bit byte. Using CPU cycles for compression-related logic results in a much lower overall power draw than transmitting unneeded bits.

If the big power draw is the CPU (doubtful, but possible) can you do tricks like precomputed lookup tables, or even offload some of the work to a remote service?


There is no single definitive set of parameters which you can use to select an integrated device like this, but I think as a first approximation, newly designed devices might be significantly better than something from a couple of years ago. Although the concept is not new, this level of integration, and the aggressive power targets make this an evolving market.

Pay close attention to the power states which are offered, viewed from the perspective of your whole system (regulators, oscilators, sensor signal conditioning). It is possible (unlikely) that your 2 min active state will benefit from a less deep sleep than the normal operating state.

The lowest power useful state should account for the majority of your energy consumption. Exactly how this pans out for you depends on things like if you can operate directly off power without a regulator, minimum operating voltage, etc.

For the active state, consider your most RAM or compute intensive operations and benchmark them using the nearest equivalent off-the-shelf parts you can find (based on CPU, speed and memory architecture). In your application it seems that preparing the payload and encryption may be fairly trivial, but in general this isn't an obvious assumption. Retention states might permit sensor integration without state save/restore for example.

Match the clock speed and architecture to the demands of your application. In sleep state, you save leakage power. Lower target clock speeds for a device may mean it needs to remain in an active state for longer, but also result in a design achieving better leakage performance (as well as maybe lower operating voltage).

You won't know the absolute best design until you have iterated more than one design - there are just too many parameters (and by this time, your product will be starting to get old), so higher level aspects of the design flow are still important. If you can optimise your architecture to reduce wake events by 5%, this should be noticeable in battery life.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.