Build a Secure, Low-Power Bluetooth Hub and Sensor Network

By Stephen Evanczuk

Contributed By Digi-Key's North American Editors

With its widespread availability on mobile devices, Bluetooth is well suited for providing consumers with easy wireless access to smart products. For IoT developers, however, building Bluetooth connected sensor networks presents challenges such as maximizing battery life, optimizing Bluetooth protocols, and ensuring secure connectivity among devices.

As this article will show, using an advanced Bluetooth device and an associated development environment from Cypress Semiconductor, developers can speed through these issues and rapidly implement secure Bluetooth hub sensor networks.

Why Bluetooth?

Bluetooth's widespread support in smartphones and other mobile devices has made it a preferred wireless technology for connecting consumers with their personal electronic devices such as wearables and medical devices, among others. With the emergence of Bluetooth 5, IoT developers can leverage those same advantages while meeting the growing requirements for longer range and higher data rates associated with sensor networks and other IoT applications.

To build designs for those applications, developers can turn to a growing array of Bluetooth 5 capable devices. Combining a complete RF subsystem and processor core, these devices are capable of performing the low-level transactions associated with Bluetooth communications. Yet, the need to maintain low power consumption and ensure secure connectivity in IoT networks can present a further complication in deploying Bluetooth in these applications.

Integrated solution

The Cypress Semiconductor CYW20719 is designed specifically to meet growing requirements for battery-powered Bluetooth connected designs for the IoT, wearables, personal electronics, and other low-power applications. Along with its low-power capabilities, its support of advanced Bluetooth 5 features, including adaptive frequency hopping, provides an important advantage in the busy radio environments associated with those applications.

The device integrates a low-power Bluetooth radio subsystem, an Arm® Cortex®-M4 core with floating-point unit (FPU), and multiple peripheral blocks (Figure 1). In addition, an on-chip security engine accelerates public key cryptography and provides critical crypto functionality required to help ensure security of Bluetooth operations. Finally, an on-chip power management unit (PMU) provides developers with a flexible mechanism for meeting requirements for the ultra-low-power operation increasingly required for Bluetooth-enabled devices.

Diagram of Cypress Semiconductor CYW20719

Figure 1: The Cypress Semiconductor CYW20719 combines an Arm® Cortex®-M4, a complete Bluetooth subsystem, and built-in software services to provide a complete Bluetooth 5 capable wireless MCU for low-power designs. (Image source: Cypress Semiconductor)

The CYW20719 radio subsystem includes complete 2.5 GHz RF signal paths for transmit (Tx) and receive (Rx) operation. For the Rx signal path, the device attenuates out-of-band signals, achieving a -95.5 dBm Rx sensitivity while enabling developers to use the device without additional off-chip filters if required. Its Tx signal path includes an integrated power amplifier (PA) designed to support configurable transmit power levels ranging from -24 dBm up to a maximum of +4 dBm. Along with integrated physical layer (PHY) capabilities, the device includes a complete on-chip Bluetooth 5 medium access control (MAC) layer. With its optimized Rx and Tx signal paths, the device uses only 5.9 mA Rx current or 5.6 mA (@ 0 dBm) Tx current.

To further minimize power consumption, the device provides multiple power modes managed by the integrated power management unit (PMU). Designed to supply separate RF and digital power domains, the PMU combines an integrated buck regulator, a low-dropout (LDO) regulator for digital circuits, and a separate LDO for RF circuits (Figure 2). In addition, the PMU includes a separate bypass LDO (BYPLDO) that automatically bypasses the buck regulator to supply the digital and RF LDOs if the source VBAT supply falls below 2.1 volts.

Diagram of Cypress CYW20719 PMU

Figure 2: The Cypress CYW20719 PMU manages separate power domains that can be selectively disabled in different low-power modes to reduce current consumption in low-power designs. (Image source: Cypress Semiconductor)

