In this Tech Talks session, Senior Field Applications Engineer, Carlos Hernandez, describes Z-Wave command class structure and provides reference code examples. Click here to watch the entire session and register now for future Tech Talks. The following is an overview of Carlos’s presentation.

What is Z-Wave?

Z-Wave is a low-power, wireless mesh network communications protocol designed specifically for control, monitoring and status reading applications in residential and light commercial environments.

Z-Wave operates through regional Sub-GHz frequencies, ensuring product interoperability throughout the region. Every product in the Z-Wave ecosystem is interoperable and backward compatible all the way to the first generation.

Any device using Z-Wave must use command class structure, which is the “language of Z-Wave” and is classified in the Z-Wave specification.

Command Class Structure

Z-Wave commands are structured so that the most significant byte is always the “command class”, which is a group of commands that perform a specific function. The next byte is the command itself, such as “Set”, “Get” or “Report”.  The next set of bytes can range in size from 0 to the maximum Z-Wave packet size, which is the payload of 64 minus the header. In the binary switch set command scenario, the third byte is the value itself – either 00 or FF, based on what you want the device to do, such as turn off or on a light.

There are four command class types in the Z-Wave realm:

• Application command class is a group of commands with a specific set of functions. All specific applications have a command class.
• Management command class allows you to control devices in the network and manage the way devices behave.
• Encapsulation command class includes commands that encapsulate other commands containing extra information.
• Network command class allows you to perform network operations such as including and excluding nodes, and preprovisioning nodes into the network.

Most command classes have three types of commands.

• Set command – the first type of command, allows a controller or gateway to set a specific state variable in another device.
• Get command – requests spec info from the device. For example, requests the status of a light. The light will respond with an “On” or “Off”.
• Report command – responds to a Get command type with the state of the variable that was requested. In the example of a light, “On” or “Off”.

For a list of Z-Wave command classes, visit our Z-Wave specification page.

Structure of a Z-Wave End Device

Z-Wave end devices are structured in the following order:

• Bottom layer — Z-Wave module or SoC (currently 700 series)
• Z-Wave Protocol layer —  precompiled in a set of libraries that you can add to your application to enable your protocol stack.
• Building block modules (3) — prewritten, pre-certified C code modules that address 90% of development needs. This is the application framework, or Z-Wave “skeleton code”, that all applications are built on.

The Sample Application and Product Specific Code layer sits on top of the application framework. Applications in this layer are pre-written and have undergone the full Z-Wave certification process. This is the best place to start designing your application. By reusing this sample code in your own application, you can significantly reduce your development time.

Getting Started

The first step to building your application is to order our Z-Wave Wireless Starter Kit (WSTK), which contains everything you need to get your project going, including the following:

• WSTK mainboard
• Radio board
• Buttons and LED expansion boards
• Controller and network sniffer USB sticks

Our Simplicity Studio tools further speed development by providing software examples, demos, sample code and supporting documentation. Using our WSTK, you can develop any Z-Wave application.

For more information on Z-Wave products and development tools, contact your Silicon Labs sales representative.

In this Tech Talks session, Senior Field Applications Engineer, Carlos Hernandez, describes Z-Wave command class structure and provides reference code examples. Click here to watch the entire session and register now for future Tech Talks. The following is an overview of Carlos’s presentation.

What is Z-Wave?

Z-Wave is a low-power, wireless mesh network communications protocol designed specifically for control, monitoring and status reading applications in residential and light commercial environments.

Z-Wave operates through regional Sub-GHz frequencies, ensuring product interoperability throughout the region. Every product in the Z-Wave ecosystem is interoperable and backward compatible all the way to the first generation.

Any device using Z-Wave must use command class structure, which is the “language of Z-Wave” and is classified in the Z-Wave specification.

Command Class Structure

Z-Wave commands are structured so that the most significant byte is always the “command class”, which is a group of commands that perform a specific function. The next byte is the command itself, such as “Set”, “Get” or “Report”.  The next set of bytes can range in size from 0 to the maximum Z-wave packet size, which is the payload of 64 minus the header. In the binary switch set command scenario, the third byte is the value itself – either 00 or FF, based on what you want the device to do, such as turn off or on a light.

