How Low Can You Go with “Low-Power Wireless”?

Thu, 09/02/2010 - 4:49am
Ross Sabolcik, Director of Marketing, Wireless Products, Silicon Labs (

Ross SabolcikOne thing I’ve learned over the years in the semiconductor industry is that I really don’t know anything. Or rather, what I think I know is always changing or isn’t quite what I thought it was. Indulge me while I explain.

Before working in the industrial-scientific-medical (ISM) wireless market, I was a member of the broadcast products group at Silicon Labs. We designed a family of AM/FM receivers for the portable market (MP3 players, cell phones, etc.), and low power operation was a key product feature. Our first generation of receivers consumed 18 mA of current in receive mode. The products offered excellent sensitivity, blocking performance and battery life. We thought 18 mA was pretty darn low, and at the time it was. We had a very successful product on our hands, but customers wanted something more – or rather less. They wanted less current consumption than 18 mA. But how much less?

We heard rumors of a part with 9 mA of current consumption. Back then, 9 mA was an insanely low number. How could anyone achieve 9 mA? We got our hands on the product and tested it. It indeed did achieve 9 mA, and it worked – but barely. The performance of the radio was significantly reduced. It overloaded in the presence of blockers, almost any blocker would do, and it had awful intermodulation performance. You could tune station 101.5 MHz at four different frequencies due to image rejection and intermod products. Overall it was not a very good radio. But it truly did draw 9 mA.

So which radio was really low power – our 18mA solution or the 9 mA solution?

My answer: Both were low power. For customers who really cared about the performance of the radio in their product, the 9 mA radio was unusable. Regardless how low the current consumption was, it wasn’t a viable solution. For these customers, our 18 mA radio was indeed low power. It provided the lowest current solution that delivered the required performance. Some customers, however, saw the radio as a check-box item in their solution and only cared about how long the battery lasted regardless of how poorly the radio performed. For these customers, that 9 mA spec was all that mattered, and nothing else was low current.

So what is the definition of low-power? The true definition of low power, as I see it, depends on a performance / current consumption metric rather than a simple current consumption number. Our radio, though consuming higher current, offered a vastly superior performance to current ratio, and most customers agreed.

Fast forward several years. Silicon Labs’ latest generation of AM/FM tuners still offers exceptional performance – like our first generation – but with only 13 mA of current consumption. Clearly, the performance / current consumption metric for Silicon Labs newest AM/FM tuners has significantly improved. So is this the only figure of merit that matters for a radio: performance versus active mode current consumption?

These days I worry about the ISM wireless space. All of the things I thought I knew about low power from an FM tuner perspective are clearly applicable in my market. Or so I thought. It turns out that the low-power requirements for an FM tuner in a media player or cell phone are very different from those in a battery-powered water meter or home security system.

Consider an FM tuner in a cell phone. The end user turns on the radio and wants to listen to some music while waiting for the train. The radio stays on for minutes or hours at a time. Whether it take 500 mS for the radio to wake up and start playing music really doesn’t impact the user experience or battery life. Once the user is finished listening, he turns off the radio and jumps on the train. When he gets home, he charges his cell phone and has a full charge ready to go the next day. Battery life is measured in hours of active mode time.

Now consider a battery-powered water meter. You never charge the battery, and changing it is a major truck-roll cost and inconvenience for the utility. Customers expect battery life of 15-20 years. The meter wakes up a few times a day to send a very short packet of information back to a collector node. The radio will be asleep for well over 99 percent of the day and is only active for a very short period of time. What’s important in this type of application is how much current the radio consumes while it is idle and how quickly it can go from the idle mode state to the active mode state (since power consumed waking up the radio is “wasted” as no information is sent or received during this time).

That’s a really bizarre concept to get your brain wrapped around; your performance when you aren’t doing anything is more important than when you are actively working. (If only other aspects of our lives worked that way as well) So with these types of radios, you really need to work hard to optimize your leakage when in sleep mode, your startup times for your VCO and synthesizer, and focus on a host of other parameters that just don’t matter in many other wireless systems. Don’t get me wrong. Active mode current still does matter in these systems. It’s just that it isn’t the only thing that matters.

Consider another example – an “asynchronous” wireless system. Assume that the smart water meter must listen for a command to send data back to the collector. Also assume that it is really difficult to precisely synchronize the transmitter and receiver to wake up at exactly the same time. In this case the radio needs to periodically wake up, quickly determine if there is a command it needs to respond to, and then turn around and send the data to the collector.

The receive portion of this protocol, listening for the command, makes the situation even more complicated. The receiver needs to wake up quickly, just like the transmit case, but now it needs to acquire the incoming signal, lock to the carrier, acquire the bit clock, train the modem, receive the packet, and then parse the packet as quickly as possible to determine if there is a valid command. All of this must occur as quickly as possible, but since the incoming message is asynchronous, the receiver can wake up in the middle of the incoming packet, before the start of the packet or after the packet is sent. This situation creates a host of system issues that need to be addressed beyond the parameters of the radio itself to ensure acceptable performance. So here we go relearning the whole concept of what it means to be low-power and how to optimize a radio and a system to achieve maximum battery life.

To make matters even more complicated, let’s add an MCU to the equation. The partitioning between the MCU and the radio can have a major impact on the battery life of the system. Advanced radios can do much of the system’s work while the MCU remains in a low-power sleep mode. Radios can automatically wake themselves up, verify that the packet is present and valid and (only if the packet is valid) wake the external MCU. Like the radio, the MCU also must be designed for low active mode and standby currents. The overall interaction between the MCU and radio along with the system architecture determines the system battery life.

When designing a low-power wireless system, you need to consider both the radio and MCU and choose optimized versions of each. When I speak with my MCU counterparts in the industry, we’re always striving to find ways to create a more optimized partitioning of features between the MCU and the radio to squeeze out every possible milliamp of battery savings. These optimizations can make a huge difference between hitting the customer’s battery life requirement or falling short.

So there you have it: all low-power wireless systems are essentially the same. But when you peer under the application hood and factor in the customer’s care-abouts, all low-power wireless systems are really quite different.

That’s my understanding of low-power wireless – until some new application or customer requirement comes along that changes everything I thought to be true.


Share this Story

You may login with either your assigned username or your e-mail address.
The password field is case sensitive.