In operation, the PMU adjusts the power domains according to the selected power mode, which includes fully active mode, idle mode, and three different sleep modes. In the lowest power shut-down sleep (SDS) mode, the PMU turns off all device blocks except I/O power, the real-time clock (RTC), and a dedicated low-power oscillator (LPO) used as the clock source for some blocks and wakeup timing.

Even using those minimal resources, the CYW20719 in SDS mode can maintain a connection with another previously paired Bluetooth device, consuming less than 70 microamps (μA) in the process. In this mode, however, the device does not retain memory and requires a warm boot to restore state before proceeding with more complex operations. The other two sleep modes, power-down sleep (PDS) and sleep state, maintain increasing levels of device activity including memory retention with commensurate incremental increases in power consumption. Even so, developers working with very limited power budgets can take advantage of PDS mode for low-power Bluetooth advertising (about 125 μA) and active connections (about 170 μA). By managing device power modes, developers can easily achieve very-low-power operation without compromising functionality.

System integration

Even with its flexible operating modes and extensive functionality, the CYW20719 requires few additional components to complete hardware integration in a system design. Because it integrates critical components on chip, developers only need to add a few resistors, coupling capacitors, a 2.2 µH inductor such as the Murata LQH2MCN2R2M52L, and ferrite beads such as the Murata BLM15AG601SN1D (Figure 3). Still, it’s wise to place a bandpass filter between the CYW20719 and the antenna matching components to reduce harmonics.

Diagram of Cypress CYW20719 (click to enlarge)

Figure 3: Because the Cypress CYW20719 integrates all critical functionality, developers can complete hardware integration with only a few additional components including a recommended bandpass filter to reduce harmonics. (Figure source: Cypress Semiconductor)

The device similarly helps simplify software integration with its extensive on-chip memory including 1 Mbyte flash, 512 Kbytes of RAM, and 2 Mbytes of ROM. While the flash and RAM provide developers with memory areas for their applications, the on-chip ROM is reserved for device firmware and Bluetooth profiles. To support firmware patches when required, the device provides patch RAM – a region of RAM connected through patch control logic (see Figure 1 above). Finally, the device provides an always-on memory (AON) area, which allows the device to store data even in low-power modes such as SDS that would otherwise turn off volatile memory.

Although the RAM and flash memory provided on the chip might seem limited compared to other state-of-the-art devices, the extensive software support built into the ROM ensures plenty of memory for typical applications. Cypress configures the on-chip ROM with a comprehensive software stack extending from the lowest hardware abstraction layer (HAL) up through the application programming interface (API) for the WICED (Wireless Internet Connectivity for Embedded Devices) environment (Figure 4).

Image of Cypress CYW20719’s 2 Mbytes of ROM firmware

Figure 4: The Cypress CYW20719’s 2 Mbytes of ROM firmware provides a full software stack including a real-time operating system, reducing complexity and footprint of the developer's application code. (Image source: Cypress Semiconductor)

Building on the HAL, the ROM firmware executes a built-in real-time operating system and handles all interactions with the CYW20719 hardware. At the same time, the ROM firmware includes a full complement of Bluetooth service layers including those supporting the essential Bluetooth Generic Attribute Profile (GATT) and generic access profile (GAP).

For typical applications, the developer code runs from RAM, using the WICED APIs to access the RTOS, peripherals, and other device features. Although RAM requirements can vary significantly, most application code for the CYW20719 typically leaves plenty of free RAM for data or working memory. For example, the hello_sensor application described later leaves about 240 Kbytes of RAM free.

For applications with particularly large code bases, however, developers can take advantage of the CYW20719's ability to work with application code designed to execute in-place (XIP) from the on-chip flash. Here, the WICED environment loads developer designated code and read-only data sections into the on-chip flash and places the remaining sections into RAM. This approach does of course reduce the RAM footprint for an application, but it can impact performance. Consequently, developers need to be cautious in designating XIP code sections and ensure that time-critical functions are placed in RAM.

