Put BLE and Wi-Fi on the same board, run them both under load, and something often happens that no bench test predicted. BLE connections start dropping. Not randomly, and not because either radio has a defect. They drop specifically during Wi-Fi bulk transfers, OTA updates, large telemetry syncs, and video uploads, and they recover once the Wi-Fi traffic quiets down.
This is RF coexistence, and it is one of the most consistently under-planned aspects of multi-radio embedded design. Not because engineers don’t know about it, but because it almost never surfaces in a lab environment. We’ve covered more on this in a previous post – UWB vs BLE vs Wi-Fi.Â
Basically, labs don’t generate the kind of sustained, simultaneous radio demand that a product sees in actual use. So the problem ships, and it gets diagnosed from field reports rather than from a test pass.
For most of embedded hardware’s history, putting multiple radios on one board was a specialized design decision, something that gateway and hub teams dealt with. Ordinary products carried one radio, and there was nothing to arbitrate.
That has changed. BLE combined with Wi-Fi is now close to a default configuration across consumer electronics, industrial IoT, and commercial connected hardware. In most of these designs, both radios live on a single combo chip with one shared RF front-end.Â
The shared front-end is what creates the coexistence problem, and it exists regardless of which vendor’s silicon is on the board and regardless of how capable that silicon is.
A combo chip with BLE and Wi-Fi does not let both radios transmit at the same time. An arbitration layer sits between the two radio stacks and the shared hardware, deciding on a millisecond timescale which radio gets access to the front-end at any given moment.
The diagram below shows the full structure:
As Espressif’s ESP-IDF coexistence documentation describes, the allocation shifts across four defined states: idle, connected, scanning, and connecting, with each state carrying a different time-slice proportion between Wi-Fi and BLE.Â
When Wi-Fi is idle, BLE gets a generous slice. When Wi-Fi is actively transferring data, its slice expands and BLE’s contracts. The arbitration layer adjusts this continuously based on real-time conditions.
But the problem is that BLE has firm timing requirements at the protocol level. A BLE peripheral that misses its scheduled connection interval can be treated as disconnected by the central device, because the central has no way to distinguish between a missed packet and a dropped link.
Wi-Fi during a bulk transfer holds the front-end for longer continuous windows than BLE’s connection intervals can accommodate. When arbitration is not tuned to protect BLE’s timing, Wi-Fi takes precedence by default, and BLE pays for it, in dropped connections.
The symptom shows up in three recognizable ways in production. BLE connections drop during Wi-Fi OTA updates or large data syncs. Wi-Fi throughput falls noticeably when BLE begins scanning. And in some designs, the failures are intermittent enough that they only emerge under real sustained load, making them hard to reproduce in normal testing.
Solving coexistence has historically meant firmware work. Engineers enable Packet Traffic Arbitration between the BLE and Wi-Fi cores, adjust BLE scan windows and connection intervals to create gaps that Wi-Fi can use without disrupting BLE’s timing, and validate the results under a realistic combined load.
That approach still applies, but silicon vendors are increasingly building coexistence arbitration into hardware. NXP’s IW612 and IW623 parts both implement a central hardware Packet Traffic Arbiter that provides real-time arbitration between Wi-Fi and Bluetooth on a per-packet basis, with software algorithms available to tune its behavior. This is a meaningful shift in who carries the base responsibility for solving the problem.
The important practical detail is that enabling this hardware capability is not automatic. NXP’s own application note states that the hardware PTA arbitration can be statically enabled or disabled. Espressif’s documentation for the ESP32-C3 explicitly states that coexistence must be enabled through menuconfig, otherwise the coexistence function cannot be used.Â
A team that integrates one of these chips, validates it in a quiet RF environment, and ships without configuring the coexistence hardware is shipping a product that has the capability to manage the problem correctly, but is not using it.
This is the most common source of coexistence failures on modern silicon. It is not a hardware limitation. It is a configuration step that did not happen.
On-device inference does not directly compete for radio time. Modern edge AI hardware is increasingly built around dedicated inference cores or micro-NPUs that run alongside the main MCU specifically to avoid that kind of contention. The inference workload itself does not draw on the radio front-end.
What draws on the radio is what the inference result decides to do. When a model detects an anomaly, recognizes a keyword, or crosses a threshold, it typically triggers a transmission: an alert over BLE, a compressed event clip over Wi-Fi, a status update over LTE. That transmission enters the same arbitration queue as every other radio event on the board.
Research on edge AI scheduling increasingly treats inference timing and radio access as a joint coordination problem, because separating them creates edge cases where an inference-triggered event competes poorly for radio time at exactly the moment when timely delivery matters most.
For teams designing a coexistence policy, this is worth planning for. A policy tuned around predictable periodic telemetry and scheduled OTA windows will behave differently once an inference layer adds an event-driven, unpredictable source of radio demand. The arbitration parameters that work well in one traffic model may not hold in the other.
Coexistence problems found early are configuration problems. Coexistence problems found after a board is finalized are much harder to resolve cleanly. Firmware workarounds can reduce the severity, usually by sacrificing some performance on one radio to protect the other.Â
If the antenna layout does not provide adequate physical isolation between the two radio paths, firmware tuning alone may not be sufficient, and the fix requires a board revision with the associated schedule and recertification cost.
The teams that ship clean multi-radio products tend to follow a few practices that are not complicated but are easy to skip under schedule pressure.
1. They read the coexistence section of the vendor SDK documentation before bring-up, not during debugging. Every major combo silicon vendor, including Espressif, Silicon Labs, Nordic, and NXP, publishes application notes and SDK configuration guides specifically for coexistence.
These documents describe which registers to enable, which parameters to tune, and which traffic scenarios to validate against. Most of the configuration that teams discover they needed during field escalations was already documented before the product shipped.
2. They configure the coexistence hardware explicitly, rather than leaving it at SDK defaults. As discussed earlier, most vendor SDKs do not enable coexistence arbitration by default. Treating a default configuration as a validated configuration is where most avoidable coexistence problems begin.
3. They test under simultaneous, sustained load before the board is locked. This means running a BLE connection and a Wi-Fi bulk transfer at the same time, at the data rates and packet sizes the product will actually see in the field, not in isolation on a quiet bench. A spectrum analyzer during this test is not optional. It is what makes the arbitration behavior visible rather than inferred from symptoms.
4. They account for event-driven radio demand if the product includes any form of on-device inference. A model that triggers transmissions changes the traffic profile the arbitration system has to manage. Teams that model only their periodic telemetry and OTA traffic when tuning coexistence parameters, and then add inference later, often find that the parameters need revisiting.
5. They treat coexistence validation as a gate in the design process, not a checkbox after the fact. The engineers who avoid field escalations are not necessarily more skilled than the ones who don’t. They are more deliberate about when in the schedule this validation happens.
RF coexistence is not an exotic problem, but it’s one that’s hard to avoid these days with multi-radio chips increasingly becoming the norm. It is a predictable consequence of putting multiple radios on shared silicon without a deliberate coordination strategy.Â
The tools to manage it are well documented, the silicon to handle it is widely available, and the validation process is straightforward. What it requires is that the work gets done at the right point in the design cycle, before the board is locked rather than after the product is in the field.
The products that handle this well are not the ones built by teams with access to better components. They are the ones built by teams who treated radio coordination as a critical design requirement from the beginning.
If your team is working through a coexistence problem on a current design, or planning a product that will combine radios on shared silicon for the first time, embedUR’s engineering team is happy to take a look.Â
We have worked through this class of problem dozens of times across BLE and Wi-Fi combo designs from several silicon vendors, and we can help identify where the gap is and what it takes to close it. Get in touch with us here.
Put BLE and Wi-Fi on the same board, run them both under load, and something often happens that no bench test predicted. BLE connections start dropping. Not randomly, and not because either radio has a defect. They drop specifically during Wi-Fi bulk transfers, OTA updates, large telemetry syncs, and video uploads, and they recover once the Wi-Fi traffic quiets down.
This is RF coexistence, and it is one of the most consistently under-planned aspects of multi-radio embedded design. Not because engineers don’t know about it, but because it almost never surfaces in a lab environment. We’ve covered more on this in a previous post – UWB vs BLE vs Wi-Fi.Â
Basically, labs don’t generate the kind of sustained, simultaneous radio demand that a product sees in actual use. So the problem ships, and it gets diagnosed from field reports rather than from a test pass.
For most of embedded hardware’s history, putting multiple radios on one board was a specialized design decision, something that gateway and hub teams dealt with. Ordinary products carried one radio, and there was nothing to arbitrate.
That has changed. BLE combined with Wi-Fi is now close to a default configuration across consumer electronics, industrial IoT, and commercial connected hardware. In most of these designs, both radios live on a single combo chip with one shared RF front-end.Â
The shared front-end is what creates the coexistence problem, and it exists regardless of which vendor’s silicon is on the board and regardless of how capable that silicon is.
A combo chip with BLE and Wi-Fi does not let both radios transmit at the same time. An arbitration layer sits between the two radio stacks and the shared hardware, deciding on a millisecond timescale which radio gets access to the front-end at any given moment.
The diagram below shows the full structure:
As Espressif’s ESP-IDF coexistence documentation describes, the allocation shifts across four defined states: idle, connected, scanning, and connecting, with each state carrying a different time-slice proportion between Wi-Fi and BLE.Â
When Wi-Fi is idle, BLE gets a generous slice. When Wi-Fi is actively transferring data, its slice expands and BLE’s contracts. The arbitration layer adjusts this continuously based on real-time conditions.
But the problem is that BLE has firm timing requirements at the protocol level. A BLE peripheral that misses its scheduled connection interval can be treated as disconnected by the central device, because the central has no way to distinguish between a missed packet and a dropped link.
Wi-Fi during a bulk transfer holds the front-end for longer continuous windows than BLE’s connection intervals can accommodate. When arbitration is not tuned to protect BLE’s timing, Wi-Fi takes precedence by default, and BLE pays for it, in dropped connections.
The symptom shows up in three recognizable ways in production. BLE connections drop during Wi-Fi OTA updates or large data syncs. Wi-Fi throughput falls noticeably when BLE begins scanning. And in some designs, the failures are intermittent enough that they only emerge under real sustained load, making them hard to reproduce in normal testing.
Solving coexistence has historically meant firmware work. Engineers enable Packet Traffic Arbitration between the BLE and Wi-Fi cores, adjust BLE scan windows and connection intervals to create gaps that Wi-Fi can use without disrupting BLE’s timing, and validate the results under a realistic combined load.
That approach still applies, but silicon vendors are increasingly building coexistence arbitration into hardware. NXP’s IW612 and IW623 parts both implement a central hardware Packet Traffic Arbiter that provides real-time arbitration between Wi-Fi and Bluetooth on a per-packet basis, with software algorithms available to tune its behavior. This is a meaningful shift in who carries the base responsibility for solving the problem.
The important practical detail is that enabling this hardware capability is not automatic. NXP’s own application note states that the hardware PTA arbitration can be statically enabled or disabled. Espressif’s documentation for the ESP32-C3 explicitly states that coexistence must be enabled through menuconfig, otherwise the coexistence function cannot be used.Â
A team that integrates one of these chips, validates it in a quiet RF environment, and ships without configuring the coexistence hardware is shipping a product that has the capability to manage the problem correctly, but is not using it.
This is the most common source of coexistence failures on modern silicon. It is not a hardware limitation. It is a configuration step that did not happen.
On-device inference does not directly compete for radio time. Modern edge AI hardware is increasingly built around dedicated inference cores or micro-NPUs that run alongside the main MCU specifically to avoid that kind of contention. The inference workload itself does not draw on the radio front-end.
What draws on the radio is what the inference result decides to do. When a model detects an anomaly, recognizes a keyword, or crosses a threshold, it typically triggers a transmission: an alert over BLE, a compressed event clip over Wi-Fi, a status update over LTE. That transmission enters the same arbitration queue as every other radio event on the board.
Research on edge AI scheduling increasingly treats inference timing and radio access as a joint coordination problem, because separating them creates edge cases where an inference-triggered event competes poorly for radio time at exactly the moment when timely delivery matters most.
For teams designing a coexistence policy, this is worth planning for. A policy tuned around predictable periodic telemetry and scheduled OTA windows will behave differently once an inference layer adds an event-driven, unpredictable source of radio demand. The arbitration parameters that work well in one traffic model may not hold in the other.
Coexistence problems found early are configuration problems. Coexistence problems found after a board is finalized are much harder to resolve cleanly. Firmware workarounds can reduce the severity, usually by sacrificing some performance on one radio to protect the other.Â
If the antenna layout does not provide adequate physical isolation between the two radio paths, firmware tuning alone may not be sufficient, and the fix requires a board revision with the associated schedule and recertification cost.
The teams that ship clean multi-radio products tend to follow a few practices that are not complicated but are easy to skip under schedule pressure.
1. They read the coexistence section of the vendor SDK documentation before bring-up, not during debugging. Every major combo silicon vendor, including Espressif, Silicon Labs, Nordic, and NXP, publishes application notes and SDK configuration guides specifically for coexistence.
These documents describe which registers to enable, which parameters to tune, and which traffic scenarios to validate against. Most of the configuration that teams discover they needed during field escalations was already documented before the product shipped.
2. They configure the coexistence hardware explicitly, rather than leaving it at SDK defaults. As discussed earlier, most vendor SDKs do not enable coexistence arbitration by default. Treating a default configuration as a validated configuration is where most avoidable coexistence problems begin.
3. They test under simultaneous, sustained load before the board is locked. This means running a BLE connection and a Wi-Fi bulk transfer at the same time, at the data rates and packet sizes the product will actually see in the field, not in isolation on a quiet bench. A spectrum analyzer during this test is not optional. It is what makes the arbitration behavior visible rather than inferred from symptoms.
4. They account for event-driven radio demand if the product includes any form of on-device inference. A model that triggers transmissions changes the traffic profile the arbitration system has to manage. Teams that model only their periodic telemetry and OTA traffic when tuning coexistence parameters, and then add inference later, often find that the parameters need revisiting.
5. They treat coexistence validation as a gate in the design process, not a checkbox after the fact. The engineers who avoid field escalations are not necessarily more skilled than the ones who don’t. They are more deliberate about when in the schedule this validation happens.
RF coexistence is not an exotic problem, but it’s one that’s hard to avoid these days with multi-radio chips increasingly becoming the norm. It is a predictable consequence of putting multiple radios on shared silicon without a deliberate coordination strategy.Â
The tools to manage it are well documented, the silicon to handle it is widely available, and the validation process is straightforward. What it requires is that the work gets done at the right point in the design cycle, before the board is locked rather than after the product is in the field.
The products that handle this well are not the ones built by teams with access to better components. They are the ones built by teams who treated radio coordination as a critical design requirement from the beginning.
If your team is working through a coexistence problem on a current design, or planning a product that will combine radios on shared silicon for the first time, embedUR’s engineering team is happy to take a look.Â
We have worked through this class of problem dozens of times across BLE and Wi-Fi combo designs from several silicon vendors, and we can help identify where the gap is and what it takes to close it. Get in touch with us here.
 Measuring where a person or object is with Bluetooth Low Energy (BLE) is like finding a bakery by its smell. You know it is close, you just can’t tell if it is 10 metres ahead or 30 metres to your left. Ultra-Wideband (UWB) gives you an edge. It measures the same distance the way a tape measure does: accurate to the centimetre. That precision is why UWB is showing up in applications where BLE cannot deliver. Every one of those applications is a firmware team solving a problem BLE never forced them to think about.
