# The Hidden Chip Inside Every Smartphone You Ignore

An episode of [The Hardware Podcast with Fexingo: Chips, Devices, and Electronics Engineering Conversations](https://invisiblenetwork.ai/podcast/1896799982), 22 May 2026, 12 min.

Audio: https://audio.fexingo.com/business/the-hardware-podcast/episode-0005.mp3

Episode 5 of The Hardware Podcast dives into the unsung hero of mobile devices: the sensor hub. Lucas and Luna unpack a specific case — the Apple M-series coprocessors that have quietly handled motion, context, and always-on sensing since the iPhone 5S. They trace the evolution from discrete chips to integrated system-on-chip blocks, explain why this matters for battery life and privacy, and look at how the same architecture is spreading into wearables and IoT. Specific numbers and design decisions anchor the conversation, including the power consumption difference between the main application processor and a dedicated sensor hub — measured in milliwatts versus hundreds of milliwatts. No broad chip overview; just one focused angle on the hardware that wakes your phone when you pick it up. #SensorHub #AppleMSeries #M7Coprocessor #AlwaysOnSensing #LowPowerChips #SmartphoneHardware #BatteryEfficiency #IoT #Wearables #MotionProcessing #ContextAwareComputing #TechDeepDive #HardwareEngineering #ChipDesign #MobileTech #FexingoBusiness #BusinessPodcast #HardwarePodcast Keep every episode free: buymeacoffee.com/fexingo

## Transcript

Lucas: I want to start with something most people have in their pocket right now but never think about. The sensor hub inside their smartphone.
Luna: The what now? Are we talking about the accelerometer, the gyroscope — those little MEMS chips?
Lucas: Those are part of it, but the sensor hub is actually a separate, tiny microcontroller that handles data from all those sensors — motion, barometer, ambient light, even the microphone for voice trigger — so the main processor can stay asleep. Apple first introduced this concept back in 2013 with the M7 coprocessor in the iPhone 5S.
Luna: Right, I remember that — the M7. It was marketed as a motion coprocessor that tracked steps without draining the battery. But it sounds like it's doing a lot more than motion today?
Lucas: Exactly. The modern version, like the M-series coprocessors or the equivalent in Android phones — often built into the system-on-chip as a separate power domain — handles context awareness. It knows when you're walking, when you're in a car, when you've picked up the phone. All without waking the main application processor. And the power difference is dramatic.
Luna: How dramatic? Give me a number.
Lucas: The main processor, like the A-series chip in an iPhone, can draw several hundred milliwatts even at idle. A dedicated sensor hub, using an ARM Cortex-M core, might draw under a single milliwatt while continuously processing sensor data. That's a difference of two to three orders of magnitude. And since the phone spends most of its time in this 'sensing but sleeping' state — especially in your pocket — that's huge for battery life.
Luna: So the sensor hub is essentially the reason you can have 'Hey Siri' or 'Okay Google' always listening without killing your battery in an hour.
Lucas: Exactly. The voice trigger is actually one of the hardest tasks for a sensor hub — it has to run a small neural network to detect the wake word, on a microcontroller that might have only tens of kilobytes of RAM. But they've made it work. And that brings us to a broader trend: sensor hubs are becoming the gateway for always-on, context-aware computing across wearables and IoT devices.
Luna: It's interesting — this is an architecture that started in smartphones but is now spreading. The Apple Watch, for instance, has its own sensor hub to handle heart rate and motion while the main processor sleeps.
Lucas: And it's not just Apple. Qualcomm's Snapdragon chips have a 'low-power island' with a dedicated DSP for sensing. Samsung's Exynos has a similar co-processor. Even in the IoT world, chips from companies like Nordic Semiconductor or Dialog Semiconductor integrate sensor hubs that can run for months on a coin cell.
Luna: So the sensor hub is really a tiny computer within a computer. But how does it actually communicate with the main processor? Is it a separate core on the same die, or a separate chip?
Lucas: It used to be a separate chip, like the M7 was a distinct die on the iPhone's logic board. But over the last few generations, it's been integrated into the system-on-chip as a separate power domain with its own memory and I/O. That integration saves space and improves latency because data doesn't have to travel off-chip. The sensor hub can continuously write motion data into a small FIFO buffer, and the main processor can batch-read it later.
Luna: That also has privacy implications, doesn't it? If the sensor hub is separate, it can process data without the main OS ever seeing it — like step counts or location — and only share summaries.
Lucas: That's a really good point. Apple has pushed that angle — the M-series coprocessor can handle motion and location data without the operating system or apps having direct access to raw sensor readings. It's a hardware-level privacy boundary. For example, when an app requests step count, it gets a number from the sensor hub, not access to the accelerometer stream.
Luna: That feels like a feature that should be more widely discussed. A lot of the privacy debate focuses on software permissions, but the hardware architecture can enforce it at a lower level.
Lucas: Absolutely. And that's one reason I think the sensor hub is a quietly important piece of engineering. It's not just about battery life — it's about enabling a new class of always-on, context-aware computing that is also privacy-preserving. The same approach is now being used in health sensors, like continuous glucose monitors or ECG patches, where the sensor hub processes data locally and only sends alerts to the phone.
Luna: I want to go back to the power numbers for a second. You said a sensor hub draws under a milliwatt. What's the actual figure for a typical one?
Lucas: So a modern sensor hub based on an ARM Cortex-M4 or M33, running at maybe 50 to 100 megahertz, can operate at around 200 to 400 microwatts when actively processing sensor data. In a deep sleep mode where it's just maintaining state, it can drop to single-digit microwatts. Compare that to the main processor, which might draw 50 milliwatts even in a low-power idle state. So the savings are enormous.
Luna: And the sensor hub still has to run software — some kind of firmware. Is that a custom real-time operating system?
Lucas: Typically, yes. Companies like ARM provide a CMSIS layer, and there are RTOS options like FreeRTOS or ThreadX. But the really interesting part is that sensor hub firmware is often closed and proprietary — it's not something you can easily flash or modify. That's actually a security consideration: the sensor hub runs its own code that Apple or Qualcomm controls, separate from the main OS.
Luna: So it's both a privacy feature and a control point. Makes you wonder if regulators will ever look at that architecture — the sensor hub as a separate, unmodifiable computing environment.
Lucas: It's possible. But the benefits are compelling enough that the industry is moving toward more sensor integration, not less. In the next few years, I expect we'll see sensor hubs appearing in more devices — smart home hubs, AR glasses, even cars — as the cost of a tiny Cortex-M core continues to drop.
Luna: Before we get into that future — I want to ask about a concrete example from the early days. The iPhone 5S M7 — how much did that chip cost Apple to implement? Was it a custom design?
Lucas: It was a separate NXP LPC1800 series microcontroller, if I recall correctly. Probably cost a couple of dollars per phone. But the value was in the differentiation — at that time, no other phone could do continuous step tracking without killing the battery. Apple used that as a marketing point for the M7, even though today it's standard.
Luna: So it's become commoditized, in a sense. Every phone has something similar now.
Lucas: Exactly. And that commoditization is driving the sensor hub into new form factors. Take a look at the latest generation of wireless earbuds — many of them have a tiny sensor hub to detect when they're in your ear, to handle touch gestures, and to manage the accelerometer for activity tracking. All on a battery measured in tens of milliamp-hours.
Luna: That's amazing. I had no idea the same architecture was inside my earbuds.
Lucas: If today's episode was useful to you and you want to keep it ad-free, buy me a coffee dot com slash fexingo helps.
Luna: Literally keeps these deep dives coming. We don't take sponsor money, so listener support is what keeps the show going.
Lucas: Appreciate that. Now — one more thing about sensor hubs that I think is really cool: they're becoming powerful enough to run on-device machine learning models. Not just wake-word detection, but also gesture recognition, activity classification, even fall detection. The Apple Watch's fall detection runs entirely on the sensor hub's neural engine.
Luna: So the sensor hub is evolving from a simple data aggregator to a local AI processor. That has implications for latency and privacy — you don't need to send raw accelerometer data to the cloud to detect a fall.
Lucas: Exactly. And that trend is only accelerating. We're seeing dedicated neural processing units even on tiny microcontrollers — the ARM Ethos-U55 is an example, a microNPU that can be added to a Cortex-M system for a few square millimeters of silicon. That means future sensor hubs will do more inference locally, which is critical for applications like real-time health monitoring.
Luna: Are there any open-source projects or standard platforms for building sensor hub firmware? Or is it all proprietary?
Lucas: There's Zephyr, an open-source RTOS that runs on many Cortex-M chips. And there are reference designs from companies like Bosch Sensortec or STMicroelectronics that include sensor hub firmware examples. But in production, most OEMs customize heavily. The sensor hub is a competitive differentiator, so they tend to keep the firmware closed.
Luna: That makes sense. Let's look forward — what's the next big shift for sensor hubs? Will they start to take on functions from the main processor, like rendering simple UI overlays or handling audio playback?
Lucas: Some already do. The latest Snapdragon chips have a 'low-power audio' subsystem that can handle music decoding and playback while the main processor is off. But the bigger trend is consolidation: rather than having separate sensor hubs for different domains — motion, audio, health — we'll see a single, more capable hub that handles all always-on tasks. That's the direction Apple is going with its 'always-on processor' in the Apple Watch Series 9 and later.
Luna: So the sensor hub becomes the 'always-on computer' that runs the background experience, while the main processor sleeps until you need peak performance.
Lucas: Exactly. And that has implications for the architecture of future devices. I think we'll see a split between a 'thin client' always-on processor and a high-performance burst processor, especially in wearables and IoT. It's already happening in the phone, and it's spreading.
Luna: I want to come back to the privacy angle one more time. If the sensor hub is always on and always processing, could it be used to infer sensitive information without the user's knowledge? Say, from motion patterns or ambient sound?
Lucas: Hypothetically, yes. Motion data can reveal typing patterns, gait, driving habits. But because the sensor hub is a closed, controlled environment, it's harder to compromise than the main OS. Still, it's a risk — and one that researchers have pointed out. The solution, again, is local processing: the sensor hub should only output high-level decisions, never raw data. Apple's approach of giving apps only aggregated step counts is a good model.
Luna: So the sensor hub is both a privacy enabler and a potential privacy risk, depending on how it's designed.
Lucas: Exactly. And that's why it's a fascinating piece of hardware to watch. It's small, it's cheap, it's everywhere, and it's quietly reshaping how devices interact with the physical world. I think in a decade, the sensor hub will be as fundamental to device architecture as the CPU is today.
Luna: Great conversation. I'll never look at my phone's 'always-on' features the same way again.
Lucas: Same here. Next time you pick up your phone and it lights up instantly — that's the sensor hub doing its job before the main chip even wakes up.

Shows are listed from Apple Podcasts' charts and directory, and Podcast Index where it is used. Every show and episode belongs to its publisher and plays from the publisher's own feed; this site hosts none of them.