Application development

Although the CYW20719 simplifies design integration, developers looking to focus on secure low-power Bluetooth applications can still face significant delays in completing hardware design and application development. Designed to demonstrate CYW20719-based applications, the Cypress CYW920719Q40EVB-01 evaluation kit works with the Cypress WICED software environment to provide a reference design and comprehensive development platform for creating Bluetooth 5.0 compliant IoT applications.

The evaluation kit is built around a carrier module that includes the CYW20719 in the Figure 3 design, with the addition of a Torex Semiconductor XC6119N voltage detector connected to the CYW20719's RST_N pin to perform a reset. The carrier module is soldered to the kit's baseboard, which includes an STMicroelectronics LSM9DS1TR 9-axis motion sensor, a Murata NCU series NTC thermistor, the CYW20719 GPIO ports, a debug connection, Arduino-compatible headers for expansion, and switches and LEDs as a simple user interface (Figure 5).

Diagram of Cypress CYW920719Q40EVB-01 evaluation kit

Figure 5: The Cypress CYW920719Q40EVB-01 evaluation kit combines a CYW20719 on a carrier module with multiple baseboard components able to support a typical IoT application. (Image source: Cypress Semiconductor)

Sample software from Cypress uses the CYW20719 and other components as part of an extensive demonstration of secure Bluetooth connectivity in a representative IoT network comprising multiple sensor devices and a central hub (Figure 6). With this sample application, developers can explore different security levels for pairing between a sensor device and the hub, and evaluate the impact of these different security levels on data exchange.

Diagram of CYW920719Q40EVB-01 kits and the Cypress WICED development environment

Figure 6: Designed to work with multiple CYW920719Q40EVB-01 kits and the Cypress WICED development environment, a Cypress sample application demonstrates secure Bluetooth connectivity in a representative IoT application. (Image source: Cypress Semiconductor)

For the application's hardware, developers use a separate CYW920719Q40EVB-01 kit configured as the secure hub, and additional kits configured as individual sensors in the network. A PC linked via a serial connection to each kit provides a console for setting parameters, viewing data, printing debug messages, and otherwise interacting with the sample application.

Although not included in this sample application, the only remaining element in a typical application such as this would be a connection to a mobile device for application monitoring and control functions. Here, the serially connected PC serves much the same function.

Cypress bundles the software for this sample application in its CYW20917 BLE Secure Hub C language package for its WICED development environment. In this case, the package includes two projects for the two separate roles in the sample application. Designed to run on the kit designated as the secure hub, one project (secure_hub) enables the hub to support multiple Bluetooth protocol roles. In particular, the hub software is designed to enable pairing at separate security levels with different kits running as slaves.

The kits configured as slaves run the sensor project (hello_sensor) designed to illustrate data collection and communication at the security level established during pairing. Each project includes several header and code modules needed to support each functional role. Among these files, the secure_hub and hello_sensor projects each include a Generic Attribute Profile (GATT) header (gatt_db.h) and code (gatt_db.c) file.

In the Bluetooth protocol, a lookup table called the GATT database (DB), defines the nature and capabilities of a Bluetooth connection through a set of defined services that each comprise a set of supported characteristics. For example, the Bluetooth specification includes predefined GATT services ranging from utility capabilities like alert notification and device information, to application-specific capabilities like blood pressure and pulse oximeter services. Serving a more fundamental role than GATT services, the Bluetooth generic access profile (GAP) for a device defines how it advertises itself for discovery by the network and how it establishes connections once discovered.

The gatt_db.h header and gatt_db.c code in the secure_hub project and hello_sensor project define GAP and GATT services for the secure hub and sensor configured kits, respectively. For this demonstration application, each project defines a custom GATT service according to its role. For example, the hello_sensor project header includes a C enum type that defines mandatory GATT and GAP service handles, as well as a custom GATT definition for a sensor service (Listing 1a). In turn, that project's gatt_db.c file uses those definitions to build the GATT DB required in the Bluetooth protocol (Listing 1b).