Most of the content written about UWB fixates on Real-Time Location Systems (RTLS: infrastructure-heavy tracking systems that monitor the positions of assets and people across a large space using fixed anchor hardware).
That coverage has its place. However, the five applications where firmware teams are doing the most interesting work “right now” go largely unwritten about: autonomous robot follow-me, child presence detection tied to automotive safety ratings, gesture recognition without cameras, contactless vital sign monitoring, and peer-to-peer ranging in consumer devices. Two of these are what regulation mandates. But all five are firmware-intensive in ways warehouse tracking never is.
This article covers all five. It includes: why UWB fits each problem, what the firmware actually has to do, and which silicon fits each use case. As for the alternatives, catch a more detailed read in our other post – UWB vs BLE vs Wi-Fi: A Firmware Engineer’s Decision Framework.
A UWB pulse lasts less than one nanosecond, the time it takes light to travel roughly 30 centimetres. That timing precision is what makes UWB a ruler rather than a radio.
Here is what “wide frequency bandwidth” means in plain terms. Narrow-band radios broadcast the way someone holds a long note on a saxophone: by the time the note reaches you directly, the echo bouncing off the wall is already on top of it.
The two blur into one sound. UWB broadcasts the way a drummer plays a single sharp hit: direct sound and echo arrive as two distinct beats you can tell apart. Spreading across 500 MHz gives the receiver that sharp-beat resolution. It separates the direct signal from its wall-reflected copies cleanly.
For firmware engineers, this shifts the problem from filtering and estimating to measuring and acting.
The five applications below all exploit that shift in different ways.
An autonomous follow-me robot is a wheeled or legged machine that follows a specific person through a shared workspace: a nurse down a hospital corridor, a warehouse picker between aisles, a logistics worker on a factory floor. The robot carries the tools, parts, or load the person would otherwise push on a cart. The design brief sounds simple. Stay a fixed distance behind the person. Close enough to be useful. Far enough to be safe. Never hit them.
The environment is where the job gets hard. For instance, in situations where: another person steps between the robot and the operator or the operator turns around and walks back to grab something from the cart. The robot has to spot the reversal, stop and hold its ground, then swing around and start following again once the operator heads off.
KUKA’s KMR iiwa, one of the most capable mobile robots on factory floors today, uses laser scanners to navigate for exactly these reasons. The same problem now shows up in humanoid robotics. Unitree’s G1 humanoid is already being paired with UWB tracking modules from vendors like Weston Robot. Once a humanoid is meant to share spaces with people, the robot must know the exact position of the person it follows, within a few centimetres, at all times.
BLE Received Signal Strength Indicator (RSSI) fails in these conditions because signal strength is a guess. The same received power could mean the operator is 2 metres directly ahead, or 8 metres away behind a steel shelf. UWB works differently. It timestamps when a radio signal is sent and when it comes back, divides by the speed of light, and returns a distance accurate to centimetres.
Think of it the way a ship uses sonar: send a pulse toward the seabed, wait for it to return, measure the round-trip time, and the depth is calculable to within metres.
TWR does the same thing between two UWB radios, at the speed of light: the tag sends a timestamped message, the anchor responds with its own timestamp, and the round-trip time reveals a distance accurate to centimetres. A UWB tag worn by the operator and an anchor node mounted on the robot exchange these ranging messages on a timed schedule.
The firmware on the robot side runs a ranging scheduler: a task that wakes the radio, collects the distance measurement, and passes it to the motion controller before putting the radio back to sleep. For heading estimation (knowing which direction to follow, in addition to how far), firmware teams typically fuse UWB readings from two or three tag positions with data from an Inertial Measurement Unit (IMU: a sensor that measures acceleration and rotation, used here to track which way the robot is turning).
Silicon that fits: the Qorvo DW3120 handles TWR with interrupt-driven firmware integration that maps cleanly onto a Real-Time Operating System (RTOS: the software layer that manages when each firmware task runs on the processor). For battery-operated operator tags where current draw is the binding constraint, Spark Microsystems documents the SR1000 at sub-mW active receive current at 0.85 Mbps in its product documentation.
For teams evaluating autonomous mobility systems: UWB follow-me removes the “clean environment” assumption from your testing checklist. The system works where your robot actually operates.
By 2026, Child Presence Detection (CPD) has become a requirement for top safety ratings in major markets, led by the European New Car Assessment Programme (Euro NCAP: the body that rates vehicle safety across Europe). Euro NCAP started awarding CPD points in 2023. From January 2025, the system must also detect a child aged three to six who climbs into an unlocked car on their own and becomes trapped when it locks. The US Hot Cars Act pushes a parallel regulatory path.
Two standards bodies carve up the CPD problem between them: Euro NCAP sets the detection requirements (what the system must spot, and how reliably), while the FiRa Consortium (Fine Ranging Consortium: the industry body that governs how UWB devices from different vendors talk to each other) sets the interoperability rules for the UWB radios themselves. For automotive suppliers and Tier 1 integrators, Euro NCAP’s CPD requirement is already scoring your competitors. This is an engineering deadline with a date attached, and a 5-star rating on the line.
The challenge is physical. A sleeping infant’s chest rises and falls three to eight millimetres with each breath. A heartbeat moves the chest by 0.2 to 0.5 millimetres. Cameras need good lighting and a clear view of the child. A closed car on a hot day gives you neither.
Think of UWB in-cabin sensing the way a bat navigates a cave. A bat reads the echo of its own chirp to map everything around it: walls, gaps, moving prey, without needing to see any of it.
A UWB radar node reads the echo of its own pulse, and a breathing chest changes that echo in a pattern no inanimate object in the car produces. The firmware configures the radio in radar mode rather than ranging mode, collects pulse-return data at a high repetition rate, applies signal averaging to filter out road vibration, and extracts the respiration waveform from what remains.The FiRa Consortium sets the interoperability rules for UWB ranging. The CPD sensing requirements (what the system must detect and how reliably) are governed by Euro NCAP.
Silicon that fits: NXP’s Trimension is the company’s family of UWB chips — the same line BMW uses for its Digital Key Plus passive entry system. NXP’s published documentation for in-cabin UWB sensing covers the Trimension CPD configuration in detail. The chip built for this job in production vehicles is the NCJ29D6A. It combines UWB ranging with short-range radar on a single chip and carries AEC-Q100 qualification (Automotive Electronics Council standard 100: the industry test suite that confirms a chip survives the temperature swings, vibration, and humidity a car endures over its lifetime). For CPD specifically, that matters because the chip has to keep working in a parked car that hits 70°C on a hot afternoon.
For product teams in automotive, consumer electronics, and industrial control: UWB gesture recognition works in any lighting condition, captures no image data, and runs five to seven recognised gestures at above 90% accuracy in production conditions. The privacy compliance burden disappears before it reaches your legal team.
Camera-based gesture systems face three challenges firmware teams rarely budget for up front. The first is the privacy compliance burden image capture brings with it. The second is processing demand most embedded platforms cannot spare. The third is a hard dependency on lighting conditions. UWB sidesteps all three.
Every UWB transmission channel produces a Channel Impulse Response (CIR). Think of the CIR the way a musician reads a room. Strike the same chord in an empty warehouse and in a tiled bathroom, and the note sounds different: same source, but completely different reflection profile.
When a hand moves between two UWB nodes, the CIR shifts in a pattern that matches the gesture. The firmware grabs the CIR frames at a fast update rate, hands them to a machine learning model running on the main microcontroller, and outputs the gesture in under 50 milliseconds.
How many gestures can UWB tell apart? A 2020 study hit 95% accuracy across eight hand gestures. The gestures were four swipe directions (left-right, right-left, up-down, down-up), two diagonal swipes, and two rotations (clockwise and counterclockwise). A 2021 public dataset stretched the count to twelve. In production cars, where a false positive is dangerous, vendors keep the menu tighter: five to seven gestures, accuracy above 90% once the model is trained on the actual cabin layout.
The implementation challenge is throughput. Raw CIR data coming off the radio must move to the classifier without stalling other firmware tasks. On an RTOS, that means a dedicated high-priority interrupt service routine handing data to a processing queue, with the classifier running as a lower-priority task against a timestamp-matched buffer. Teams that underestimate this pipeline are the ones who end up with gesture latency measured in seconds rather than milliseconds.
Silicon that fits: Where most ranging chips hand you a distance and nothing else, Qorvo DW3220 gives you the full raw reflection data directly. That full reflection fingerprint is what the classifier trains on and runs against. A mature driver ecosystem means the radio is up and feeding data quickly. The firmware problem left to solve is the interesting one: building the model.
For medical device teams and automotive OEMs: contactless vital sign monitoring removes the need for electrodes, adhesives, or patient compliance. The sensor reads breathing and heartbeat at up to five metres of clear line-of-sight. It works whether the patient cooperates or not.
UWB can detect breathing and heartbeat through air, without touching the patient. The physics is the same impulse-radar principle used in contactless monitors in neonatal intensive care units (NICUs), where it has been tested against ECG and chest-impedance sensors on more than thirty premature babies in published clinical studies. Microwave radar has been used to monitor vital signs in clinics since the mid-1970s. UWB takes the same physics and shrinks it to fit the power budget and board space embedded engineers work with.
Each UWB pulse reflects off the chest wall. As the chest moves with each breath, the return time of the reflected pulse shifts by picoseconds (trillionths of a second), corresponding to a displacement of millimetres. The firmware averages thousands of pulse returns to pull this signal out of noise, applies bandpass filters tuned to the frequencies of human respiration (12 to 20 cycles per minute) and heartbeat (60 to 100 beats per minute), and produces a clean waveform a host processor can interpret.
A useful frame for picturing this: press your wrist gently against a drumhead while someone taps the other side of the drum. You feel the vibration clearly, even though your wrist is nowhere near the source. UWB reads the equivalent of that vibration through open air, without any physical connection to the patient. Working range for reliable respiration detection is up to approximately 5 metres under clear line-of-sight conditions.
Applications include neonatal monitoring, in-vehicle occupant detection as a complement to the CPD use case above, and eldercare systems where reducing physical contact with a sensor matters. A patient who moves or removes a wired monitor in the night still has a chest wall that can be monitored.
Silicon that fits: Novelda’s X4M200 is a dedicated Impulse-Radio UWB (IR-UWB: the sub-category of UWB that uses short, repeated radar-like pulses specifically for sensing rather than communication) respiration sensor. Novelda’s own product documentation confirms its 0.4 to 5-metre sensing zone for breathing detection, and the IR-UWB approach it uses is independently validated in peer-reviewed literature.
Fixed-infrastructure positioning is expensive. RTLS forces you to mount anchors on ceilings, calibrate them, run a location engine on a server, and pay to keep all of it running. That cost shuts a lot of useful applications out of the market.
Peer-to-peer (P2P) UWB ranging removes the infrastructure entirely. Two devices with UWB radios trade timestamped messages and work out the distance between them directly. No anchors. No server.
What this unlocks: Apple’s AirTag uses P2P UWB to point you to a misplaced wallet within a few centimetres. BMW’s Digital Key Plus uses it for hands-free entry: the owner’s phone ranges against a UWB node inside the car door, and the lock opens when the phone is authenticated and inside the permitted zone.
The Car Connectivity Consortium (CCC: the industry body that sets the standard for how phones unlock cars) defines this in its Digital Key 3.0 standard, covering both the ranging protocol and the security on top of it. Industrial proximity warning, asset pairing without a network, and contactless payment confirmation are all live build areas.
What firmware has to solve: The hard problem is not ranging. It is scheduling. When dozens of P2P devices range at the same time in a tight space like a car park, a warehouse loading dock, or a busy office, the protocol has to decide who talks when. If it gets that wrong, measurement collisions stack up into delays.
Think of P2P ranging like two people standing at opposite ends of a street, each holding a stopwatch synchronised to the same clock. One calls out, the other records the time of arrival and calls back. From those two timestamps and the known speed of radio waves, both can calculate the distance between them to within centimetres.
The firmware manages two roles: initiator (the device that sends the first ranging message) and responder (the device that timestamps receipt and replies). At product scale, the hard firmware problem shifts from ranging to scheduling: when dozens of P2P devices are ranging simultaneously in a confined space, the protocol must handle contention without measurement collisions stacking up into delays.
Silicon that fits: Qorvo documents the DW3xxx series for consumer and industrial P2P ranging in its “UWB in Digital Car Key” whitepaper, which details ranging performance in CCC Digital Key 3.0-compliant deployments. For automotive-grade implementations requiring both CCC compliance and AEC-Q100 qualification, NXP’s Trimension SR150 product documentation maps the chip directly to the CCC Digital Key 3.0 specification.
None of the five applications above uses ceiling anchors. None requires a cloud location engine. Strip away the RTLS framing that dominates most UWB content, and what remains is a single consistent capability: precise distance measurement between two points, executed in firmware, at close range.
That is the thread. Between two devices. Between a radar node and a chest wall. Between a robot and the operator it follows.
The firmware architecture that serves all five looks the same at its core: a ranging or radar engine producing raw measurements, a decision layer acting on those measurements against a threshold or model, and a power manager keeping the radio asleep between sessions. Master that pattern once, and it transfers across every application in this article.
One constraint carries across all five applications: line-of-sight matters, but the meaning is more specific than zero obstacles. Commercial UWB ranging chips operate in the 6 to 9 GHz band. At those frequencies the signal passes through drywall, wood, and glass with some loss of accuracy. It degrades sharply through brick and reinforced concrete. It is effectively blocked by metal: steel shelving, car door pillars, aluminium cabinets, copper plumbing in a wall. Water absorbs UWB too, which is why a human body itself blocks the signal.
The practical rule for firmware teams: a UWB node needs a clear radio path to its target, free of metal obstructions, with at least twenty centimetres of clearance from any nearby metal that could distort the antenna. A metal cabinet between a UWB node and a patient’s chest, a car door pillar between two ranging nodes, a steel shelf between a robot and its operator tag will all wreck measurement quality. Antenna placement is an architecture decision. Finalise it before the software stack takes shape.
The volume in UWB over the next product cycle is coming from these five firmware problems, driven by regulatory mandates, consumer product adoption, and the specific gap that centimetre-level ranging fills where BLE cannot.
Where does your current product sit against that list, and what does the firmware architecture need to look like when UWB joins the stack?
embedUR’s firmware team has integrated UWB ranging across automotive, consumer, and industrial applications. If you are evaluating UWB for any of the applications covered here, a 30-minute architecture review maps your requirements to a firmware topology and flags integration risks before any code is written.
If you enjoyed this article, discover even more of UWB’s capabilities in our next blog post – UWB Beyond Ranging: What IEEE 802.15.4ab Means for Your Firmware.
Too many times we’ve seen or heard a situation where a child falls asleep in the back seat. The driver steps away. Fifteen minutes later, the cabin temperature starts climbing. So, what if somewhere inside the dashboard, the same UWB chip that unlocked the car door when the driver approaches can do something entirely different. Like reading the faint reflections of its own radio pulses bouncing off the child’s chest, detecting the tiny rise and fall of breathing, and triggering an alert before heat becomes danger.
That capability will soon be available in modern production vehicles. The existing Ultra-Wideband (UWB) radio already inside the dashboard is learning a valuable second skill.
UWB has earned its place as the most accurate indoor positioning radio available, delivering centimeter-level distance measurements using time-of-flight (ToF): the time it takes a pulse to travel from one device to another and back. Our decision framework for indoor positioning radios covered the firmware realities of choosing between UWB, Bluetooth Low Energy (BLE), and Wi-Fi. That comparison assumed UWB was a ranging radio.
This article, which talks about the next-generation standard, IEEE 802.15.4ab, widens the assumption. With standardized radar sensing, a UWB anchor in a hospital hallway can detect whether an elderly patient has fallen, without a camera in the room. With 30x extended range, fewer anchors cover the same warehouse floor, cutting deployment costs and calibration overhead. Ranging is still there. Radar sensing, extended range, and 18x higher data rates now sit alongside it. For firmware teams, the radio’s job description just expanded, and the software has to keep up.
UWB ranging is a conversation between two devices. A tag sends a pulse, an anchor replies, and the system measures the round-trip time to calculate distance. Both sides participate.
UWB radar is an echo. One device sends pulses into a room and listens to what bounces back. No second device needed. The reflections carry information: where objects are, whether something is moving, and how far away it sits. What the device captures is called a channel impulse response, or CIR. Think of it as clapping once in an unfamiliar room. Every surface sends back an echo at a slightly different time and volume. A CIR is the full recording of all those echoes at once, preserving the timing and strength of each reflection path.
The physics underneath is the same as ranging: short pulses across a 500 MHz bandwidth. The difference is entirely in what the firmware does with the signal. Ranging firmware reads timestamps and computes distance. Radar firmware reads the CIR and runs detection algorithms: is something present? Is it moving? Is it breathing?
Two parameters control the trade-off. First, more samples per radar sweep extend the detection range from centimeters to several meters. Second, higher sweep rates improve accuracy but cost more power. Even at several meters of detection range, UWB radar draws under 10 milliwatts. That number keeps battery-powered devices on the table.
The practical result: a UWB anchor installed for digital key access can double as a presence sensor. Same hardware. No extra cost.
The current generation of UWB silicon, including Qorvo’s DW3xxx series and NXP’s Trimension platform, is built on IEEE 802.15.4z. That standard defined secure ranging and physical-layer (PHY) security: the lowest level of the radio hardware, where pulses are shaped and timed. It gave firmware teams a reliable foundation. Time-of-flight measurement with distance-bounding that prevents relay attacks (where a thief amplifies your car key signal from a distance to trick the lock into opening). Every production UWB ranging product on the market today runs on 802.15.4z.
IEEE 802.15.4ab is the successor, expected to be officially released in the first half of 2026. It is backward compatible with 802.15.4z, building on the existing foundation rather than discarding it. Going forward, three additions will matter for teams building on UWB:
1. Radar sensing becomes part of the standard: Under 802.15.4z, radar-like sensing was possible but vendor-specific. Qorvo published application notes on CIR-based presence detection using existing DW3xxx hardware. NXP shipped the Trimension SR250 with combined ranging and radar support. Each implementation used proprietary firmware interfaces. 802.15.4ab writes radar into the standard itself, defining how Impulse Radio UWB (IR-UWB) transceivers operate in sensing mode.
That means interoperable radar behavior across chipmakers. Not just interoperable ranging. Ceva is pushing this further: their Ceva-Waves UWB IP, the industry’s first 802.15.4ab-compliant design, supports combined ranging-and-radar sensing on a single silicon block. Because Ceva also licenses edge AI processors (NeuPro) and sensor fusion cores (MotionEngine), chipmakers can place the UWB radio and the radar detection algorithms on the same chip, rather than offloading CIR processing to a separate microcontroller.
For firmware engineers, this collapses two separate worlds into one. Today, your ranging code and your radar code (if you use it) talk to different vendor libraries with different data structures and different timing rules. A standardized radar mode means chipmakers will converge on common interfaces. Your architecture needs to anticipate a unified API (Application Programming Interface, the set of commands your code uses to control the chip) rather than two bolted-together SDKs (Software Development Kits).
2. Secure ranging pushes from pocket distance to building scale: Current 802.15.4z secure ranging works reliably at close proximity: digital keys, item finders, short-range access control. 802.15.4ab introduces multi-millisecond (MMS) ranging techniques. Instead of a single fast pulse exchange, MMS accumulates multiple measurements over a longer window, trading speed for signal gain. The result is more range at the same transmit power, and the early numbers suggest the gain is substantial.
How much more range are we talking about? Ceva’s 802.15.4ab-compliant UWB IP, announced on March 10, 2026, claims up to 30x range extension over current 802.15.4z. That moves UWB from “is the user next to the door?” to “where in this space are they?” UWB still works best within line-of-sight or through lightweight partitions, so “this space” means a floor, a warehouse zone, or an open facility rather than through concrete walls and steel framing. It pushes UWB into territory held by Wi-Fi Round-Trip Time (RTT) positioning and BLE Angle of Arrival (AoA), but with UWB’s inherent accuracy and security.
For firmware teams, longer-range sessions consume more energy per cycle, making your sleep and wake scheduling more consequential. Your power model has to account for these longer windows.
For decision-makers, the implication is simpler: UWB can now cover warehouse-scale and campus-scale spaces where teams previously had to fall back on BLE or Wi-Fi. Fewer compromises on accuracy, fewer radios to manage.
3. Data rates jump 18x: Current UWB devices communicate at 6.8 Megabits per second (Mbps). 802.15.4ab supports up to roughly 125 Mbps. That opens up use cases that pure ranging applications never needed: low-latency audio transport, richer protocol exchanges, and combined sessions where a single UWB transaction delivers both a position fix and a data payload.
For most Real-Time Location System (RTLS) and access control firmware, 6.8 Mbps has been more than enough. But if your product roadmap includes streaming sensor data alongside ranging, or pushing firmware updates over UWB rather than a separate BLE link, the additional bandwidth changes what your radio can carry.
In practice, you end up with one radio link that handles positioning, data transfer, and firmware updates. That is fewer radios in the design and fewer integration headaches in the field.
The volume signal underneath all of this: Grand View Research projects the global UWB market to grow at a CAGR of 18.9% from 2024 to 2030, reaching $4.37 billion by 2030 from an estimated $1.40 billion base in 2023. The ecosystem is moving. Also, Ceva’s announcement signals that compliant silicon IP is available for licensing now, meaning chipmakers can integrate it into next-generation Systems on Chip (SoCs: single chips combining processor, radio, and memory). Production parts built on 802.15.4ab are a design cycle away.
Here is where the standard meets the code your team writes.
a) Dual-mode scheduling: If your transceiver supports both ranging and radar, your Real-Time Operating System (RTOS: the software layer that decides when each task on the chip gets to run) has to manage two types of radio sessions with different timing profiles.
Think of it as air traffic control for a runway shared by two kinds of aircraft. Ranging sessions are the small fast jets: short bursts, tight timing, nanosecond-level precision. Radar sweeps are the heavy cargo planes: longer windows, more data collected, a different processing pipeline on the ground. Interleaving them without collision is a scheduling problem that ranging-only firmware never had to solve.
b) A new signal processing layer: Ranging firmware reads timestamps from the transceiver. Radar firmware reads CIR data: arrays of amplitude and phase samples that need filtering, thresholding, and classification to extract meaning (is someone present, are they moving, are they breathing). These are algorithmic problems that require more flash memory and RAM. If your current firmware barely fits in a DW3xxx’s companion microcontroller (MCU: the small processor running your tag’s software), radar processing will force a hardware reassessment.
c) Power budget complexity: A tag that ranges every 500 milliseconds has a predictable power profile. Add radar sweeps every 2 seconds and the profile shifts. Add adaptive logic that triggers radar only when ranging detects proximity, and the profile becomes state-dependent. Your power model needs to account for these layered modes. Otherwise, battery life estimates built for ranging alone will miss the mark.
d) The abstraction question: This one is about future-proofing. An abstraction layer in firmware works like a standard electrical outlet in a house. You plug in any appliance without rewiring the wall. Without that standard interface, every new device would mean tearing open the drywall. If your firmware talks directly to a 802.15.4z transceiver without a clean hardware abstraction layer between them, swapping in an 802.15.4ab chip later will mean rewriting that boundary. A few days of architecture work today prevents a quarter of rework after your product ships.
Automotive child presence detection: The European New Car Assessment Programme (Euro NCAP), the body that rates vehicle safety, have started tightening their scoring of vehicles on child presence detection (CPD) systems from 2025 onward. UWB radar detects micro-movements like breathing inside a cabin using the same anchor hardware as the digital key. No extra sensors. This is the first application where UWB radar will ship at volume, because regulation demands it.
Occupancy sensing without cameras: UWB radar detects presence and motion without capturing images. For healthcare facilities (fall detection in elder care), enterprise buildings (meeting room utilization), and smart buildings (heating, ventilation, and air conditioning automation), that privacy advantage changes the deployment conversation entirely.
Sparser infrastructure for indoor positioning: With 30x range improvement, fewer anchors cover the same floor space. Fewer anchors means lower deployment cost and less calibration overhead. Those two factors have been UWB’s most persistent adoption barriers.
If your team is mid-development on 802.15.4z, finish your product. The current silicon is stable and proven. But design your firmware with enough abstraction that the next chip does not demand a rewrite.
However, if you are in early product definition, factor in the widening value proposition. A radio that does ranging today and radar tomorrow carries a different cost-benefit weight than ranging alone.
Now, if your team is designing UWB firmware and wants to stress-test the architecture against what 802.15.4ab will demand, embedUR runs 30-minute architecture reviews. The review maps your requirements to firmware topology, models your power budget, and flags where your abstraction layer needs room to grow. That conversation costs less than the rework it prevents.
Which is cheaper for your team: the abstraction layer now, or the rewrite later?
In the embedded systems world, embedUR has spent the last twenty years in the trenches. We’ve built the wireless infrastructure that runs enterprise access points and the residential gateways sitting in millions of homes. In that time, we’ve learned one thing: regulatory shifts aren’t just legal problems. They are engineering problems.
The EU Cyber Resilience Act (CRA) is one of the biggest shifts we’ve seen in a decade. It isn’t just a footnote in a policy briefing; it’s a fundamental change in how we need to or should design, build, and most importantly, sustain products. At embedUR, we’ve guided teams through every Wi-Fi evolution from the early days of 802.11n to the complexities of Wi-Fi 6E and the new world of tinyML at the edge.
From where we stand, the CRA shouldn’t be a headache. It should be the catalyst that finally forces the industry to build smarter, more resilient systems.
But let’s be honest: for an engineering lead trying to hit a product launch date while staring down resource gaps, the CRA looks like a mountain of paperwork. To climb it, you have to bridge the gap between using an open-source RTOS like Zephyr and meeting the rigorous demands of European law.
We are currently in early 2026. The grace period is evaporating. The CRA was formally adopted back in late 2024, and the first major hammer will drop on September 11, 2026. That is the date when mandatory vulnerability reporting goes live.
If your device has a digital element and you sell it in the EU, you have 24 hours to report an exploited vulnerability. Not 24 hours after you fix it—24 hours after you find it.
By December 2027, the remaining requirements kick in: security-by-design as a legal mandate, machine-readable Software Bills of Materials (SBOMs), and a 5-year support window. If you miss these marks, the fines are eye-watering: up to €15 million or 2.5% of your global turnover. For any U.S. company exporting to Europe, which is a massive chunk of the global market, this is now the cost of doing business.
We’ve been working with Zephyr RTOS since its early releases in 2016. It’s under the Linux Foundation, it’s transparent, and it’s modular. On paper, it’s the perfect answer to the CRA.
Zephyr’s PSIRT (Product Security Incident Response Team) is excellent. They handle CVEs (Common Vulnerabilities and Exposures) with a level of transparency that mirrors the Linux kernel. When a bug is found in the networking stack, the fix is public and documented.
Furthermore, the Long-Term Support (LTS) releases, like the 3.7 LTS, offer five years of security maintenance. That perfectly maps to the CRA’s support requirements.
Zephyr also gives us the “West” tool. Using west spdx, we can generate an SBOM automatically during the build process. If you’ve ever tried to manually track every library and sub-component in a proprietary RTOS, you know that automated SBOM generation is a godsend. It takes the drudgery out of compliance.
However, this is the local engineer’s truth: upstream Zephyr is not the same thing as a shipping product.
Here is where the theory hits the floor. In our work sustaining Wi-Fi products for major global brands, where we manage fleets of over 10 million units, we’ve seen divergence as a major problem.
An engineer starts with a clean Zephyr LTS branch. Then, the silicon vendor provides a HAL (Hardware Abstraction Layer) that isn’t quite right for the specific power constraints of a Cortex-M4 gateway. So, the engineer tweaks the kernel. Then the marketing team requests a specific feature that requires a custom driver. Before you know it, you’ve forked the repo.
When a security patch comes down from the Zephyr upstream six months later, it doesn’t fit. It breaks your custom power management. It conflicts with your Wi-Fi driver. Now, compliance means a three-week rebase and a full regression test.
If you have a multi-SKU product line, maybe some devices use ARM and others use RISC-V, your vulnerability tracking turns into a nightmare. There are cases where a field-reported bug traced back to an unpatched erratum in a silicon vendor’s HAL. Because the team had drifted too far from the clean upstream code, they couldn’t pull the fix.Â
This kind of delay is exactly what the CRA will penalize.
The complexity doubles when you add tinyML. We’re seeing more industrial gear using TensorFlow Lite Micro on Zephyr to do predictive maintenance at the edge. These models are ultra-constrained. Every byte of RAM matters.
When you’re fighting for every kilobyte to make an AI model work on an IoT sensor, security overhead feels like an enemy. But under the CRA, that edge intelligence is part of the product’s digital footprint.
If your ML inference engine has a buffer overflow vulnerability, you are liable. Shoehorning these models into Zephyr while maintaining a secure, updatable bootloader (like MCUboot) requires a level of memory management that most teams aren’t prepared for.
So, how do we stop compliance from being a burden and turn it into a reason why customers choose you over a competitor? You have to treat security as a feature, not a chore.
The biggest mistake we see is that engineers treat Zephyr like a one-off download. You have to stay aligned with the LTS branches. We recommend a “cherry-pick” strategy. You pin your project to a stable LTS version and build a rigorous process for pulling in only the security patches you need. This keeps your custom “secret sauce” separate from the core RTOS plumbing.
If an auditor asks for your SBOM, you shouldn’t have to spend a week in Excel. We help our clients integrate SBOM tools directly into their CI/CD pipelines (like GitLab or GitHub Actions).Â
Every time a developer pushes code, the system should automatically run a vulnerability scan (using tools like grype or trivy) and generate a new SPDX file. If a vulnerability is found, the build should fail before the code ever reaches a device.
To handle the multi-SKU headache, we use Zephyr Device Tree overlays. Instead of having different codebases for different hardware, you keep one core application and use overlays to describe the hardware differences. This minimizes code drift and ensures that a security patch for your BLE stack works across every device in your catalog.
You can’t trust a simulation for CRA compliance. You need automated test rigs where real hardware is subjected to simulated exploits. At embedUR, we’ve built environments where we test everything from LTE stack vulnerabilities to timing glitches in crypto libraries.Â
This is how you catch a DoS (Denial of Service) bug before it gets found in the field and becomes a mandatory 24-hour report to the EU.
This is what we do. We aren’t a compliance consultancy that just hands you a PowerPoint. We are an engineering firm with over 400 expert embedded systems engineers who live in the kernel. Our architects have upstreamed code to Zephyr’s networking modules. We also know the silicon vendors—NXP, Infineon, Nordic, and Silicon Labs—and where their HALs usually break.
We have the sustainment framework ready to go. We handle the kernel upgrades, the CVE monitoring, and the SBOM maintenance so that your senior engineers can focus on the stuff that actually makes you money, like your next-gen predictive maintenance algorithms or your cloud-to-edge analytics.
The September 2026 deadline is closer than it looks on the calendar. In the world of embedded systems, eighteen months is one design cycle. If you start thinking about the CRA during the testing phase, you’ve already lost.
Is your Zephyr setup a solid foundation, or is it a house of cards? If you’re building for the EU market and worried about staying compliant without killing your product roadmap, let’s talk.
We can do a technical review of your current stack and show you exactly where the gaps are. We’ve been through the Wi-Fi wars and the IoT explosion; we can get you through this, too.
Let’s get your engineering team back to innovating. Schedule a Technical Review: Talk directly with our lead architects about your current Zephyr stack and CRA gaps.
In the embedded systems world, embedUR has spent the last twenty years in the trenches. We’ve built the wireless infrastructure that runs enterprise access points and the residential gateways sitting in millions of homes. In that time, we’ve learned one thing: regulatory shifts aren’t just legal problems. They are engineering problems.
The EU Cyber Resilience Act (CRA) is one of the biggest shifts we’ve seen in a decade. It isn’t just a footnote in a policy briefing; it’s a fundamental change in how we need to or should design, build, and most importantly, sustain products. At embedUR, we’ve guided teams through every Wi-Fi evolution from the early days of 802.11n to the complexities of Wi-Fi 6E and the new world of tinyML at the edge.
From where we stand, the CRA shouldn’t be a headache. It should be the catalyst that finally forces the industry to build smarter, more resilient systems.
But let’s be honest: for an engineering lead trying to hit a product launch date while staring down resource gaps, the CRA looks like a mountain of paperwork. To climb it, you have to bridge the gap between using an open-source RTOS like Zephyr and meeting the rigorous demands of European law.
We are currently in early 2026. The grace period is evaporating. The CRA was formally adopted back in late 2024, and the first major hammer will drop on September 11, 2026. That is the date when mandatory vulnerability reporting goes live.
If your device has a digital element and you sell it in the EU, you have 24 hours to report an exploited vulnerability. Not 24 hours after you fix it—24 hours after you find it.
By December 2027, the remaining requirements kick in: security-by-design as a legal mandate, machine-readable Software Bills of Materials (SBOMs), and a 5-year support window. If you miss these marks, the fines are eye-watering: up to €15 million or 2.5% of your global turnover. For any U.S. company exporting to Europe, which is a massive chunk of the global market, this is now the cost of doing business.
We’ve been working with Zephyr RTOS since its early releases in 2016. It’s under the Linux Foundation, it’s transparent, and it’s modular. On paper, it’s the perfect answer to the CRA.
Zephyr’s PSIRT (Product Security Incident Response Team) is excellent. They handle CVEs (Common Vulnerabilities and Exposures) with a level of transparency that mirrors the Linux kernel. When a bug is found in the networking stack, the fix is public and documented.
Furthermore, the Long-Term Support (LTS) releases, like the 3.7 LTS, offer five years of security maintenance. That perfectly maps to the CRA’s support requirements.
Zephyr also gives us the “West” tool. Using west spdx, we can generate an SBOM automatically during the build process. If you’ve ever tried to manually track every library and sub-component in a proprietary RTOS, you know that automated SBOM generation is a godsend. It takes the drudgery out of compliance.
However, this is the local engineer’s truth: upstream Zephyr is not the same thing as a shipping product.
Here is where the theory hits the floor. In our work sustaining Wi-Fi products for major global brands, where we manage fleets of over 10 million units, we’ve seen divergence as a major problem.
An engineer starts with a clean Zephyr LTS branch. Then, the silicon vendor provides a HAL (Hardware Abstraction Layer) that isn’t quite right for the specific power constraints of a Cortex-M4 gateway. So, the engineer tweaks the kernel. Then the marketing team requests a specific feature that requires a custom driver. Before you know it, you’ve forked the repo.
When a security patch comes down from the Zephyr upstream six months later, it doesn’t fit. It breaks your custom power management. It conflicts with your Wi-Fi driver. Now, compliance means a three-week rebase and a full regression test.
If you have a multi-SKU product line, maybe some devices use ARM and others use RISC-V, your vulnerability tracking turns into a nightmare. There are cases where a field-reported bug traced back to an unpatched erratum in a silicon vendor’s HAL. Because the team had drifted too far from the clean upstream code, they couldn’t pull the fix.Â
This kind of delay is exactly what the CRA will penalize.
The complexity doubles when you add tinyML. We’re seeing more industrial gear using TensorFlow Lite Micro on Zephyr to do predictive maintenance at the edge. These models are ultra-constrained. Every byte of RAM matters.
When you’re fighting for every kilobyte to make an AI model work on an IoT sensor, security overhead feels like an enemy. But under the CRA, that edge intelligence is part of the product’s digital footprint.
If your ML inference engine has a buffer overflow vulnerability, you are liable. Shoehorning these models into Zephyr while maintaining a secure, updatable bootloader (like MCUboot) requires a level of memory management that most teams aren’t prepared for.
So, how do we stop compliance from being a burden and turn it into a reason why customers choose you over a competitor? You have to treat security as a feature, not a chore.
The biggest mistake we see is that engineers treat Zephyr like a one-off download. You have to stay aligned with the LTS branches. We recommend a “cherry-pick” strategy. You pin your project to a stable LTS version and build a rigorous process for pulling in only the security patches you need. This keeps your custom “secret sauce” separate from the core RTOS plumbing.
If an auditor asks for your SBOM, you shouldn’t have to spend a week in Excel. We help our clients integrate SBOM tools directly into their CI/CD pipelines (like GitLab or GitHub Actions).Â
Every time a developer pushes code, the system should automatically run a vulnerability scan (using tools like grype or trivy) and generate a new SPDX file. If a vulnerability is found, the build should fail before the code ever reaches a device.
To handle the multi-SKU headache, we use Zephyr Device Tree overlays. Instead of having different codebases for different hardware, you keep one core application and use overlays to describe the hardware differences. This minimizes code drift and ensures that a security patch for your BLE stack works across every device in your catalog.
You can’t trust a simulation for CRA compliance. You need automated test rigs where real hardware is subjected to simulated exploits. At embedUR, we’ve built environments where we test everything from LTE stack vulnerabilities to timing glitches in crypto libraries.Â
This is how you catch a DoS (Denial of Service) bug before it gets found in the field and becomes a mandatory 24-hour report to the EU.
This is what we do. We aren’t a compliance consultancy that just hands you a PowerPoint. We are an engineering firm with over 400 expert embedded systems engineers who live in the kernel. Our architects have upstreamed code to Zephyr’s networking modules. We also know the silicon vendors—NXP, Infineon, Nordic, and Silicon Labs—and where their HALs usually break.
We have the sustainment framework ready to go. We handle the kernel upgrades, the CVE monitoring, and the SBOM maintenance so that your senior engineers can focus on the stuff that actually makes you money, like your next-gen predictive maintenance algorithms or your cloud-to-edge analytics.
The September 2026 deadline is closer than it looks on the calendar. In the world of embedded systems, eighteen months is one design cycle. If you start thinking about the CRA during the testing phase, you’ve already lost.
Is your Zephyr setup a solid foundation, or is it a house of cards? If you’re building for the EU market and worried about staying compliant without killing your product roadmap, let’s talk.
We can do a technical review of your current stack and show you exactly where the gaps are. We’ve been through the Wi-Fi wars and the IoT explosion; we can get you through this, too.
Let’s get your engineering team back to innovating. Schedule a Technical Review: Talk directly with our lead architects about your current Zephyr stack and CRA gaps.
In the embedded systems world, embedUR has spent the last twenty years in the trenches. We’ve built the wireless infrastructure that runs enterprise access points and the residential gateways sitting in millions of homes. In that time, we’ve learned one thing: regulatory shifts aren’t just legal problems. They are engineering problems.
The EU Cyber Resilience Act (CRA) is one of the biggest shifts we’ve seen in a decade. It isn’t just a footnote in a policy briefing; it’s a fundamental change in how we need to or should design, build, and most importantly, sustain products. At embedUR, we’ve guided teams through every Wi-Fi evolution from the early days of 802.11n to the complexities of Wi-Fi 6E and the new world of tinyML at the edge.
From where we stand, the CRA shouldn’t be a headache. It should be the catalyst that finally forces the industry to build smarter, more resilient systems.
But let’s be honest: for an engineering lead trying to hit a product launch date while staring down resource gaps, the CRA looks like a mountain of paperwork. To climb it, you have to bridge the gap between using an open-source RTOS like Zephyr and meeting the rigorous demands of European law.
We are currently in early 2026. The grace period is evaporating. The CRA was formally adopted back in late 2024, and the first major hammer will drop on September 11, 2026. That is the date when mandatory vulnerability reporting goes live.
If your device has a digital element and you sell it in the EU, you have 24 hours to report an exploited vulnerability. Not 24 hours after you fix it—24 hours after you find it.
By December 2027, the remaining requirements kick in: security-by-design as a legal mandate, machine-readable Software Bills of Materials (SBOMs), and a 5-year support window. If you miss these marks, the fines are eye-watering: up to €15 million or 2.5% of your global turnover. For any U.S. company exporting to Europe, which is a massive chunk of the global market, this is now the cost of doing business.
We’ve been working with Zephyr RTOS since its early releases in 2016. It’s under the Linux Foundation, it’s transparent, and it’s modular. On paper, it’s the perfect answer to the CRA.
Zephyr’s PSIRT (Product Security Incident Response Team) is excellent. They handle CVEs (Common Vulnerabilities and Exposures) with a level of transparency that mirrors the Linux kernel. When a bug is found in the networking stack, the fix is public and documented.
Furthermore, the Long-Term Support (LTS) releases, like the 3.7 LTS, offer five years of security maintenance. That perfectly maps to the CRA’s support requirements.
Zephyr also gives us the “West” tool. Using west spdx, we can generate an SBOM automatically during the build process. If you’ve ever tried to manually track every library and sub-component in a proprietary RTOS, you know that automated SBOM generation is a godsend. It takes the drudgery out of compliance.
However, this is the local engineer’s truth: upstream Zephyr is not the same thing as a shipping product.
Here is where the theory hits the floor. In our work sustaining Wi-Fi products for major global brands, where we manage fleets of over 10 million units, we’ve seen divergence as a major problem.
An engineer starts with a clean Zephyr LTS branch. Then, the silicon vendor provides a HAL (Hardware Abstraction Layer) that isn’t quite right for the specific power constraints of a Cortex-M4 gateway. So, the engineer tweaks the kernel. Then the marketing team requests a specific feature that requires a custom driver. Before you know it, you’ve forked the repo.
When a security patch comes down from the Zephyr upstream six months later, it doesn’t fit. It breaks your custom power management. It conflicts with your Wi-Fi driver. Now, compliance means a three-week rebase and a full regression test.
If you have a multi-SKU product line, maybe some devices use ARM and others use RISC-V, your vulnerability tracking turns into a nightmare. There are cases where a field-reported bug traced back to an unpatched erratum in a silicon vendor’s HAL. Because the team had drifted too far from the clean upstream code, they couldn’t pull the fix.Â
This kind of delay is exactly what the CRA will penalize.
The complexity doubles when you add tinyML. We’re seeing more industrial gear using TensorFlow Lite Micro on Zephyr to do predictive maintenance at the edge. These models are ultra-constrained. Every byte of RAM matters.
When you’re fighting for every kilobyte to make an AI model work on an IoT sensor, security overhead feels like an enemy. But under the CRA, that edge intelligence is part of the product’s digital footprint.
If your ML inference engine has a buffer overflow vulnerability, you are liable. Shoehorning these models into Zephyr while maintaining a secure, updatable bootloader (like MCUboot) requires a level of memory management that most teams aren’t prepared for.
So, how do we stop compliance from being a burden and turn it into a reason why customers choose you over a competitor? You have to treat security as a feature, not a chore.
The biggest mistake we see is that engineers treat Zephyr like a one-off download. You have to stay aligned with the LTS branches. We recommend a “cherry-pick” strategy. You pin your project to a stable LTS version and build a rigorous process for pulling in only the security patches you need. This keeps your custom “secret sauce” separate from the core RTOS plumbing.
If an auditor asks for your SBOM, you shouldn’t have to spend a week in Excel. We help our clients integrate SBOM tools directly into their CI/CD pipelines (like GitLab or GitHub Actions).Â
Every time a developer pushes code, the system should automatically run a vulnerability scan (using tools like grype or trivy) and generate a new SPDX file. If a vulnerability is found, the build should fail before the code ever reaches a device.
To handle the multi-SKU headache, we use Zephyr Device Tree overlays. Instead of having different codebases for different hardware, you keep one core application and use overlays to describe the hardware differences. This minimizes code drift and ensures that a security patch for your BLE stack works across every device in your catalog.
You can’t trust a simulation for CRA compliance. You need automated test rigs where real hardware is subjected to simulated exploits. At embedUR, we’ve built environments where we test everything from LTE stack vulnerabilities to timing glitches in crypto libraries.Â
This is how you catch a DoS (Denial of Service) bug before it gets found in the field and becomes a mandatory 24-hour report to the EU.
This is what we do. We aren’t a compliance consultancy that just hands you a PowerPoint. We are an engineering firm with over 400 expert embedded systems engineers who live in the kernel. Our architects have upstreamed code to Zephyr’s networking modules. We also know the silicon vendors—NXP, Infineon, Nordic, and Silicon Labs—and where their HALs usually break.
We have the sustainment framework ready to go. We handle the kernel upgrades, the CVE monitoring, and the SBOM maintenance so that your senior engineers can focus on the stuff that actually makes you money, like your next-gen predictive maintenance algorithms or your cloud-to-edge analytics.
The September 2026 deadline is closer than it looks on the calendar. In the world of embedded systems, eighteen months is one design cycle. If you start thinking about the CRA during the testing phase, you’ve already lost.
Is your Zephyr setup a solid foundation, or is it a house of cards? If you’re building for the EU market and worried about staying compliant without killing your product roadmap, let’s talk.
We can do a technical review of your current stack and show you exactly where the gaps are. We’ve been through the Wi-Fi wars and the IoT explosion; we can get you through this, too.
Let’s get your engineering team back to innovating. Schedule a Technical Review: Talk directly with our lead architects about your current Zephyr stack and CRA gaps.
In the embedded systems world, embedUR has spent the last twenty years in the trenches. We’ve built the wireless infrastructure that runs enterprise access points and the residential gateways sitting in millions of homes. In that time, we’ve learned one thing: regulatory shifts aren’t just legal problems. They are engineering problems.
The EU Cyber Resilience Act (CRA) is one of the biggest shifts we’ve seen in a decade. It isn’t just a footnote in a policy briefing; it’s a fundamental change in how we need to or should design, build, and most importantly, sustain products. At embedUR, we’ve guided teams through every Wi-Fi evolution from the early days of 802.11n to the complexities of Wi-Fi 6E and the new world of tinyML at the edge.
From where we stand, the CRA shouldn’t be a headache. It should be the catalyst that finally forces the industry to build smarter, more resilient systems.
But let’s be honest: for an engineering lead trying to hit a product launch date while staring down resource gaps, the CRA looks like a mountain of paperwork. To climb it, you have to bridge the gap between using an open-source RTOS like Zephyr and meeting the rigorous demands of European law.
We are currently in early 2026. The grace period is evaporating. The CRA was formally adopted back in late 2024, and the first major hammer will drop on September 11, 2026. That is the date when mandatory vulnerability reporting goes live.
If your device has a digital element and you sell it in the EU, you have 24 hours to report an exploited vulnerability. Not 24 hours after you fix it—24 hours after you find it.
By December 2027, the remaining requirements kick in: security-by-design as a legal mandate, machine-readable Software Bills of Materials (SBOMs), and a 5-year support window. If you miss these marks, the fines are eye-watering: up to €15 million or 2.5% of your global turnover. For any U.S. company exporting to Europe, which is a massive chunk of the global market, this is now the cost of doing business.
We’ve been working with Zephyr RTOS since its early releases in 2016. It’s under the Linux Foundation, it’s transparent, and it’s modular. On paper, it’s the perfect answer to the CRA.
Zephyr’s PSIRT (Product Security Incident Response Team) is excellent. They handle CVEs (Common Vulnerabilities and Exposures) with a level of transparency that mirrors the Linux kernel. When a bug is found in the networking stack, the fix is public and documented.
Furthermore, the Long-Term Support (LTS) releases, like the 3.7 LTS, offer five years of security maintenance. That perfectly maps to the CRA’s support requirements.
Zephyr also gives us the “West” tool. Using west spdx, we can generate an SBOM automatically during the build process. If you’ve ever tried to manually track every library and sub-component in a proprietary RTOS, you know that automated SBOM generation is a godsend. It takes the drudgery out of compliance.
However, this is the local engineer’s truth: upstream Zephyr is not the same thing as a shipping product.
Here is where the theory hits the floor. In our work sustaining Wi-Fi products for major global brands, where we manage fleets of over 10 million units, we’ve seen divergence as a major problem.
An engineer starts with a clean Zephyr LTS branch. Then, the silicon vendor provides a HAL (Hardware Abstraction Layer) that isn’t quite right for the specific power constraints of a Cortex-M4 gateway. So, the engineer tweaks the kernel. Then the marketing team requests a specific feature that requires a custom driver. Before you know it, you’ve forked the repo.
When a security patch comes down from the Zephyr upstream six months later, it doesn’t fit. It breaks your custom power management. It conflicts with your Wi-Fi driver. Now, compliance means a three-week rebase and a full regression test.
If you have a multi-SKU product line, maybe some devices use ARM and others use RISC-V, your vulnerability tracking turns into a nightmare. There are cases where a field-reported bug traced back to an unpatched erratum in a silicon vendor’s HAL. Because the team had drifted too far from the clean upstream code, they couldn’t pull the fix.Â
This kind of delay is exactly what the CRA will penalize.
The complexity doubles when you add tinyML. We’re seeing more industrial gear using TensorFlow Lite Micro on Zephyr to do predictive maintenance at the edge. These models are ultra-constrained. Every byte of RAM matters.
When you’re fighting for every kilobyte to make an AI model work on an IoT sensor, security overhead feels like an enemy. But under the CRA, that edge intelligence is part of the product’s digital footprint.
If your ML inference engine has a buffer overflow vulnerability, you are liable. Shoehorning these models into Zephyr while maintaining a secure, updatable bootloader (like MCUboot) requires a level of memory management that most teams aren’t prepared for.
So, how do we stop compliance from being a burden and turn it into a reason why customers choose you over a competitor? You have to treat security as a feature, not a chore.
The biggest mistake we see is that engineers treat Zephyr like a one-off download. You have to stay aligned with the LTS branches. We recommend a “cherry-pick” strategy. You pin your project to a stable LTS version and build a rigorous process for pulling in only the security patches you need. This keeps your custom “secret sauce” separate from the core RTOS plumbing.
If an auditor asks for your SBOM, you shouldn’t have to spend a week in Excel. We help our clients integrate SBOM tools directly into their CI/CD pipelines (like GitLab or GitHub Actions).Â
Every time a developer pushes code, the system should automatically run a vulnerability scan (using tools like grype or trivy) and generate a new SPDX file. If a vulnerability is found, the build should fail before the code ever reaches a device.
To handle the multi-SKU headache, we use Zephyr Device Tree overlays. Instead of having different codebases for different hardware, you keep one core application and use overlays to describe the hardware differences. This minimizes code drift and ensures that a security patch for your BLE stack works across every device in your catalog.
You can’t trust a simulation for CRA compliance. You need automated test rigs where real hardware is subjected to simulated exploits. At embedUR, we’ve built environments where we test everything from LTE stack vulnerabilities to timing glitches in crypto libraries.Â
This is how you catch a DoS (Denial of Service) bug before it gets found in the field and becomes a mandatory 24-hour report to the EU.
This is what we do. We aren’t a compliance consultancy that just hands you a PowerPoint. We are an engineering firm with over 400 expert embedded systems engineers who live in the kernel. Our architects have upstreamed code to Zephyr’s networking modules. We also know the silicon vendors—NXP, Infineon, Nordic, and Silicon Labs—and where their HALs usually break.
We have the sustainment framework ready to go. We handle the kernel upgrades, the CVE monitoring, and the SBOM maintenance so that your senior engineers can focus on the stuff that actually makes you money, like your next-gen predictive maintenance algorithms or your cloud-to-edge analytics.
The September 2026 deadline is closer than it looks on the calendar. In the world of embedded systems, eighteen months is one design cycle. If you start thinking about the CRA during the testing phase, you’ve already lost.
Is your Zephyr setup a solid foundation, or is it a house of cards? If you’re building for the EU market and worried about staying compliant without killing your product roadmap, let’s talk.
We can do a technical review of your current stack and show you exactly where the gaps are. We’ve been through the Wi-Fi wars and the IoT explosion; we can get you through this, too.
Let’s get your engineering team back to innovating. Schedule a Technical Review: Talk directly with our lead architects about your current Zephyr stack and CRA gaps.
2024 was a defining year for the Internet of Things (IoT). By the end of 2024, we had more than 18.8 billion connected devices across the globe. These devices evolved into problem-solvers; streamlining operations, improving efficiency, and introducing capabilities that seemed out of reach just a few years ago.
In manufacturing, IoT sensors enabled predictive maintenance, allowing machines to signal when repairs were needed before a breakdown could occur, saving millions in downtime and repair costs. Healthcare witnessed a revolution with real-time patient monitoring, empowering doctors to catch warning signs early and provide better, data-driven care. Retailers used IoT to track inventory, optimize supply chains, and enhance customer experiences, while cities began rolling out smarter infrastructures to address traffic congestion and energy consumption.
Behind these advancements were critical technology enablers. Edge computing gave IoT devices the ability to process data locally, making faster decisions without relying solely on the cloud. Artificial intelligence (AI) enabled IoT devices to become more intelligent, learning user habits, predicting needs, and adapting to changing conditions.
Meanwhile, the expansion of 5G and improved Wi-Fi technology made it possible to connect devices in previously unreachable locations, such as remote farms and deep industrial sites. Advances in chips, sensors, and battery technology further pushed the boundaries, allowing devices to perform complex tasks with greater efficiency and longevity.
However, this explosive growth was not without some challenges. The rise in connected devices brought pressing concerns: safeguarding user data, ensuring interoperability among different devices, and finding ways to handle the tidal wave of information these devices generate. Addressing these issues demanded innovation, collaboration, and new standards, and while progress was made, the journey is far from over.
IoT Tomorrow: Predictions for 2025
In 2025, the momentum only builds. What breakthroughs and shifts lie ahead? What trends will define IoT this year? Let’s explore the possibilities and challenges shaping the next phase of this technology revolution.
1. AI Integration in IoT will Explode
In 2025, AI is expected to transform IoT devices into truly intuitive systems capable of anticipating and adapting to user needs. At the recently concluded 2025 Consumer Electronics Show (CES), we saw significant progress in this direction. Synaptics unveiled its Astra IoT platform, a scalable embedded computing solution designed for multimodal Edge AI workloads.
This platform simplifies Edge AI application development across consumer, enterprise, and industrial markets by combining purpose-built hardware with open-source software. Their focus was on privacy-conscious solutions that process sensitive data locally, boosting security, reducing latency, and enabling real-time decision-making. Here is a video Interview with Synaptics at CES 2025.
Silicon Labs also made a great impression at CES 2025 with its innovations in wireless connectivity and its integration with AI tools. Their next-generation SoCs are designed to support AI-driven IoT devices that can make autonomous decisions while ensuring interoperability across protocols. These developments reflect how silicon vendors are creating the building blocks for smarter, more capable IoT devices.
Looking ahead to the 2025 Embedded World Conference, we’re expecting to see even more exciting progress. It’s been about two years since silicon vendors started focusing on AI chips, and now there are more of them available. At the event, we’ll likely see these chips being tested and showcased, giving us a clear idea of how far the technology has come and what it can do for AI-powered IoT devices.
2. Integration of IoT Sensing and CCTV Technologies
Looking ahead to 2025, IoT sensors, which monitor environmental factors such as temperature, light, or pressure, and smart cameras are set to work together more closely than ever, reshaping how we think about safety and efficiency in smart cities. Cameras powered by AI are expected to do much more than just record.
They will analyze situations in real time, detecting issues like traffic jams or suspicious activities such as loitering in restricted areas and triggering automated responses and alerts. For instance, they could streamline traffic management or enhance public safety by immediately notifying authorities of potential incidents.
IoT sensors are also advancing with onboard image processing capabilities. This allows them to capture and process visual data, sending only precise and streamlined information over low-power networks. This reduces network congestion while improving the speed and accuracy of communication. Together, these technologies promise smarter, more responsive smart cities where systems operate in unison to enhance situational awareness and overall functionality.
3. Network Consolidation and Hybrid Connectivity
In 2025, organizations looking to implement smart solutions will face a more streamlined approach to connectivity. The wide variety of network technologies and devices that have cluttered the market will start to consolidate, making it easier to adopt and scale IoT systems.
Fragmentation in network options has been a challenge for businesses, but recent developments, such as AT&T decommissioning its NB-IoT network in the US in favor of newer technologies like LTE-M, signal a shift towards more unified solutions. However, NB-IoT will continue to play a crucial role in certain regions, such as the UK, where it may work alongside other networks.
Additionally, LoRaWAN technology will remain a flexible and cost-effective option for smart city projects and smart buildings, where local control and service delivery are critical. In 2025, we can expect an acceleration of collaboration among managed LoRaWAN service providers, bringing about better integration and network sharing.
Hybrid connectivity models will also gain traction, combining the strengths of different network types, like cellular and LoRaWAN, to deliver reliable and consistent performance, reducing risks and enabling broader adoption of smart solutions.
4. Transition to Zero-trust Security
Businesses are increasingly integrating IT and IoT networks to improve operations and gain valuable insights. As this convergence expands, a unified security approach becomes crucial, with a growing emphasis on applying zero-trust principles across all networks.
Zero Trust frameworks require a shift towards continuous verification of every device and user. While the core principles of Zero Trust should be consistent, implementation will likely need to be tailored to the specific requirements and constraints of each environment. Although the initial implementation of Zero Trust can involve investment, it offers the potential for long-term efficiencies and cost savings by reducing security risks and improving overall security posture.
There will also be a growing emphasis on securing IoT devices from the outset. While IoT security has been a widely discussed priority for years, the rapid pace of IoT adoption often left security playing catch-up to innovation. In many cases, tight development timelines and cost constraints led to security being treated as an afterthought.
However, with the increasing sophistication of cyber threats and the rising cost of breaches, businesses are now recognizing that robust security must be embedded throughout the device development process, from concept to deployment. This shift reflects a maturing perspective on the balance between innovation and risk management.
Looking ahead, regular risk assessments and network penetration testing will become increasingly routine as organizations seek to maintain a clear and accurate understanding of their security posture. This ongoing evaluation will be essential in ensuring that businesses can minimize vulnerabilities and reduce exposure.
5. Service Evolution
As IoT adoption grows, businesses often face challenges in maintaining consistent services and use cases across diverse applications. These challenges stem from solutions that remain siloed, lack scalability, or fail to integrate effectively.
However, in 2025, we expect to see a shift from fragmented IoT services to more unified services that prioritize consistency, scalability, and interoperability across industries. This transformation will be driven by the development of interoperable connectivity platforms, unified device management systems, and comprehensive security frameworks.
To illustrate the difference, here’s a comparison between fragmented and unified IoT services:
| FRAGMENTED IOT SERVICES | UNIFIED IOT SERVICES |
|---|---|
|
Solutions are isolated, with limited scalability across devices
|
Interoperable platforms enable seamless scaling across industries
|
|
Data is siloed and fragmented, reducing actionable insights
|
Unified systems aggregate data for advanced BI, analytics, and AI/ML
|
|
Devices are managed individually, creating inefficiencies
|
Centralized platforms streamline unified management of all devices
|
|
Ad-hoc security measures; inconsistent enforcement
|
Comprehensive frameworks enforce policies consistently across all IoT
|
|
Difficult to demonstrate ROI due to inefficiencies
|
Clear ROI from consistent, reliable, and efficient services
|
These advancements will help organizations reduce duplication of efforts, improve security, and enhance operational efficiency. Managing IoT ecosystems will become simpler, more secure, and more effective, enabling businesses to deliver consistent service quality while demonstrating clear cost-to-benefit ratios.
In Summary
The trends we’ve explored—AI in IoT, the integration of IoT and CCTV technologies, the consolidation of networks, security, and the maturation of service delivery are all interconnected developments that will drive the next transformation phase. These innovations point to a more unified, efficient, and intelligent world where connectivity, data, and decision-making converge to create smarter solutions across industries.
The fusion of IoT and AI will enable smarter, real-time decision-making, helping cities manage traffic more efficiently and businesses monitor equipment before a breakdown occurs. The increasing integration of network technologies, alongside the growth of hybrid connectivity models, will give way to greater flexibility, reliability, and scalability for organizations deploying smart solutions.
And while the journey toward seamless, mature IoT services continues, 2025 will see businesses benefit from more consistent and standardized service delivery. This will be powered by improved connectivity platforms, better device management, and stronger security frameworks.
If you are navigating the world of Edge AI and building intelligent devices, platforms like ModelNova are leading the way by making the development of Edge AI devices more accessible the same way the no-code platforms did for software development.Â
Launched in 2024, ModelNova has already become an invaluable tool for developers, with over 50 pre-trained models designed for low-power hardware platforms. Whether you’re working on AI vision, sound, or speech recognition, ModelNova can simplify the traditionally complex process of selecting, adapting, and deploying AI models on edge devices.Â
This acceleration in prototyping and deployment will empower businesses to bring intelligent applications to life faster than ever and bridge the gap between innovation and real-world deployment. Read more on the building blocks of IoT and learn all about the foundations of a connected world.
IoT devices have evolved from simple data collectors into intelligent systems, leveraging technologies like Edge AI to process data locally. This shift has enabled faster decision-making, greater autonomy, and new functionality for various sectors, such as healthcare and industrial automation.
Central to this growth is the connectivity framework underpinning IoT ecosystems. While there are various connectivity standards like cellular networks, low-power wide-area networks (LPWAN), and wireless protocols such as Wi-Fi, Zigbee, and Z-Wave, Wi-Fi remains one of the most widely used, powering over 31% of global IoT connections.
Wi-Fi’s importance continues to grow with advancements like Wi-Fi 6E, which delivered faster speeds, lower latency, and greater energy efficiency to more than 473 million IoT devices shipped in 2023.
Now, with the rollout of Wi-Fi 7 in 2024, IoT applications will benefit from even higher performance, making it possible to support demanding use cases like advanced Edge AI processing and real-time automation. These innovations are setting the stage for the next wave of IoT growth.
Historical Development of Wi-Fi
Wi-Fi has been instrumental in the growth of IoT technology. Early IoT solutions used Wi-Fi primarily for its ubiquity, high data rate, and ease of deployment. However, these initial implementations often faced limitations like network congestion, high power consumption, and inconsistent performance in dense device environments.
Now, Wi-Fi has undergone significant evolution, transitioning from Wi-Fi 4 and Wi-Fi 5 to Wi-Fi 6, 6E, and now Wi-Fi 7. Each new generation has introduced features designed to enhance IoT performance.
Evolution of Wi-Fi Generations
| Wi-Fi Generation | Year Introduced | Key Features |
|---|---|---|
|
Wi-Fi 4 (802.11n)
|
2009
|
MIMO (Multiple Input Multiple Output) for improved signal reliability and range, suitable for IoT.
|
|
Wi-Fi 5 (802.11ac)
|
2014
|
MU-MIMO (Multi-User MIMO) for simultaneous connections, reducing device power consumption in IoT applications.
|
|
Wi-Fi HaLow (802.11ah)
|
2016
|
Operates in sub-1 GHz bands for long-range, low-power communication. Ideal for battery-operated IoT in industrial and agricultural settings.
|
|
Wi-Fi 6 (802.11ax)
|
2019
|
OFDMA for efficient multi-device communication, minimizing power usage. Target Wake Time (TWT) for extended IoT device battery life.
|
|
Wi-Fi 6E
|
2020
|
Access to the 6 GHz spectrum, reducing interference and enhancing IoT efficiency. Retains TWT for optimized power management.
|
|
Wi-Fi 7 (802.11be)
|
2024
|
Multi-Link Operation (MLO) for seamless multi-band communication, reducing power usage. Advanced interference management for battery-powered IoT applications.
|
Impact on IoT Devices
Advances in Wi-Fi technology are transforming the capabilities of IoT and enabling them to operate more efficiently. Let’s explore the impact Wi-Fi has on IoT devices:
1. Solving the Latency Challenge for Real-Time Intelligence
Low latency, or the delay in data communication, is a critical factor in edge AI applications where precision and timing are essential. Wi-Fi 7 introduces deterministic latency, a feature designed to deliver minimal delays. While not the sole solution, it provides a robust framework for applications that demand reliable, real-time performance.
For example, autonomous drones inspecting power lines or bridges can greatly benefit from these advancements. As these devices roam across coverage areas, environmental factors such as obstacles and interference may affect the performance of certain frequency bands.
Wi-Fi 7’s Multi-Link Operation (MLO) enables seamless transitions between bands, ensuring uninterrupted connectivity. This allows drones to adapt dynamically to changing conditions, maintaining reliable communication even in challenging environments.
It’s important to note that real-time performance in edge AI devices also depends on the broader ecosystem, such as optimized hardware, software algorithms, and complementary connectivity protocols. Together, these elements enable the low-latency, reliable operations demanded by modern IoT applications.
2. Enhanced Network Capacity for Dense IoT Deployments
As IoT networks become denser, especially in industrial settings, handling a large number of connected devices within the same environment is a critical challenge. Wi-Fi 6E and Wi-Fi 7 address this challenge not just through wider bandwidth channels but also through advanced technologies designed for more efficient handling of multiple devices.
While wider communication channels (160 MHz in Wi-Fi 6E and up to 320 MHz in Wi-Fi 7) help with data-heavy applications, technologies like Orthogonal Frequency-Division Multiple Access (OFDMA) and Target Wake Time (TWT) are more directly responsible for optimizing the capacity to handle many devices.
These features allow Wi-Fi networks to support simultaneous communication between numerous devices without congestion, ensuring reliable performance even in environments with high device density.
For example, in a smart city, where traffic sensors, Wi-Fi hotspots, and connected surveillance cameras operate side by side, Wi-Fi’s ability to efficiently manage this large number of devices allows for uninterrupted data flow, even during peak usage.
Similarly, industrial IoT networks, such as those in factories with autonomous robots and predictive maintenance sensors, can rely on Wi-Fi to enable real-time data sharing without compromising performance.
This shift towards greater efficiency, coupled with advancements in multi-user support and seamless coordination across devices, ensures that Wi-Fi is an ideal choice for high-density IoT deployments, particularly in urban environments.
3. Power Efficiency
Power efficiency is a critical challenge for IoT devices, especially those deployed in resource-constrained environments where battery replacement or frequent maintenance is impractical. Modern Wi-Fi advancements address this issue by introducing innovative strategies and chipsets tailored for ultra-low power consumption.
An example is Silicon Labs’ new SiWx917 ultra-low-power WiFi 6 IoT chipset, which delivers significant improvements in energy efficiency, enabling battery life of up to two years in specific IoT applications.
This chipset integrates Target Wake Time (TWT), a feature that schedules communication intervals for devices, minimizing energy use during idle periods.
By reducing unnecessary network activity, TWT optimizes the power consumption of IoT devices like environmental sensors and wearable health monitors. The SiWx917 also includes advanced features such as a Cortex-M4 processor for on-device processing, reducing reliance on external compute resources and saving additional power.
Synergy Between Wi-Fi and Other IoT Connectivity Protocols
The IoT ecosystem thrives on connectivity diversity, with each protocol carving its niche to meet the unique demands of different applications. While Wi-Fi has earned its reputation as a backbone for high-bandwidth, low-latency environments, it does not operate in isolation.
Instead, it functions as part of a multi-technology ecosystem, complementing other protocols like Zigbee, Bluetooth, cellular networks, and LPWAN to address diverse IoT challenges.
Wi-Fi and Cellular: Powering Mobile and Large-Scale IoT
Cellular technologies like LTE-M and 5G offer unmatched wide-area coverage, mobility, and the ability to keep IoT devices “on the grid.” They are essential for applications such as connected vehicles, remote asset tracking, and large-scale smart city deployments. Wi-Fi, on the other hand, excels at localized high-speed data transfer, making it an effective complement to cellular networks.
In hybrid scenarios, devices use cellular connectivity for persistent tracking and visibility, switching to Wi-Fi when available to handle large amounts of data efficiently.
Applications include:
Wi-Fi and Zigbee: Collaboration in Smart Homes
Hybrid smart home systems use Zigbee for efficient local communication and Wi-Fi for seamless internet access, ensuring robust functionality with balanced power efficiency and speed.
Zigbee, a low-power, mesh networking protocol, is a popular choice for applications requiring long battery life and reliable operation across multiple nodes, such as smart lighting and home automation systems. Wi-Fi, on the other hand, delivers the bandwidth needed for streaming video feeds from security cameras or managing cloud-connected devices.
In smart home ecosystems, hybrid solutions often leverage the strengths of both technologies. For example, a Zigbee-enabled smart thermostat might communicate locally with sensors and switches while also using Wi-Fi for remote access via a smartphone app.
Some devices act as bridges, seamlessly speaking both Zigbee and Wi-Fi to connect low-power local networks with the broader internet. This synergy balances power efficiency and high-speed data transfer, ensuring robust functionality without compromising battery life.
Wi-Fi and Bluetooth: For Proximity-Based Applications
Bluetooth is synonymous with short-range, low-power communication, making it ideal for wearable devices, beacons, and proximity-based IoT use cases. Bluetooth Low Energy (BLE) beacons have been used in retail to guide customers with personalized offers based on their location within a store.Â
However, while initially touted as transformative, their adoption has been uneven. Challenges like privacy concerns, the need for dedicated apps, and competition from technologies such as Wi-Fi have limited their widespread impact.Â
Even so, they remain valuable in niche retail applications, such as inventory management and targeted engagement in loyalty programs. Wi-Fi complements Bluetooth in such scenarios by supporting analytics platforms and transmitting aggregated data to centralized servers.
Wi-Fi and LPWAN: For Long-Range, Low-Power Needs
Low-Power Wide-Area Networks (LPWAN) protocols like LoRaWAN and NB-IoT excel in applications requiring long-range communication and low power consumption, such as environmental monitoring, asset tracking, and smart agriculture. These protocols are ideal for deploying IoT devices in remote areas where power sources are scarce and cellular connectivity may be unreliable. Wi-Fi integrates with LPWAN systems by acting as a gateway between localized IoT deployments and cloud platforms.Â
LoRaWAN-enabled soil sensors gather data on parameters like moisture and temperature across the field. These sensors transmit their data using low-power, long-range LoRaWAN connectivity to a central Wi-Fi gateway, strategically placed within range.
The Wi-Fi gateway processes and forwards the data to a cloud-based analytics platform via a Wi-Fi connection. This hybrid approach leverages LoRaWAN for energy efficiency and extended battery life in field sensors, while Wi-Fi ensures high-speed, reliable transmission of aggregated data for real-time decision-making and insights.
Making IoT Work with embedUR
Wi-Fi has come a long way, evolving from a simple connectivity solution to a critical enabler of modern IoT ecosystems.
With the introduction of Wi-Fi 7, network congestion, latency, and energy efficiency issues are finally being addressed, creating new opportunities for smarter, faster, and more reliable IoT applications. However, technology alone is not enough. Success in IoT depends on making all the pieces work together seamlessly.
That’s where embedUR comes in. For over 20 years, we’ve been driving innovation in IoT connectivity, building the firmware and protocols that power some of the most advanced devices in the industry.
We understand that IoT is not just about getting devices to connect—it’s about making them perform reliably in real-world conditions. Our team specializes in tackling the tough challenges of wireless connectivity, helping companies like yours bring innovative, scalable IoT products to market.
If you’re ready to move beyond off-the-shelf solutions and need a partner who knows how to make IoT work, let’s talk. embedUR can help turn your vision into reality, ensuring your products are not just ready for today’s challenges but built to lead tomorrow’s market. Did you like this post? Then you’ll love reading about all the non-data transmission uses of Wi-Fi.