There are four command class types in the Z-Wave realm:

• Application command class is a group of commands with a specific set of functions. All specific applications have a command class.
• Management command class allows you to control devices in the network and manage the way devices behave.
• Encapsulation command class includes commands that encapsulate other commands containing extra information.
• Network command class allows you to perform network operations such as including and excluding nodes, and preprovisioning nodes into the network.

Most command classes have three types of commands.

• Set command – the first type of command, allows a controller or gateway to set a specific state variable in another device.
• Get command – requests spec info from the device. For example, requests the status of a light. The light will respond with an “On” or “Off”.
• Report command – responds to a Get command type with the state of the variable that was requested. In the example of a light, “On” or “Off”.

For a list of Z-Wave command classes, visit our Z-Wave specification page.

Structure of a Z-Wave End Device

Z-Wave end devices are structured in the following order:

• Bottom layer — ZWave module or SoC (currently 700 series)
• ZWave Protocol layer —  precompiled in a set of libraries that you can add to your application to enable your protocol stack.
• Building block modules (3) — prewritten, pre-certified C code modules that address 90% of development needs. This is the application framework, or ZWave “skeleton code”, that all applications are built on.

The Sample Application and Product Specific Code layer sits on top of the application framework. Applications in this layer are pre-written and have undergone the full Z-Wave certification process. This is the best place to start designing your application. By reusing this sample code in your own application, you can significantly reduce your development time.

Getting Started

The first step to building your application is to order our Z-Wave Wireless Starter Kit (WSTK), which contains everything you need to get your project going, including the following:

• WSTK mainboard
• Radio board
• Buttons and LED expansion boards
• Controller and network sniffer USB sticks

Our Simplicity Studio tools further speed development by providing software examples, demos, sample code and supporting documentation. Using our WSTK, you can develop any Z-Wave application.

For more information on Z-Wave products and development tools, contact your Silicon Labs sales representative.

In this Tech Talks session, Senior Field Applications Engineer, Carlos Hernandez, describes Z-Wave command class structure and provides reference code examples. Click here to watch the entire session and register now for future Tech Talks. The following is an overview of Carlos’s presentation.

What is Z-Wave?

Z-Wave is a low-power, wireless mesh network communications protocol designed specifically for control, monitoring and status reading applications in residential and light commercial environments.

Z-Wave operates through regional Sub-GHz frequencies, ensuring product interoperability throughout the region. Every product in the Z-Wave ecosystem is interoperable and backward compatible all the way to the first generation.

Any device using Z-Wave must use command class structure, which is the “language of Z-Wave” and is classified in the Z-Wave specification.

Command Class Structure

Z-Wave commands are structured so that the most significant byte is always the “command class”, which is a group of commands that perform a specific function. The next byte is the command itself, such as “Set”, “Get” or “Report”.  The next set of bytes can range in size from 0 to the maximum Z-wave packet size, which is the payload of 64 minus the header. In the binary switch set command scenario, the third byte is the value itself – either 00 or FF, based on what you want the device to do, such as turn off or on a light.

There are four command class types in the Z-Wave realm:

• Application command class is a group of commands with a specific set of functions. All specific applications have a command class.
• Management command class allows you to control devices in the network and manage the way devices behave.
• Encapsulation command class includes commands that encapsulate other commands containing extra information.
• Network command class allows you to perform network operations such as including and excluding nodes, and preprovisioning nodes into the network.

Most command classes have three types of commands.

• Set command – the first type of command, allows a controller or gateway to set a specific state variable in another device.
• Get command – requests spec info from the device. For example, requests the status of a light. The light will respond with an “On” or “Off”.
• Report command – responds to a Get command type with the state of the variable that was requested. In the example of a light, “On” or “Off”.

For a list of Z-Wave command classes, visit our Z-Wave specification page.

Structure of a Z-Wave End Device