typedef enum


    HANDLE_HSENS_GATT_SERVICE = 0x1, // service handle


    HANDLE_HSENS_GAP_SERVICE = 0x14, // service handle

        HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_NAME, // characteristic handl

        HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_NAME_VAL, // char value handle


        HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_APPEARANCE, // characteristic handl





        HANDLE_HSENS_SERVICE_CHAR_UART, // characteristic handl

        HANDLE_HSENS_SERVICE_CHAR_UART_VAL, // char value handle

        HANDLE_HSENS_SERVICE_CHAR_CFG_DESC, // charconfig desc handl


        HANDLE_HSENS_SERVICE_CHAR_BLINK, // characteristic handl

           HANDLE_HSENS_SERVICE_CHAR_BLINK_VAL, // char value handle


           HANDLE_HSENS_SERVICE_CHAR_TEMP, // characteristic handl

                  HANDLE_HSENS_SERVICE_CHAR_TEMP_VAL, // char value handle

                  HANDLE_HSENS_SERVICE_CHAR_TEMP_CFG_DESC, // charconfig desc handl




/* Permissions for custom characteristics */





uint8_t paired_security_level;


static void                     temp_notificaition_timeout( uint32_t count );



const uint8_t hello_sensor_gatt_database[]=


    // Declare mandatory GATT service



    // Declare mandatory GAP service. Device Name and Appearance are mandatory

    // characteristics of GAP service



        // Declare mandatory GAP service characteristic: Dev Name




        // Declare mandatory GAP service characteristic: Appearance




    // Declare proprietary Hello Service with 128 byte UUID


        // Declare characteristic used to notify/indicate change





            // Declare client characteristic configuration descriptor

            // Value of the descriptor can be modified by the client

            // Value modified shall be retained during connection and across connection

            // for bonded devices.  Setting value to 1 tells this application to send notification

            // when value of the characteristic changes.  Value 2 is to allow indications.



        // Declare characteristic Hello Configuration

        // The configuration consists of 1 bytes which indicates how many times to

       // blink the LED when user pushes the button.



                                        LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_WRITE,

                                        LED_BLINK_CHAR_PERMISSION ),






            // Declare client characteristic configuration descriptor

            // Value of the descriptor can be modified by the client

            // Value modified shall be retained during connection and across connection

            // for bonded devices.  Setting value to 1 tells this application to send notification

            // when value of the characteristic changes.  Value 2 is to allow indications.




Listing 1: Included in the Cypress BLE Secure Hub application's hello_sensor project, a header file defines an enum type for different characteristics (A) that the corresponding code module uses to build the GATT DB required for Bluetooth operations. (Code source: Cypress Semiconductor)

Embedded in these definitions, the GATT sensor service also defines whether its underlying service characteristics can read, write, notify, or indicate (using the connected console). For example, the LED blink characteristic (HANDLE_HSENS_SERVICE_CHAR_BLINK declared in Listing 1a and applied in Listing 1b) includes bitmasks (LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_WRITE in Listing 1b) that indicate the characteristic is both readable and writable.

The hello_sensor project's gatt_db.c file, however, combines those definitions with code that implements secure access to that characteristic. That is, the capability to blink the LED the number of times indicated by a character typed into the console by the developer. For the purposes of this sample application, access to this capability requires that the connection to that sensor kit was made with Bluetooth man-in-the-middle (MITM) pairing using a user-provided passkey entered using the console during pairing.

In general, when a request is made to invoke some functionality, a corresponding handler performs the application-specific tasks, taking into account both defined characteristics and secure access requirements. For the LED blink example, when a request is made to perform the LED blink function, the actual code for ensuring permission and authorizing access is simple enough.

