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.