Z-Wave end devices are structured in the following order:

• Bottom layer — ZWave module or SoC (currently 700 series)
• ZWave Protocol layer —  precompiled in a set of libraries that you can add to your application to enable your protocol stack.
• Building block modules (3) — prewritten, pre-certified C code modules that address 90% of development needs. This is the application framework, or ZWave “skeleton code”, that all applications are built on.

The Sample Application and Product Specific Code layer sits on top of the application framework. Applications in this layer are pre-written and have undergone the full Z-Wave certification process. This is the best place to start designing your application. By reusing this sample code in your own application, you can significantly reduce your development time.

Getting Started

The first step to building your application is to order our Z-Wave Wireless Starter Kit (WSTK), which contains everything you need to get your project going, including the following:

• WSTK mainboard
• Radio board
• Buttons and LED expansion boards
• Controller and network sniffer USB sticks

Our Simplicity Studio tools further speed development by providing software examples, demos, sample code and supporting documentation. Using our WSTK, you can develop any Z-Wave application.

For more information on Z-Wave products and development tools, contact your Silicon Labs sales representative.

In this Tech Talks session, Senior Field Applications Engineer, Carlos Hernandez, describes Z-Wave command class structure and provides reference code examples. Click here to watch the entire session and register now for future Tech Talks. The following is an overview of Carlos’s presentation.

What is Z-Wave?

Z-Wave is a low-power, wireless mesh network communications protocol designed specifically for control, monitoring and status reading applications in residential and light commercial environments.

Z-Wave operates through regional Sub-GHz frequencies, ensuring product interoperability throughout the region. Every product in the Z-Wave ecosystem is interoperable and backward compatible all the way to the first generation.

Any device using Z-Wave must use command class structure, which is the “language of Z-Wave” and is classified in the Z-Wave specification.

Command Class Structure

Z-Wave commands are structured so that the most significant byte is always the “command class”, which is a group of commands that perform a specific function. The next byte is the command itself, such as “Set”, “Get” or “Report”.  The next set of bytes can range in size from 0 to the maximum Z-wave packet size, which is the payload of 64 minus the header. In the binary switch set command scenario, the third byte is the value itself – either 00 or FF, based on what you want the device to do, such as turn off or on a light.

There are four command class types in the Z-Wave realm:

• Application command class is a group of commands with a specific set of functions. All specific applications have a command class.
• Management command class allows you to control devices in the network and manage the way devices behave.
• Encapsulation command class includes commands that encapsulate other commands containing extra information.
• Network command class allows you to perform network operations such as including and excluding nodes, and preprovisioning nodes into the network.

Most command classes have three types of commands.

• Set command – the first type of command, allows a controller or gateway to set a specific state variable in another device.
• Get command – requests spec info from the device. For example, requests the status of a light. The light will respond with an “On” or “Off”.
• Report command – responds to a Get command type with the state of the variable that was requested. In the example of a light, “On” or “Off”.

For a list of Z-Wave command classes, visit our Z-Wave specification page.

Structure of a Z-Wave End Device

Z-Wave end devices are structured in the following order:

• Bottom layer — ZWave module or SoC (currently 700 series)
• ZWave Protocol layer —  precompiled in a set of libraries that you can add to your application to enable your protocol stack.
• Building block modules (3) — prewritten, pre-certified C code modules that address 90% of development needs. This is the application framework, or ZWave “skeleton code”, that all applications are built on.

The Sample Application and Product Specific Code layer sits on top of the application framework. Applications in this layer are pre-written and have undergone the full Z-Wave certification process. This is the best place to start designing your application. By reusing this sample code in your own application, you can significantly reduce your development time.

Getting Started

The first step to building your application is to order our Z-Wave Wireless Starter Kit (WSTK), which contains everything you need to get your project going, including the following:

• WSTK mainboard
• Radio board
• Buttons and LED expansion boards
• Controller and network sniffer USB sticks

Our Simplicity Studio tools further speed development by providing software examples, demos, sample code and supporting documentation. Using our WSTK, you can develop any Z-Wave application.

