Wireless SoC Selection

Wireless SoCs Chosen by Protocol

A wireless SoC is a single chip that puts a radio and a microcontroller on the same die, so one part runs the application code and drives the radio link itself. The choice between these parts runs through the protocol first, because the radio is built for a standard and the standard is set by what the device has to talk to. A sensor that reports to a phone, a lock that joins a smart-home network, a meter that reaches a gateway a kilometer off: each names a protocol before it names a part, and the protocol narrows the field to a handful of vendors who do that radio well, and the rest of the selection happens inside that narrowed set.

Start from what the device has to talk to

The protocol is fixed before the part is, because it is set outside the design. A wearable that pairs with a phone speaks Bluetooth Low Energy, since that is what the phone speaks; there is no trade study to run on the link itself. The job there is to pick the part that carries BLE at the right power and price, and choosing the host that runs it is its own piece of work, the kind the wider question of replacing a separate radio and host with one wireless MCU takes up once the radio is settled.

Where the device sets its own network, the protocol opens up. A smart-home product chooses among Bluetooth Mesh, Zigbee, and Thread, and that choice leans on the ecosystem it has to join more than on the radio itself. A field sensor reporting to a distant gateway looks instead at range and battery life, which points away from the short-range radios entirely and toward a sub-gigahertz link.

A second axis sits under the protocol, which is power. A coin-cell sensor that has to last years rules out a radio that cannot sleep at microamp levels between short wake-ups, and that constraint alone removes whole families before any feature is compared. The duty cycle the product can live with, how often it has to talk and how briefly, shapes the part as firmly as the standard does. A mains-powered hub can run a radio that never sleeps; a sensor on a button cell cannot, and the two end up on different families even when both speak the same protocol.

In practice the protocol picks the vendor as much as the part it points to.

Each radio standard has a short list of vendors who have shipped it long enough to have stable silicon, a stack that holds up in the field, and the regional certifications already passed on their modules. The protocol decision quietly hands the design to one corner of the market before a single part number is compared, so naming the standard early is what sets the shortlist that follows.

The parts that own each protocol

WiFi and Bluetooth in one inexpensive part is Espressif territory, and comparing and selecting within the ESP32 family is a routine first step for a connected consumer device, since the family spans a single core with WiFi up to multi-core parts with more memory and radio options. For on-device signal work next to the radio, the ESP32-S3 AI acceleration and its workloads cover wake-word detection and light vision jobs that ride along with the connectivity, the kind of load that used to need a second chip.

For BLE at low power, Nordic sets the pace. Choosing among the Nordic nRF52, nRF53, and nRF54 is the path the bulk of battery BLE designs walk, across a generational span that trades current draw, processing, and price, and the SoftDevice stack carries from one generation to the next so the firmware investment moves with it. Where a product needs to speak more than one short-range standard from a single part, the Silicon Labs EFR32 multiprotocol value is that one radio runs BLE, Zigbee, and Thread, which suits a smart-home device that has to bridge networks or switch the role it plays on them.

Long range at low power calls for a different radio, and LoRa is the common answer. The Semtech SX1276 standing as the LoRa default rests on years of deployed networks and a known design path, while the SX1262 improvements over the SX1276 lower the current draw and widen the band coverage for a new design that carries no legacy baggage. On the TI side the split runs by part, and the current adoption of the TI CC2640 and CC2652 tracks two different jobs: the CC2640 is a single-mode BLE part, while the multiprotocol CC2652 adds Zigbee and Thread on the same die. Both stay steady across remotes, sensors, and gateways where TI’s tooling is already in the building. A choice like that often turns on what a team has shipped before, since a known toolchain and a working driver base shorten a schedule more than a small spec advantage on a fresh part would.

The pattern under all of this is that each protocol grew a default part, and that part carries the certified stack and the reference designs the standard needs. That body of proven work is the real reason a design follows the protocol to its usual vendor instead of starting the radio from scratch. A radio stack is hard to get right and harder to certify, so inheriting a vendor’s tested one removes months of risk that never appears on the bill of materials. The cost of leaving the default shows up as engineering time, not part price.

Reading the protocol trade honestly

The protocol map keeps moving, and two of the choices on it reward a slow read rather than a glance at a slide table. The first is when a design should step up to WiFi 6. Knowing when to move to a Wi-Fi 6 module matters because the gain shows up in a crowded radio environment, many devices contending for the same air, far more than on a quiet link where an older WiFi generation carries the traffic at a lower part cost. A camera in a busy building benefits; a thermostat checking in once a minute does not, and paying for the newer radio there buys nothing the product can use. The same reading applies to the antenna and the regulatory work the newer band brings, which scale with the radio rather than with the feature list.

The second is the mesh question that sits under a large share of smart-home builds, and it is the one to read carefully. The honest framing of choosing between Bluetooth Mesh and Zigbee is less about the radios, which overlap on range and power, and more about the network a product must live in. Zigbee carries a long history of interoperable lighting and sensor gear and the hubs that go with it, so a device joining that world inherits a proven ecosystem. Bluetooth Mesh lets a device commission straight from a phone without a separate hub, a real saving for a product meant to skip the gateway. A team that picks on the radio specification alone often meets the ecosystem gap during integration, after the part is on the board and the firmware is half written. Thread complicates the call further, since it shares the same 802.15.4 radio as Zigbee but carries IP to the device and now underpins much of Matter, so a part chosen today may need to run a stack that did not exist when the silicon was designed. A multiprotocol SoC hedges that risk, letting one radio be reflashed for the standard that wins the socket rather than betting the board on a single stack.

Reading these two trades against the device’s real conditions, the radio traffic it lives in and the network it joins, keeps a design off a protocol that demos well and fits badly. The standard a product speaks tends to outlive the other parts around it, since a deployed network and its installed base are slow to change, so the protocol is the decision to get right before any silicon is chosen. Get it wrong and the fix is rarely a part swap; it is a redesign of the radio and often the firmware stack on top of it.

The cost the datasheet does not show

A wireless part carries a cost no electrical specification lists, which is certification. Working out the FCC, CE, and SRRC certification costs for a wireless module belongs in the part decision from the start, because intentional radiators face testing in every market a product ships to, and the bill and the schedule can outweigh the difference in chip price several times over. A part that saves a little on the line item can lose that saving back at the test lab, and then some. SRRC approval for the China market and the separate FCC and CE paths each carry their own test campaigns, and an intentional radiator cannot ship into a region until its paperwork there clears, which puts the certification calendar on the critical path next to the silicon.

On many designs this is the argument for a pre-certified module. A module that carries its own regulatory IDs lets a product inherit much of that approval, trading a higher part cost for a lower certification bill and a shorter path to market, so the choice between the chip and the module is as much a sourcing decision as a technical one. An independent distributor that stocks both the SoCs and the certified modules built on them is where a team weighs that trade against the real lead times and prices on each, the chip against the module that wraps it, with the certification bill counted in. Volume tips the same trade the other way. A module carries a fixed premium on every unit, so a design heading for high volume eventually saves more by certifying its own bare-chip layout than it pays the lab once, while a product shipping in the thousands rarely reaches that crossover and keeps the module. Where the break-even sits depends on the module premium, the certification cost, and the volume forecast, so it is a sum to run early, before the module choice hardens into a habit. A team that defers it can find itself recertifying a bare-chip design late, to claw back margin the module quietly spent on every unit shipped so far.

The judgment that fits

Name the protocol first, let it point to the vendor, then choose the part on power, price, and certification. The radio standard is the long-lived decision, and the silicon follows from it.