What factors to consider when selecting an integrated wifi MCU for a low powered edge device?

Question

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?

References:

• SimpleLink™ CC3100/CC3200 Wi-Fi Internet-on-a-chip Networking Sub-system Power Management
• How to Select your Wi-Fi Module?

Answer 1

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.

Answer 2

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?

Answer 3

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.

Answer 4

Despite this question is pretty old, it still lacks one very important thing:

If it is legal to use in the specific country.

Since EU regulations are more lax than FCC, most MCUs are not legally allowed to be used in e.g. US/Canada and similar countries, without the design being certified by FCC.

Design choices such as antenna gain, filter attenuation, max possible transmission power etc., all affect if the design will fulfill the requirements of allowed channel use, max allowed transmission power, out-of-channel and out-of-band spurious transmissions etc.

For example, ESP32 is by default configured to transmit with maximum possible transmission power, way above allowed by both FCC and ETSI (EU).

Hence, it is in most cases best to avoid looking at a specifik MCU, but to consider using a pre-certified module with manufacturer-approved antennas.