For more information on Z-Wave products and development tools, contact your Silicon Labs sales representative.

When an IoT customer, impressed with our EFR32BG22 (BG22) performance, wanted to achieve the best possible battery life for their application, Silicon Labs accepted the challenge. Field Applications Engineer, Marius Turculet, began testing and found that BG22 could achieve 30 to 40 percent of power savings when combined with our EFP01 Energy Friendly PMIC family. Click here to watch the entire presentation and register now for future Tech Talks. Highlights from Marius' session are below.

EFR32BG22 and EFP01 Used Together

BG22 is our most energy-friendly wireless system-on-chip (SoC). Equipped with an Arm® Cortex®-M33 core, BG22 SoCs achieve extremely low power levels while in an operational sleep state down to 1.4 µA.

BG22 is capable of dynamic voltage scaling (DVS), a power management technique used to make voltage changes "on-the-fly." DVS is an important power savings feature because the relationship between dynamic power consumption, operating frequency and operating voltage means that voltage scaling can significantly reduce power consumption.

Another BG22 feature is that it can disable the internal digital LDO. By disabling the LDO and replacing input from a buck converter, you can achieve 85-90 percent power transfer efficiency. A buck converter requires only a fraction of the LDO's current to supply the DECOUPLE node. Thus, by using an external dc/dc converter in the buck topology, you can achieve an efficiency of 30 to 40 percent over what the digital LDO would need to deliver the same energy to the digital logic.

Our EFP01 enables using an external dc/dc buck converter in place of the internal digital LDO. EFP01 is a flexible, highly efficient, multi-output power management IC dedicated for EFM32 MCUs and EFR32 wireless devices. It supports a broad range of input voltages (0.8 to 5.5 V), allowing developers to use different battery types and chemistries for optimal efficiency.

Used together, BG22 and EFP01 can achieve an even lower power consumption rate than using BG22 as a standalone device. This setup takes advantage of the following device features:

• Disabling internal LDO.
• Employing dynamic voltage scaling, which varies the voltage on the DECOUPLE pin from the external PMIC.

Test Setup

For testing, the EFP0108 PMIC variant was setup with the following parameters:

• DC/DC A configured as a boost, generating 1.8 V at the VOA rail and supplying all EFR32 rails
• DC/DC B used as a buck, supplying the BG22 DECOUPLE pin

The BG22 features the following parameters:

• Internal LDO off
• Dynamic voltage scaling varying the voltage from 0.9 to 1 V

All measurements (voltage, current, power) were taken at the VIN input node, representing a power supply input or a battery supply in real-world systems. Additionally, the setup supplies all the necessary BG22 rails and EFP01 current consumption while also accounting for all efficiencies in both dc/dc converters.

Software for the EFP0108 device was configured using the Simplicity Studio EFP Configuration Tool. BG22 software was configured using an SoC empty project, a software example project delivered with the Bluetooth Low Energy (LE) software stack and Gecko SDK (2.7.6).

Tests were conducted in both advertising and connection modes, with similar parameters for each test case. In both cases, the transition between modes were managed on-the-fly by the Bluetooth LE stack and the BG22 energy management unit (EMU).

Tests were run on a series of different designs, in the following order:

• Single 1.8 V supply, VOA only
• Single 1.8 V supply, VOA only + DVS
• Single 1.8 V supply, VOA & VOB
• Single 1.8 V supply, VOA & VOB + DVS

Each testing stage revealed increasing power consumption improvements, resulting in power and current consumption savings of 30 to 40 percent when using BG22 with a PMIC and employing DVS on a DECOUPLE power net.

The results of these tests demonstrate that BG22 can achieve even greater power savings than its best-in-class standards when combined with our energy-friendly EFP01 PMIC devices. To learn more about our BG22 and EFP01 devices' power-saving capabilities, contact your Silicon Labs sales representative.