To change the LED blink characteristic value (HANDLE_HSENS_SERVICE_CHAR_BLINK_VAL), the code uses a conditional statement that confirms both write permission and access authorization (Listing 2). For write permission, the conditional compares the requested permission (LEGATTDB_PERM_AUTH_WRITABLE) with the actual LED device's blink permission setting, LED_BLINK_CHAR_PERMISSION (defined at the top of Listing 1b). For authorization, the conditional checks that the current paired security level (paired_security_level) was created with MITM pairing (BTM_SEC_LINK_PAIRED_WITH_MITM) (Listing 2).



 * Process write request or write command from peer device


wiced_bt_gatt_status_t hello_sensor_gatts_req_write_handler( uint16_t conn_id, wiced_bt_gatt_write_t * p_data )


    wiced_bt_gatt_status_t result    = WICED_BT_GATT_SUCCESS;

    uint8_t                *p_attr   = p_data->p_val;


    uint8_t sec_flag, key_size;

    WICED_BT_TRACE("write_handler: conn_id:%d hdl:0x%x prep:%d offset:%d len:%d\r\n ", conn_id, p_data->handle, p_data->is_prep, p_data->offset, p_data->val_len );


    switch ( p_data->handle )








           if ( p_data->val_len != 2 )


               return WICED_BT_GATT_INVALID_ATTR_LEN;


           WICED_BT_TRACE( "Temp Notif Enabled\r\n");


           hello_sensor_hostinfo.temp_characteristic_client_configuration = p_attr[0] | ( p_attr[1] << 8 );





        if ( p_data->val_len != 1 )


            return WICED_BT_GATT_INVALID_ATTR_LEN;






            WICED_BT_TRACE("Write Failed: Insufficient Authentication\r\n");




        hello_sensor_hostinfo.number_of_blinks = p_attr[0];

        if ( hello_sensor_hostinfo.number_of_blinks != 0 )


            WICED_BT_TRACE( "hello_sensor_write_handler:num blinks: %d\r\n", hello_sensor_hostinfo.number_of_blinks );

            wiced_bt_app_hal_led_blink(250, 250, hello_sensor_hostinfo.number_of_blinks );









    return result;


Listing 2: In this snippet from the Cypress BLE Secure Hub application, a request to perform the LED Blink characteristic first needs to pass a check (highlighted) for permission and security authorization. (Code source: Cypress Semiconductor)

Using GATT DB definitions and supporting code appropriate for the sensor project and the hub project, this sample application provides developers with the basic design patterns associated with three different security levels, including any level of pairing, MITM pairing describe here, and Bluetooth LE Secure pairing. The latter pairing method offers the highest security, using an authentication method based on Elliptic Curve Diffie-Hellman (ECDH) key exchange. Because the CYW20719's integrated security engine includes an ECDH accelerator, developers can deploy this approach without compromising performance.


The availability of integrated Bluetooth-enabled wireless MCUs has helped developers speed integration of these devices into their designs. To implement secure Bluetooth networks, however, developers face multiple challenges in creating Bluetooth compatible services and writing applications able to use those devices securely.

Based on the Cypress CYW20719 Bluetooth MCU, the Cypress Semiconductor CYW920719Q40EVB-01 kit Bluetooth evaluation kit and WICED development environment provide a comprehensive platform for building these applications. Using the kits and WICED environment in conjunction with the Cypress BLE Secure Hub package, developers can quickly evaluate secure Bluetooth applications, and extend them rapidly into custom applications able to leverage the enhanced speed and range of Bluetooth 5.

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this author

Stephen Evanczuk

Stephen Evanczuk has more than 20 years of experience writing for and about the electronics industry on a wide range of topics including hardware, software, systems, and applications including the IoT. He received his Ph.D. in neuroscience on neuronal networks and worked in the aerospace industry on massively distributed secure systems and algorithm acceleration methods. Currently, when he's not writing articles on technology and engineering, he's working on applications of deep learning to recognition and recommendation systems.

About this publisher

Digi-Key's North American Editors