Power Management in Multi-Radio Devices
A product can pass every test in the lab and still fail in a customer’s hands, for a reason that has nothing to do with bad code, bad luck, or a faulty chip. It happens more often than most engineering teams realize, and almost every time, the real cause turns out to be the same thing.
Picture a device that runs Bluetooth, Wi-Fi, and an AI model, all built into one chip. In the lab, each of these was tested on its own, and each one performed exactly as the datasheet promised. The product shipped. Then customers started reporting dropped connections, batteries draining faster than expected, and the occasional unexplained reset.
Nobody could reproduce it reliably. The hardware checked out fine every time it was inspected. The firmware passed every review. And yet, in the field, the product simply did not behave the way it had in the lab.
Here is what was actually happening. Bluetooth, Wi-Fi, and the AI model were each managing their own power independently, the way radios have always done. Each one woke up, did its job, and went back to sleep, entirely on its own schedule, with no idea what the other two were doing at the same moment.
Most of the time, that was fine. But often, all three would wake up within the same few milliseconds, drawing power from the same shared battery supply at the same instant. When that happened, the battery couldn’t quite keep up, and the voltage dipped just enough to cause a dropped packet, a missed connection, or a reset that looked, from the outside, like it came from nowhere.
That is the entire problem, in one sentence: nobody had told the three of them to take turns.
Why This Never Used to Matter
A few years ago, this simply wasn’t an issue, because it wasn’t physically possible for it to be one. Wireless radios and AI processing usually lived on separate chips, each with its own power supply, completely unaware of the other’s existence. If one drew a spike of current, it had no effect on the other, because they weren’t sharing anything.
That has changed. Modern chips now combine Wi-Fi, Bluetooth, sometimes Thread or Zigbee as well, and a dedicated AI processor, typically an NPU, or Neural Processing Unit, built specifically to run AI models efficiently, all on a single piece of silicon.
Each part of that chip still has its own settings for when to sleep and when to wake, but all of them draw from the same underlying power supply. What looks, on a spec sheet, like several independent components is, in practice, one shared electrical system with several tenants who don’t talk to each other.
That is the shift that created this problem, and it has happened recently across almost every category of connected product.
The Number Most Teams Have Backward
Most people think the AI Model is the power hog. It may be the memory hog, but it is not the power hog people think. Here is something worth knowing before going further, because it changes where the real risk actually sits.
Engineering teams may assume the AI model is the power-hungry part of the system, since it is the newest and most computationally demanding piece. It usually is not. An analysis compared how much power each part of a typical device draws:
a) Running the AI model, on average: 10 to 100 microwatts
b) Sending a single Bluetooth transmission: 10 to 50 milliwatts, up to 5000 times more than the AI model
c) Sending a single Wi-Fi transmission: 200 to 1000 milliwatts or more, up to a million times more than the AI model
The radios, not the AI, are where almost all of the power goes. Which means a team that spends weeks trimming the AI model to save power is optimising the smallest number on the board, while the two components that actually drive battery life keep operating with no coordination between them at all.
Why This Is Getting More Common
If this were a rare edge case, it might not be worth an article. It isn’t rare, and it’s becoming common every year.
Chip makers are racing to put more of these components on a single die, because customers want smaller, cheaper, more capable products. One of our semiconductor partners, Synaptics, recently launched a chip that combines Wi-Fi, Bluetooth, and a dedicated AI processor on a single piece of silicon.
Another partner, NXP, has done something similar, pairing its processors with dedicated AI accelerators on the same chip. Every one of these announcements makes the underlying problem more common, because every one of them puts more shared tenants on the same electrical supply.
The chip makers can build better individual components. They cannot decide, from inside the silicon, whether a Wi-Fi transmission should wait two milliseconds for a Bluetooth connection to finish first. That decision has to be made by whoever builds the product, in software, because no chip on the market makes that call on its own.
Luckily, we have the privileged relationships to get our grubby little mits on these chips before the general public, so we can figure out the power management well in advance.
What This Actually Costs
None of this shows up as a line item on a project budget. It shows up later, and it costs more the later it shows up.
i) It shows up as customer reviews complaining about battery life that doesn’t live up to marketing claims.
ii) It shows up as support tickets for dropped connections that engineering can never quite reproduce.
iii) It shows up as weeks, sometimes months, spent investigating a hardware issue that keeps mysteriously vanishing the moment a debugging tool gets attached, because the failure only happens under exact, unrepeatable timing conditions.
iv) And in the worst case, it shows up as an emergency firmware update, built under real pressure, months after launch, to fix a problem that a single design review would have caught before the product ever shipped.
Every one of those costs traces back to the same missing piece: nobody on the team ever decided who gets to draw power, and when.
What Fixing This Looks Like
The good news is that fixing this does not require new hardware, a redesigned board, or a more expensive chip. It requires one thing: a single policy, written once, owned by one team, that governs how every radio and the AI model share power across the whole product, rather than each one deciding for itself.
In most embedded systems, there is already a natural place for this policy to live: the software that schedules everything else the chip does. That scheduler already knows what is running and when. Teams simply need to extend it to also decide who gets power and when, instead of leaving that decision to each component individually. Zephyr, one of the most widely used platforms for this kind of work, already has the tools built in for exactly this. Many products never take advantage of those capabilities.
The most advanced version of this doesn’t just react after something asks for power. It predicts what is about to happen, based on the patterns it has already seen, and starts preparing power slightly before the request lands, rather than scrambling after it arrives. That single habit, planning ahead instead of reacting, is quietly becoming the difference between products that behave consistently and products that don’t.
Questions Worth Asking Right Now
Before your next product goes into production, put these questions to your team:
1. Is there one policy deciding how every radio and the AI model share power, or is it a free-for-all?
2. Was the power budget ever tested with all of them running at the same time, or only tested one at a time on a clean bench?
3. Do you actually know which part of the product is drawing the most power in real customer use, or is that still a guess based on the datasheet?
4. And who owns this decision today, checking that it still holds up every time the firmware changes?
If any of those answers come back uncertain, the gap already exists in your product. It is far cheaper to close now than after a customer finds it for you.
The Bottom Line
The chip makers keep building better individual radios, faster processors, and more efficient AI accelerators. None of that solves this problem, because the problem was never about any single component.
It is about whether anyone stipulated how those components share the one thing they all depend on. That decision does not belong to the chip. It belongs to the team building the product.
At embedUR, we help engineering teams design, validate, and optimize multi-radio, AI-enabled products, so they behave the same way in the field as they do on the bench.
If your product is heading toward launch, or if you’re trying to understand why a finished design behaves differently in customers’ hands than it did in your lab, talk to our engineering team. We can help you find these gaps before they turn into field failures.
If you enjoyed this post, make sure you catch the next related article also on multi-radio systems: Antenna Placement and Isolation in Multi-Radio Embedded Systems.