When an IoT customer, impressed with our EFR32BG22 (BG22) performance, wanted to achieve the best possible battery life for their application, Silicon Labs accepted the challenge. Field Applications Engineer, Marius Turculet, began testing and found that BG22 could achieve 30 to 40 percent of power savings when combined with our EFP01 Energy Friendly PMIC family. Click here to watch the entire presentation and register now for future Tech Talks. Highlights from Marius' session are below.

EFR32BG22 and EFP01 Used Together

BG22 is our most energy-friendly wireless system-on-chip (SoC). Equipped with an Arm® Cortex®-M33 core, BG22 SoCs achieve extremely low power levels while in an operational sleep state down to 1.4 µA.

BG22 is capable of dynamic voltage scaling (DVS), a power management technique used to make voltage changes "on-the-fly." DVS is an important power savings feature because the relationship between dynamic power consumption, operating frequency and operating voltage means that voltage scaling can significantly reduce power consumption.

Another BG22 feature is that it can disable the internal digital LDO. By disabling the LDO and replacing input from a buck converter, you can achieve 85-90 percent power transfer efficiency. A buck converter requires only a fraction of the LDO's current to supply the DECOUPLE node. Thus, by using an external dc/dc converter in the buck topology, you can achieve an efficiency of 30 to 40 percent over what the digital LDO would need to deliver the same energy to the digital logic.

Our EFP01 enables using an external dc/dc buck converter in place of the internal digital LDO. EFP01 is a flexible, highly efficient, multi-output power management IC dedicated for EFM32 MCUs and EFR32 wireless devices. It supports a broad range of input voltages (0.8 to 5.5 V), allowing developers to use different battery types and chemistries for optimal efficiency.

Used together, BG22 and EFP01 can achieve an even lower power consumption rate than using BG22 as a standalone device. This setup takes advantage of the following device features:

• Disabling internal LDO.
• Employing dynamic voltage scaling, which varies the voltage on the DECOUPLE pin from the external PMIC.

Test Setup

For testing, the EFP0108 PMIC variant was setup with the following parameters:

• DC/DC A configured as a boost, generating 1.8 V at the VOA rail and supplying all EFR32 rails
• DC/DC B used as a buck, supplying the BG22 DECOUPLE pin

The BG22 features the following parameters:

• Internal LDO off
• Dynamic voltage scaling varying the voltage from 0.9 to 1 V

All measurements (voltage, current, power) were taken at the VIN input node, representing a power supply input or a battery supply in real-world systems. Additionally, the setup supplies all the necessary BG22 rails and EFP01 current consumption while also accounting for all efficiencies in both dc/dc converters.

Software for the EFP0108 device was configured using the Simplicity Studio EFP Configuration Tool. BG22 software was configured using an SoC empty project, a software example project delivered with the Bluetooth Low Energy (LE) software stack and Gecko SDK (2.7.6).

Tests were conducted in both advertising and connection modes, with similar parameters for each test case. In both cases, the transition between modes were managed on-the-fly by the Bluetooth LE stack and the BG22 energy management unit (EMU).

Tests were run on a series of different designs, in the following order:

• Single 1.8 V supply, VOA only
• Single 1.8 V supply, VOA only + DVS
• Single 1.8 V supply, VOA & VOB
• Single 1.8 V supply, VOA & VOB + DVS

Each testing stage revealed increasing power consumption improvements, resulting in power and current consumption savings of 30 to 40 percent when using BG22 with a PMIC and employing DVS on a DECOUPLE power net.

The results of these tests demonstrate that BG22 can achieve even greater power savings than its best-in-class standards when combined with our energy-friendly EFP01 PMIC devices. To learn more about our BG22 and EFP01 devices' power-saving capabilities, contact your Silicon Labs sales representative.

When an IoT customer, impressed with our EFR32BG22 (BG22) performance, wanted to achieve the best possible battery life for their application, Silicon Labs accepted the challenge. Field Applications Engineer, Marius Turculet, began testing and found that BG22 could achieve 30 to 40 percent of power savings when combined with our EFP01 Energy Friendly PMIC family. Click here to watch the entire presentation and register now for future Tech Talks. Highlights from Marius' session are below.

