Modern IoT devices are expected to do more while using less power and occupying less physical space. A single connected device may need to communicate with a cloud platform over Wi-Fi while also communicating locally with smartphones, sensors, controllers, or other nearby devices over Bluetooth Low Energy (BLE).
Traditionally, these requirements could involve multiple connectivity chips and supporting components. An integrated Wi-Fi and BLE System-on-Chip (SoC) can simplify the hardware architecture by combining wireless connectivity, processing, memory interfaces, security features, and peripherals into a more compact solution.
This article looks at the main engineering considerations when designing a low-power IoT device around an integrated Wi-Fi + BLE SoC.
Why Combine Wi-Fi and Bluetooth LE?
Wi-Fi and Bluetooth LE solve different connectivity problems.
Wi-Fi is generally useful when an IoT device needs:
Internet or cloud connectivity
Higher data throughput
Local network communication
Firmware or configuration updates
Communication with network-based services
Bluetooth LE is particularly useful for:
Smartphone connectivity
Device provisioning
Short-range control
Sensors and accessories
Low-power communication
Device-to-device interaction
Combining both technologies allows an IoT product to use the most appropriate wireless interface for each task.
For example, a smart home sensor could use BLE during initial configuration while using Wi-Fi for normal cloud communication.
Smartphone
│
│ Bluetooth LE
▼
┌──────────────┐
│ │
│ Wi-Fi + │
│ BLE SoC │
│ │
└──────┬───────┘
│
│ Wi-Fi
▼
Wi-Fi Router
│
▼
Cloud/API
This architecture can reduce the need for separate wireless controllers and simplify communication between the application firmware and connectivity subsystem.
What Is an Integrated Wireless SoC?
A System-on-Chip integrates several functions into a single semiconductor device.
Depending on the specific device, a wireless SoC may combine:
Processor cores
Memory
Wi-Fi connectivity
Bluetooth LE
RF components
Security hardware
GPIO
UART
SPI
I²C
PWM
Audio or other application interfaces
The exact feature set varies between SoCs, so the device should be selected according to the requirements of the target application.
The basic concept is:
┌─────────────────────────┐
│ Wireless SoC │
│ │
│ ┌───────────────────┐ │
│ │ CPU / Memory │ │
│ └───────────────────┘ │
│ │
│ ┌───────┐ ┌─────────┐ │
│ │ Wi-Fi │ │ BLE │ │
│ └───────┘ └─────────┘ │
│ │
│ GPIO / SPI / I²C/UART │
│ │
│ Security / Peripherals│
└─────────────────────────┘
This level of integration can help reduce board complexity and make it easier to develop compact connected products.
Wi-Fi 6 for Connected IoT Devices
Wi-Fi 6, based on IEEE 802.11ax, introduces technologies designed to improve wireless efficiency, capacity, and performance.
For IoT product development, the important consideration is not simply the maximum theoretical throughput. Engineers also need to consider:
Power consumption
Network reliability
Latency
Coexistence with other wireless radios
Memory requirements
Security
Antenna performance
Firmware complexity
Features such as Target Wake Time (TWT) can be particularly interesting for battery-powered applications because they allow devices and access points to coordinate periods of activity and sleep.
However, actual battery life depends on the complete system design, including radio activity, processor workload, sensor usage, power-management circuitry, and firmware behavior.
Bluetooth LE as a Companion Interface
Bluetooth LE can complement Wi-Fi by providing a convenient local communication channel.
One common architecture is to use BLE for provisioning.
For example:
- User powers on device │ ▼
- Smartphone discovers device using BLE │ ▼
- User provides Wi-Fi credentials │ ▼
- Device connects to Wi-Fi │ ▼
- Device communicates with cloud
This avoids requiring the user to configure the device entirely through a local display or physical controls.
BLE can also remain active after provisioning for local configuration, diagnostics, control, or communication with nearby accessories.
Designing for Low Power
Wireless connectivity is often one of the most important contributors to power consumption in an IoT product.
A simple way to think about system power is:
Total Power
=
Processor Power
- Wi-Fi Activity
- BLE Activity
- Sensors
- Memory
- Peripherals
- Power Supply Losses
Reducing power consumption therefore requires more than selecting a low-power SoC.
- Minimize Radio Activity
Keep the radio active only when necessary.
For a sensor device, an application might follow this cycle:
┌─────────────┐
│ Sleep │
└──────┬──────┘
│
▼
Read Sensor
│
▼
Process Reading
│
▼
Transmit Data
│
▼
Return to Sleep
│
└───────────►
The exact behavior depends on the application's communication requirements.
- Use Appropriate Sleep Modes
A wireless SoC may provide multiple power states.
The firmware should select a mode based on how quickly the device needs to respond.
A device that wakes every few minutes can generally use a different power strategy from a device that must respond immediately to user input.
- Avoid Unnecessary Processing
The processor does not need to remain at maximum performance continuously.
Application firmware can schedule tasks efficiently and allow the processor to enter a lower-power state when no work is pending.
- Consider the Complete Power Path
The SoC may have excellent low-power characteristics, but inefficient voltage regulators, sensors, LEDs, memory devices, or external peripherals can dominate the overall power budget.
Therefore, power optimization should be performed at the system level.
Wi-Fi and BLE Coexistence
When Wi-Fi and BLE operate in the same device, radio coexistence becomes an important design consideration.
Both technologies operate in the 2.4 GHz frequency range, so simultaneous activity must be managed appropriately.
A good coexistence strategy considers:
Channel usage
Radio scheduling
Transmission timing
Receive windows
Application priorities
Antenna design
Firmware coordination
The goal is not simply to enable both radios. The system should maintain reliable communication while meeting latency and power requirements.
Hardware Design Considerations
Selecting the SoC is only the beginning of the hardware design.
RF and Antenna
Wireless performance depends heavily on the RF implementation.
Engineers should carefully follow the SoC manufacturer's reference design and layout recommendations for:
RF traces
Matching networks
Grounding
Antenna placement
Keep-out areas
PCB stack-up
Component placement
An excellent wireless SoC can still deliver poor range if the antenna or PCB layout is poorly designed.
Power Supply
The power supply should provide stable voltage under changing radio loads.
Engineers should consider:
Peak current requirements
Voltage ripple
Regulator efficiency
Decoupling
Battery characteristics
Thermal behavior
The power system should be evaluated under realistic Wi-Fi transmission and reception conditions rather than only under idle conditions.
Peripheral Interfaces
IoT products commonly connect sensors and peripherals through interfaces such as:
I²C → Sensors
SPI → Displays / Flash / High-speed peripherals
UART → Debugging / External modules
GPIO → Buttons / LEDs / Digital signals
PWM → Motors / LEDs / Control
Having these interfaces integrated into the SoC can reduce the number of external controllers required.
Security Should Be Designed In
Connected devices must be designed with security in mind from the beginning.
Depending on the SoC and platform, useful hardware and software security capabilities can include:
Secure boot
Hardware cryptographic acceleration
Protected key storage
Firmware authentication
Encrypted communication
Secure firmware updates
Security should not be treated as an optional feature added after the hardware and firmware architecture have already been finalized.
A secure device architecture should consider the complete lifecycle:
Manufacturing
│
▼
Device Provisioning
│
▼
Secure Boot
│
▼
Normal Operation
│
▼
Authenticated Updates
│
▼
End of Device Lifecycle
Firmware Architecture
A well-structured firmware architecture can make a dual-wireless device easier to maintain.
One possible approach is to separate application logic from connectivity management.
┌───────────────────────────────┐
│ Application Layer │
│ Sensors / Logic / User Tasks │
├───────────────────────────────┤
│ Connectivity Layer │
│ Wi-Fi / BLE Manager │
├───────────────────────────────┤
│ Drivers │
│ GPIO / I²C / SPI / UART │
├───────────────────────────────┤
│ Hardware / SoC │
└───────────────────────────────┘
This separation makes it easier to modify the application without rewriting the entire connectivity stack.
For example, the application might request:
connect_to_network()
send_sensor_data()
start_ble_provisioning()
enter_low_power_mode()
while the connectivity layer handles the implementation details.
Example: Connected Environmental Sensor
Consider a battery-powered environmental monitoring device.
The device contains:
Temperature sensor
Humidity sensor
Wi-Fi + BLE SoC
Battery
Status LED
Optional user button
A typical operating sequence could be:
Power On
│
▼
Initialize Hardware
│
▼
BLE Provisioning Mode
│
▼
Configure Wi-Fi
│
▼
Connect to AP
│
▼
Read Environment
│
▼
Send Data to Cloud
│
▼
Sleep Mode
│
▼
Wake Periodically
│
└──────────────►
This architecture demonstrates why integrating Wi-Fi and BLE into one SoC can be useful. BLE provides a local interface for setup and configuration, while Wi-Fi provides network connectivity for regular data transmission.
Why SoC Integration Matters
From a product-development perspective, integration can provide several potential advantages.
Smaller Hardware Footprint
Combining multiple functions into one chip can reduce the number of major ICs required on the PCB.
Simplified System Architecture
Application processing and wireless connectivity can be managed within a more integrated platform.
Reduced Component Count
Fewer external controllers can potentially simplify the bill of materials and PCB design.
Faster Prototyping
A development kit based on the target SoC allows engineers to evaluate connectivity and firmware before committing to a custom PCB.
Flexible Product Development
The same wireless platform can potentially support different product categories with appropriate firmware and peripheral configurations.
Selecting the Right Wireless SoC
There is no single best wireless SoC for every IoT product.
Before selecting a device, engineers should evaluate:
Requirement Questions to Ask
Wireless Which Wi-Fi and BLE features are required?
Power What are the active and sleep power requirements?
Processing How much CPU performance is required?
Memory How much Flash and RAM are needed?
Security What security features are required?
Interfaces Which GPIO, SPI, I²C and UART interfaces are needed?
RF What antenna and PCB requirements exist?
Software Is the required SDK and development environment available?
Cost Does the solution meet the target BOM?
Availability Can the device support production requirements?
A development kit should also be evaluated before final hardware selection.
Where Integrated Wi-Fi + BLE SoCs Can Be Used
This architecture is applicable to many connected-device categories, including:
Smart home devices
IoT sensors
Smart appliances
Connected controllers
Industrial monitoring devices
Wearable accessories
Consumer electronics
Connected lighting
Energy-management devices
Remote monitoring systems
The actual architecture should be adapted to the power, connectivity, processing, security, and environmental requirements of each product.
T2M Wireless SoC Solutions
T2M Semiconductor develops wireless System-on-Chip solutions for connected-device applications, including Wi-Fi and Bluetooth connectivity.
Its wireless portfolio includes solutions targeting applications where connectivity, embedded processing, power efficiency, and system integration are important design considerations.
For engineers evaluating a Wi-Fi + BLE platform, the relevant T2M product documentation can be used to review device capabilities, interfaces, supported wireless technologies, and development requirements.
Final Thoughts
Designing a low-power IoT device is a system-level engineering problem.
Choosing an integrated Wi-Fi and Bluetooth LE SoC can simplify the architecture, but successful product development also depends on RF design, power management, firmware architecture, security, antenna implementation, and careful component selection.
The most effective approach is to start with the actual application requirements and work backward toward the SoC, hardware architecture, and firmware design.
For developers and hardware engineers, a suitable development kit can provide an important first step: validate wireless connectivity, experiment with firmware, measure power consumption, and understand the practical behavior of the platform before designing the final product.
The combination of integrated wireless connectivity and embedded processing continues to make SoC-based architectures an important option for the next generation of connected IoT devices.
