Introduction
Wireless products are expected to serve more markets, remain in production for years, and respondtochanging connectivity requirements. Engineers are therefore asking how much radio behavior canremain configurable after the PCB is fixed.
Multi-PHY transceivers do not remove every constraint, but they can move part of the product roadmapfrom hardware redesign into software and system architecture. Antenna design, protocol integration, certification, and regional compliance remain system-level responsibilities.
The hidden cost of choosing a radio too early
In a conventional IoT design, choosing a wireless protocol also commits the product to a transceiver, RF front end, antenna strategy, firmware stack, certification path, and regional frequency plan. That decision may be reasonable for the first deployment, but it becomes expensive when the sameplatformmust serve several markets or customer requirements change after the hardware has stabilized.
Consider a utility device initially designed for LoRaWAN telemetry in Europe. A later opportunitymayrequire Wireless M-Bus, while a North American program may ask for Wi-SUN FSK. A smart-buildingderivative may need Z-Wave, and a commissioning workflow may benefit from a Bluetooth LowEnergyphysical layer. With dedicated radios, each branch can create a new PCB variant, qualificationcycle, inventory forecast, and maintenance burden.
Protocol choice is therefore not only a link-budget calculation. It is also a platform-economics decisionshaped by how much radio behavior can remain configurable after the hardware is fixed.
A multi-PHY radio changes the hardware boundary
The LR2021 illustrates this shift. Semtech describes it as a dual-band transceiver covering Sub-GHzand 2.4 GHz operation, with support for LoRa, FLRC, FSK, OOK, O-QPSK, and LR-FHSSmodulation. Its product information also positions the architecture for multi-region designs and protocols implemented through compatible third-party stacks.
The Wio-LR2021 packages that transceiver as a compact RF module controlled by an external host MCU over SPI. It is not an application processor with every network stack built in, and it is not twoindependent radios placed in one package. The host remains responsible for application logic, protocol integration, security, memory allocation, and update policy.
At the radio level, firmware can select the required packet type and configure the associated modulationparameters. This gives one hardware platform access to several physical layers and allows moreof theRF subsystem to be reused across designs that previously would have diverged earlier.
Physical-layer flexibility is not protocol readiness
Multi-PHY capability should not be described as automatic protocol interchangeability. Amodulationisthe radio’s method for encoding and recovering symbols. A deployable protocol also includes framingrules, timing, networking behavior, security, device roles, interoperability requirements, and oftencertification by an industry alliance.
Hardware support for an O-QPSK physical layer can enable IEEE 802.15.4-based development, but it does not by itself provide a complete Thread or Zigbee product. Likewise, a 2.4 GHz radio capableof GFSK modulation does not by itself provide a compliant Bluetooth Low Energy PHY or a self-containedBluetooth controller. The required baseband, link-layer, host software, and validation must still besupplied.
Z-Wave, Wi-SUN, Wireless M-Bus, Amazon Sidewalk, and LoRaWAN also require appropriatehost software, third-party components where applicable, regional configuration, and validation. Thepractical benefit is that one RF platform can reduce the hardware changes required to evaluate and maintainseveral protocol paths.
Three product strategies become more practical
1. Regional reuse with controlled RF variants
A shared module and host interface can reduce PCB variants across regions. Regulations, permittedchannels, output-power limits, antenna characteristics, and enclosure effects still vary, so eachshippingconfiguration must be verified for its target region.
2. Long-range control plus high-rate local transfer
A device can use LoRa for long-range status traffic and switch to FLRC when peers are closeandfastertransfer is needed. Workloads may include diagnostic logs, firmware images, compressed audio, or selected image data. Higher data rates trade sensitivity and link margin for throughput, so modeselection must consider channel conditions, urgency, energy, and airtime rules.
3. Hardware reuse across product families
A manufacturer may develop a common radio board for several products, then pair it with different host firmware and application stacks. This can simplify sourcing, manufacturing test, and lifecycle management, while allowing customer-specific protocol options to be evaluated before committingtoaseparate high-volume design.
What the architecture does not eliminate
Antenna and RF layout
The module provides separate Sub-GHz and 2.4 GHz RF interfaces. Antenna selection, 50-ohmrouting,matching, isolation, enclosure detuning, and coexistence remain board-level responsibilities. Harmonicfiltering also matters because Sub-GHz harmonics can affect 2.4 GHz receiver performance.
Software maturity
Each protocol path needs a suitable stack, host resources, drivers, test coverage, and a maintenanceowner. Support for a modulation does not guarantee equal software maturity across ecosystems.
Certification and interoperability
Module-level regulatory certification can reduce part of the compliance burden, but it does not automatically cover the final host product, a different antenna, or an enclosure that changes RFbehavior. Protocol-specific alliance certification remains separate from radio regulatory approval.
Switching policy
Changing PHYs is a scheduled system action, not simultaneous multi-radio operation. The moduleoperates in a time-shared manner across Sub-GHz and 2.4 GHz paths, so the host must coordinateradio state, switching timing, peer compatibility, security context, and recovery behavior.
The real value is optionality with discipline
Wireless systems will continue to face changing requirements across protocols, regions, anddatarates. Multi-PHY radios do not make product design protocol-agnostic, but they can give engineeringteamsmore room to respond without redesigning the RF platform every time requirements change.
When more physical-layer capability is consolidated into one radio platform, teams can postponesomeirreversible decisions, reuse more hardware across product families, and address newrequirementsthrough firmware and validation instead of an immediate PCB respin. Protocol stacks, antennas, certification, network behavior, and regional rules still define real boundaries.
The most useful question is therefore not whether one protocol will win. It is whether the product architecture can absorb the next protocol, region, or data-rate requirement without starting over. Amulti-PHY transceiver can make that answer more often yes, provided flexibility is treated as a systemcapability rather than a shortcut.