EFR32BG22 and EFP01 Used Together

BG22 is our most energy-friendly wireless system-on-chip (SoC). Equipped with an Arm® Cortex®-M33 core, BG22 SoCs achieve extremely low power levels while in an operational sleep state down to 1.4 µA.

BG22 is capable of dynamic voltage scaling (DVS), a power management technique used to make voltage changes "on-the-fly." DVS is an important power savings feature because the relationship between dynamic power consumption, operating frequency and operating voltage means that voltage scaling can significantly reduce power consumption.

Another BG22 feature is that it can disable the internal digital LDO. By disabling the LDO and replacing input from a buck converter, you can achieve 85-90 percent power transfer efficiency. A buck converter requires only a fraction of the LDO's current to supply the DECOUPLE node. Thus, by using an external dc/dc converter in the buck topology, you can achieve an efficiency of 30 to 40 percent over what the digital LDO would need to deliver the same energy to the digital logic.

Our EFP01 enables using an external dc/dc buck converter in place of the internal digital LDO. EFP01 is a flexible, highly efficient, multi-output power management IC dedicated for EFM32 MCUs and EFR32 wireless devices. It supports a broad range of input voltages (0.8 to 5.5 V), allowing developers to use different battery types and chemistries for optimal efficiency.

Used together, BG22 and EFP01 can achieve an even lower power consumption rate than using BG22 as a standalone device. This setup takes advantage of the following device features:

• Disabling internal LDO.
• Employing dynamic voltage scaling, which varies the voltage on the DECOUPLE pin from the external PMIC.

Test Setup

For testing, the EFP0108 PMIC variant was setup with the following parameters:

• DC/DC A configured as a boost, generating 1.8 V at the VOA rail and supplying all EFR32 rails
• DC/DC B used as a buck, supplying the BG22 DECOUPLE pin

The BG22 features the following parameters:

• Internal LDO off
• Dynamic voltage scaling varying the voltage from 0.9 to 1 V

All measurements (voltage, current, power) were taken at the VIN input node, representing a power supply input or a battery supply in real-world systems. Additionally, the setup supplies all the necessary BG22 rails and EFP01 current consumption while also accounting for all efficiencies in both dc/dc converters.

Software for the EFP0108 device was configured using the Simplicity Studio EFP Configuration Tool. BG22 software was configured using an SoC empty project, a software example project delivered with the Bluetooth Low Energy (LE) software stack and Gecko SDK (2.7.6).

Tests were conducted in both advertising and connection modes, with similar parameters for each test case. In both cases, the transition between modes were managed on-the-fly by the Bluetooth LE stack and the BG22 energy management unit (EMU).

Tests were run on a series of different designs, in the following order:

• Single 1.8 V supply, VOA only
• Single 1.8 V supply, VOA only + DVS
• Single 1.8 V supply, VOA & VOB
• Single 1.8 V supply, VOA & VOB + DVS

Each testing stage revealed increasing power consumption improvements, resulting in power and current consumption savings of 30 to 40 percent when using BG22 with a PMIC and employing DVS on a DECOUPLE power net.

The results of these tests demonstrate that BG22 can achieve even greater power savings than its best-in-class standards when combined with our energy-friendly EFP01 PMIC devices. To learn more about our BG22 and EFP01 devices' power-saving capabilities, contact your Silicon Labs sales representative.

In this Tech Talks session, Field Applications Engineer, Claudio Filho, describes the basics of Silicon Labs' Bluetooth LE Software structure as well as procedures for configuring the stack. Click here to watch the entire presentation and register now for future sessions. Highlights from Claudio's session are below. 

Bluetooth LE Software Features

Our Bluetooth LE software stack is 5.2-compliant, featuring dynamic transmission power control, the direction finding capabilities of Bluetooth 5.1, and standard features of Bluetooth 5.0 and 4.0. It is packed with functionality such as simultaneous advertising and scanning and is optimized for low-power consumption with the ability to go into sleep mode when inactive. 

The software stack can be used to create standalone Bluetooth applications for Wireless Gecko SoCs or modules or alternatively, network co-processor (NCP) applications. With the SoC model, which is the focus of this Tech Talk, the SoC is at the heart of the application, such as for wearable devices or smart lighting.  

Project Structure

The software stack is built on top of the EFR32 platform and includes the following components:

• Gecko bootloader – distributed as source; has its own project structure.
• Bluetooth stack and RAIL libraries – stack is distributed as a binary file; RAIL enables multiprotocol.
• GATT related files – user-friendly GUI enables creating GATT database files.
• Application libraries – emlib and emdrv libraries are used by the stack but can also be used by the application. Examples are available on our GitHub page.

Application Build Flow

The first step to configuring the Bluetooth LE software stack for your application is to open an empty SoC example project from the Simplicity Studio IDE. From here, you will have access to the Visual GATT Editor, a graphical tool for defining the GATT and generating gatt_db.c and gatt_db.h files.

With the GATT configurator, you can start with any pre-defined Bluetooth SIG profiles and drag-and-drop them into the configurator window. Adjustable settings allow you to customize the Bluetooth SIG services, characteristics and descriptors as needed. You can also import GATT data from external XML files.

A compiler will combine the GATT generated database files with your own application source code and begin building your project. Compiling the project generates an object file, which is then linked with the pre-compiled libraries provided in the SDK. The output of the linking is a flash image that can be programmed for production. You can also generate GBL files for enabling over-the-air (OTA) updates if needed.

Configuring Hardware and the BLE Stack

Two important files for configuring hardware within the empty SoC structure are:

• hal-config.h file – enables board features.
• hal-config-board.h file – enables hardware.

These files enable code re-use among different components and peripherals. A forthcoming UI will allow you to generate these files automatically.

The Bluetooth LE stack configuration is managed within the main.c file. From this file, you can customize several parameters of our stack. The file is pre-programmed for low-power management.

Our stacks are event-driven, and events can be blocking or non-blocking. All stack events are handled at App.c.

Support

Visit docs.silabs.com for supporting documentation including application notes, reference manuals, and user guides. Our GitHub pages include library and peripheral examples. For more information about our Bluetooth LE software stack solutions, contact your Silicon Labs sales representative.

In this Tech Talks session, Field Applications Engineer, Claudio Filho, describes the basics of Silicon Labs' Bluetooth LE Software structure as well as procedures for configuring the stack. Click here to watch the entire presentation and register now for future sessions. Highlights from Claudio's session are below. 

Bluetooth LE Software Features

Our Bluetooth LE software stack is 5.2-compliant, featuring dynamic transmission power control, the direction finding capabilities of Bluetooth 5.1, and standard features of Bluetooth 5.0 and 4.0. It is packed with functionality such as simultaneous advertising and scanning and is optimized for low-power consumption with the ability to go into sleep mode when inactive. 

The software stack can be used to create standalone Bluetooth applications for Wireless Gecko SoCs or modules or alternatively, network co-processor (NCP) applications. With the SoC model, which is the focus of this Tech Talk, the SoC is at the heart of the application, such as for wearable devices or smart lighting.  

Project Structure

The software stack is built on top of the EFR32 platform and includes the following components:

• Gecko bootloader – distributed as source; has its own project structure.
• Bluetooth stack and RAIL libraries – stack is distributed as a binary file; RAIL enables multiprotocol.
• GATT related files – user-friendly GUI enables creating GATT database files.
• Application libraries – emlib and emdrv libraries are used by the stack but can also be used by the application. Examples are available on our GitHub page.

Application Build Flow

The first step to configuring the Bluetooth LE software stack for your application is to open an empty SoC example project from the Simplicity Studio IDE. From here, you will have access to the Visual GATT Editor, a graphical tool for defining the GATT and generating gatt_db.c and gatt_db.h files.

With the GATT configurator, you can start with any pre-defined Bluetooth SIG profiles and drag-and-drop them into the configurator window. Adjustable settings allow you to customize the Bluetooth SIG services, characteristics and descriptors as needed. You can also import GATT data from external XML files.

A compiler will combine the GATT generated database files with your own application source code and begin building your project. Compiling the project generates an object file, which is then linked with the pre-compiled libraries provided in the SDK. The output of the linking is a flash image that can be programmed for production. You can also generate GBL files for enabling over-the-air (OTA) updates if needed.

Configuring Hardware and the BLE Stack

Two important files for configuring hardware within the empty SoC structure are:

• hal-config.h file – enables board features.
• hal-config-board.h file – enables hardware.

These files enable code re-use among different components and peripherals. A forthcoming UI will allow you to generate these files automatically.

The Bluetooth LE stack configuration is managed within the main.c file. From this file, you can customize several parameters of our stack. The file is pre-programmed for low-power management.

Our stacks are event-driven, and events can be blocking or non-blocking. All stack events are handled at App.c.

Support

Visit docs.silabs.com for supporting documentation including application notes, reference manuals, and user guides. Our GitHub pages include library and peripheral examples. For more information about our Bluetooth LE software stack solutions, contact your Silicon Labs sales representative.

In this Tech Talks session, Field Applications Engineer, Claudio Filho, describes the basics of Silicon Labs' Bluetooth LE Software structure as well as procedures for configuring the stack. Click here to watch the entire presentation and register now for future sessions. Highlights from Claudio's session are below. 

Bluetooth LE Software Features

Our Bluetooth LE software stack is 5.2-compliant, featuring dynamic transmission power control, the direction finding capabilities of Bluetooth 5.1, and standard features of Bluetooth 5.0 and 4.0. It is packed with functionality such as simultaneous advertising and scanning and is optimized for low-power consumption with the ability to go into sleep mode when inactive. 

The software stack can be used to create standalone Bluetooth applications for Wireless Gecko SoCs or modules or alternatively, network co-processor (NCP) applications. With the SoC model, which is the focus of this Tech Talk, the SoC is at the heart of the application, such as for wearable devices or smart lighting.  

Project Structure

The software stack is built on top of the EFR32 platform and includes the following components:

• Gecko bootloader – distributed as source; has its own project structure.
• Bluetooth stack and RAIL libraries – stack is distributed as a binary file; RAIL enables multiprotocol.
• GATT related files – user-friendly GUI enables creating GATT database files.
• Application libraries – emlib and emdrv libraries are used by the stack but can also be used by the application. Examples are available on our GitHub page.

Application Build Flow

The first step to configuring the Bluetooth LE software stack for your application is to open an empty SoC example project from the Simplicity Studio IDE. From here, you will have access to the Visual GATT Editor, a graphical tool for defining the GATT and generating gatt_db.c and gatt_db.h files.

With the GATT configurator, you can start with any pre-defined Bluetooth SIG profiles and drag-and-drop them into the configurator window. Adjustable settings allow you to customize the Bluetooth SIG services, characteristics and descriptors as needed. You can also import GATT data from external XML files.

A compiler will combine the GATT generated database files with your own application source code and begin building your project. Compiling the project generates an object file, which is then linked with the pre-compiled libraries provided in the SDK. The output of the linking is a flash image that can be programmed for production. You can also generate GBL files for enabling over-the-air (OTA) updates if needed.

Configuring Hardware and the BLE Stack

Two important files for configuring hardware within the empty SoC structure are:

• hal-config.h file – enables board features.
• hal-config-board.h file – enables hardware.

These files enable code re-use among different components and peripherals. A forthcoming UI will allow you to generate these files automatically.

The Bluetooth LE stack configuration is managed within the main.c file. From this file, you can customize several parameters of our stack. The file is pre-programmed for low-power management.

Our stacks are event-driven, and events can be blocking or non-blocking. All stack events are handled at App.c.

Support

Visit docs.silabs.com for supporting documentation including application notes, reference manuals, and user guides. Our GitHub pages include library and peripheral examples. For more information about our Bluetooth LE software stack solutions, contact your Silicon Labs sales representative.