The carrier board design and the placement of the module strongly determine the module's antenna performance. In order to achieve the possible best RF performance the layout guidelines described in the module datasheet must be carefully followed.
Additionally, here are some highlights in regards to the module placement recommendations below.
- Place the module in the corner of the carrier board.
- If placing the module in the corner is not possible then place the module at the carrier PCB edge and ensrue an at least 20 mm copper clearance keep-out area from the module antenna.
- If the module is not being placed at the carrier board edge then the antenna gets de-tuned even if copper clearnace area is also ensured to the top direction from the antenna.
- So, placing the module exactly to the corner or board edge of the carreir PCB is essential.
- Also, try to avoid having any material in the close proximity (~ a few mm) of the module antenna. For metal material this minimum clearance is even higher, like 10-20 mm.
This article is demonstrating how to implement custom binary protocol between NCP target and host using specific features of BGAPI.
BGAPI support
Since Bluetooth SDK 2.6.0 the stack provides the following commands and events for that:
cmd_user_message_to_target
evt_user_message_to_host
See the details in API reference manual [1].
The cmd_user_message_to_target command can be used by an NCP host to send a message to the target application on device. To send a custom message with this API command the host have to send the byte sequence specified below to the target. Byte 4..255 can be the custom messsage itself.
Once the target receives this byte sequence it must response with the byte sequence specified below. Byte 6 to 255 can be used for the custom response.
Additionally, the evt_user_message_to_host event can be used by the target to send a message to NCP host. The target must send the byte sequence specified below. Byte 4..255 can be the custom messsage itself.
The native_gecko.h provides a utility function which can send out the required byte sequence. See the declaration below.
In the attached example a user command handling framework has been added to the NCP example for demonstarting the feature. The framework calls handle_user_command function if a command ID is gecko_cmd_user_message_to_target_id.
Default handle_user_command() is declared as weak so that user can override it in other source file of the application. In this example the handle_user_command() function overrided in the main.c
The following codesnippets highlights the modifiaction against the default NCP example.
Declaration of handle_user_command in ncp.h:
/***************************************************************************//**
* @brief
* Called when a user command (Message ID: gecko_cmd_user_message_to_target_id)
* is received.
*
* @details
* Implement this function if the BGAPI protocol is extended at application layer
* between the host and target for data exchange. At the end of command handling,
* a response to this command must be sent to the host. Use
* gecko_send_rsp_user_message_to_target(uint16_t, uint8_t, uint8_t*) to send the
* response.
*
* The target can also initiate the communication by sending event messages
* (Message ID: gecko_evt_user_message_to_host_id) to the host by using API
* gecko_send_evt_user_message_to_host(uint8_t, uint8_t*).
*
* Notice that events should not be sent in the context of user command handling.
*
* @param[in] payload
* the data payload in the command message
******************************************************************************/
void handle_user_command(const uint8array *payload);
The default implementation of handle_user_command() in ncp.c:
void ncp_handle_command(){
if (command_received()) {
uint32_t *cmd_header = (uint32_t *)rx_queue.data;
if (BGLIB_MSG_ID(*cmd_header) == gecko_cmd_user_message_to_target_id) {
handle_user_command((void*)&rx_queue.data[BGLIB_MSG_HEADER_LEN]);
} else {
gecko_handle_command(*cmd_header,(void*)&rx_queue.data[BGLIB_MSG_HEADER_LEN]);
}
ncp_transmit_enqueue(gecko_rsp_msg);
// reset the buffer after the command is handled
rx_queue_reset();
}
ncp_transmit();
}
Application example
The attached example echoes back the payload received from the host immediatly. Receiving the user message starts a 2 second long one shot timer. To achive this the handle_user_command() has to be overridden as it shown below.
/**
* handle for receiving message from the HOST
*/
void handle_user_command(const uint8array *payload)
{
user_event_data_len = payload->len > USER_EVENT_DATA_MAX_LEN ? USER_EVENT_DATA_MAX_LEN : payload->len;
memcpy(user_event_data, payload->data, user_event_data_len);
/* Start one shot timer for generating a user event to demonstrate HOST to TARGET communication */
gecko_cmd_hardware_set_soft_timer(2*SECOND, USER_EVENT_ID, 1);
/* Loop back payload as a response */
gecko_send_rsp_user_message_to_target(bg_err_success, payload->len, payload->data);
}
Once the timer fires the target sends the previous payload again.
/* soft timer fired event */
case gecko_evt_hardware_soft_timer_id:
/* check which softtimer fired */
if (evt->data.evt_hardware_soft_timer.handle == USER_EVENT_ID) {
/* user event can be sent out to HOST */
/* echo the last custom message from the HOST */
gecko_send_evt_user_message_to_host(user_event_data_len, user_event_data);
}
break;
Testing the example
In SDK 2.6.0 the BGTool not supports the user event and command APIs. Therefore a terminal needed which supports binary communcation. On PC you may use H-Term [2].
Terminal settings
The attached example is using 115200 baud 8N1 with no flow control over J-Link USB CDC virtual COM port.
Communication sequence
The caputered log below shows that first we sent a user message from the host to target with the payload 0x02 0x55 0xAA then the target sent back a response with the same payload.
Then a timer event happened. After that a user message event occured with the same payload.
Note: This example has been modified after 2.6.x SDK and there is an updated version of this KBA here covering newer SDK versions.
Introduction
The SDK version 2.6.0 introduces a new example for the Thunderboard Sense (TB Sense) called SOC – Voice over Bluetooth Low Energy which samples data from the analog microphone on TB Sense, runs it through a filter and codec and sends it over the Bluetooth link to a GATT client.
The GATT client application is also made available as source code in C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.0 \app\bluetooth_2.6\examples_ncp_host\voice_over_bluetooth_low_energy_app. You need to install a tool such as cygwin to build the project into an executable.
How to Use It
To test this solution you need one TB Sense and one WSTK with any of our EFR32xG or BGM radio boards.
Thunderboard Sense (GATT Server)
For the TB Sense side you can simply open the SOC – Voice over Bluetooth Low Energy and flash it as is. The only option available in this application is which type of filter you want to use. The filter types are listed in filter_type_t in filter.h.
On the WSTK side you can simply flash the pre-compiled NCP target – Empty example for the specific radio board that you are using to enable communication with the PC.
Then open a command line prompt, navigate to the directory where the host side executable is located and run voice_over_bluetooth_low_energy_app.exe to get the help menu.
Let’s go through each the options here:
COM Port: this is the COM Port for your NCP device, you can check it using BGTool, the WSTK lists as a “JLink CDC UART Port”.
Baud rate: NCP-empty example has 115200 by default and there is no need to change this
Output file name: filename where you want your audio data to be stored in, it doesn’t need to have any extension.
Remote device Bluetooth address: Bluetooth address of the TB Sense board that you are using as GATT client. This can be read using the Commander as instructed at the beginning of this article.
ADC sampling rate: the options are 16kHz or 8kHz, you only need to put the number e.g. –s 16
ADC resolution: the options are 8 or 12 bits, only number is needed as well e.g. –r 12
Enable/Disable filtering: default is disabled if you omit this option. To enable it write –f 1
Enable/Disable notification for Audio Data characteristic: this can be omitted
Help: prints out the help shown in the above image (which is also printed if you call the executable without any arguments)
Verbose: If this switch is added the application prints out status messages
Running the Solution
With the firmware SOC – Voice over Bluetooth Low Energy flashed into the TB Sense and the NCP – empty flashed into the radio board on the WSTK you can bring up the command prompt and navigate to the directory where the GATT client application executable is located. Then call the executable with your chosen sampling rate, resolution and output file name. In the example below we are using the maximum for both sampling rate and resolution (16kHz and 12 bits respectively) and saving the audio data in a file called my_audio_file.
If you have activated verbose as in the above image you will get status messages from the GATT client application. The application will stop printing status messages after is has written all the configurations which in the above image is after enabling filtering. At this stage the application is just waiting for notifications from the GATT client with the audio data so it can be stored in the chosen file.
You can then press SW1 button in the TB Sense to start streaming audio data and SW2 to stop streaming. All the audio data will be saved into the same file and if the file name given as parameter already exists then the audio data will be appended to the existing file.
Importing to Audacity
To listen to the audio you can use a freeware tool such as Audacity to import and decode the data. In Audacity select File -> Import -> Raw Data and select the audio file you have created. The select VOX ADPCM encoding and write down the sample rate that you used, either 8000 or 16000 Hz. In this example 16000 Hz was used.
Once the file is imported you can listen to it by pressing the Play button on the top left corner. Then you can export the file to wav format through File -> Export Audio and upload it to Watson’s Speech to Text to get a speech transcription.
How it Works
The block diagram below summarizes the data flow from the analog microphone into the Bluetooth link.
The EFR32 on the TB Sense samples the analog microphone using the ADC with the sampling rate and resolution configured by the GATT client. The sampled data is then run through a digital filter (if the filter usage is enabled) and coded using ADPCM codec before being sent via the Bluetooth link to the GATT client using notifications.
On the GATT client side, the application starts by sending the configurations to the TB Sense and then it just waits for the audio data to be sent over notifications and stores into a file.
This KBA summarizes the COEX feature itself then walks through how to enable the feature in a Bluetooth SDK project. Finally, it shows how the COEX signals behaves while the Bluetooth device advertising, scanning or in connection.
What is COEX?
COEX feature is a 3 wire PTA implementation introduced in Silicon Labs Bluetooth SDK v2.6.0 release.
What is PTA?
PTA stands for Packet Traffic Arbitration and PTA is described in IEEE 802.15.2 (2003) Clause 6 and is a recommendation, not a standard. The PTA mechanism coordinates sharing of the medium dynamically, based on the traffic load of the two wireless networks, in this case Bluetooth and Wi-Fi.
3-Wire PTA
There are 1, 2, 3 and 4 wire PTA implementations exist. Silicon Labs Bluetooth SDK supports the 3 wire PTA implementation which is the most common used in Wi-Fi devices.
In 3-Wire PTA 3 signals defined
GRANT
REQUEST
PRIORITY
The Wi-Fi device asserts a GRANT signal when Wi-Fi is not busy transmitting or receiving. When GRANT is asserted, the Bluetooth radio can transmit or receive.
The REQUEST signal is allowing the Bluetooth radio to request the 2.4 GHz ISM band. The Wi-Fi device internally controls the prioritization between Bluetooth and Wi-Fi and, on a conflict, the Wifi device can choose to either GRANT Bluetooth or Wi-Fi.
The PRIORITY signal is allowing the Bluetooth radio to signify a high or low priority message is either being received or transmitted. The Wi-Fi device compares this external priority request against the internal Wi-Fi priority, which may be high/low or high/mid/low and can choose to either GRANT Bluetooth or Wi-Fi.
Note: PRIORITY can be implemented as static or time-shared (enhanced) priority. As of PTA support implementation in Silicon Labs SDKs only supports static priority.
• Static: PRIORITY is either high or low during REQUEST asserted for the transmit or receive operation.
• Time-Shared: PRIORITY is either high or low for a typically 20 µs duration after REQUEST asserted, but switches to low during receive operation and high during transmit operation. Given the relatively low RF duty cycle of 802.15.4, static PRIORITY can be always asserted at the Wi-Fi/PTA input with the EFR32 PTA operating in 2-Wire mode. This frees a GPIO pin on the EFR32 and eliminates a circuit board trace.
Project setup
To enable the COEX feature in a Bluetooth SDK project the libcoex.a library has to be added to the project.
The library can be used only with Bluetooth stack, not compatible with other Silicon Labs stacks. The library increases flash consumption by ~1kB. It has dependencies to em_gpio.c, gpiointerrupt.c files which are provided by the gecko sdk suit.
In Simplicity Studio, the library name and the library path has to be added to the project.
COEX library path is depending on the MCU variant and the complier. See the default path for EFR32BG1B device using GCC complier
The COEX library name and the library path can be specified in the project properties dialog as shown below. In case using GCC the lib prefix has to be removed from the library name.
COEX configuration
Once the libcoex.a library added to the project the COEX feature has to be configured for the system needs. There are options which can be configured in compile time via preprocessor switches (#defines) and there are options which can be configured runtime via API calls.
Compile time options
The following #define-s must be set in hal-config.h. The file can be found in Bluetooth SDK example-s root.
// Enable 802.11 co-ex feature in gecko_init
#define HAL_COEX_ENABLE 1
// Request window in microseconds
// How many us before the TX/RX request signal is enabled
#define HAL_COEX_REQ_WINDOW 500
// Grant signal polarity, pin and port
#define BSP_COEX_GNT_ASSERT_LEVEL 0
#define BSP_COEX_GNT_PIN 12
#define BSP_COEX_GNT_PORT gpioPortD
// Priority signal polarity, pin and port
#define BSP_COEX_PRI_ASSERT_LEVEL 0
#define BSP_COEX_PRI_PIN 11
#define BSP_COEX_PRI_PORT gpioPortD
// Request signal polarity, pin and port
#define BSP_COEX_REQ_ASSERT_LEVEL 0
#define BSP_COEX_REQ_PIN 10
#define BSP_COEX_REQ_PORT gpioPortD
// Shared request in case multiple EFR32 radios are used
#define HAL_COEX_REQ_SHARED 0
// Enable priority signal (set both to 1)
#define HAL_COEX_TX_HIPRI 1
#define HAL_COEX_RX_HIPRI 1
// Abort TX if grant is denied during ongoing TX operation
#define HAL_COEX_TX_ABORT 1
COEX API
The COEX feature have to be initialized by calling gecko_initCoexHAL() API function. For convenience this is done by the void gecko_init(const gecko_configuration_t *config) API by default.
Runtime options
The gecko_cmd_coex_set_options(uint32_t mask, uint32_t options) API can be used for modify COEX options in runtime. The following option can be configured:
Enable/disable coexistence: coex_option_enable
Abort TX in GRANT denial: coex_option_tx_abort
Enable/disable high PRIORITY: coex_option_high_priority
See the API documentation and chapter 2.1 in the Bluetooth API reference
Shared REQUEST feature
The Shared REQUEST feature is needed when one master (Wi-Fi) controls multiple EFR32 slaves. In this case all devices share the same REQUEST, PRIORITY, and GRANT signals therefore it is mandatory that GPIO configuration (polarity, open drain/source mode, pull-up/down resistor) is consistent across the devices. This feature can be turned on by the #define HAL_COEX_REQ_SHARED preprocessor switch.
COEX signals in practice
In this setup, all 3 COEX signals and the radio RX/TX signals of the Bluetooth device connected to a logic analyzer.The radio TX/RX signals are active high signals so they are high if there is a radio activity ongoing
The GRANT signal configured to active low and it is always low. So, the Wi-Fi device always let the Bluetooth device to transmit or receive once it requested.
The REQUEST signal configured to active low. So, it is low when Bluetooth device requests the radio usage.
The PRIORITY signal is active low so the priority is high when the signal is low.
COEX signals in connectable advertising
At A1 marker, the REQUEST signal is active with high priority. After 500 usec at A2 marker, the TX starts followed by RX. Note that the actual radio operation starts 500 usec later then the REQUEST signal is active. This is because the HAL_COEX_REQ_WINDOW defined to 500 in hal-config.h.
The RX/TX sequence repeated for all 3 advertising channels. After the last RX, the REQUEST signal deactivated and the PRIORITY set to low.
COEX signals in scannig
During the scan interval, the REQUEST signal is active and the radio get RX interrupts as it is indicated by the RX signal.
COEX signals in connection
In a connection as slave device, EFR32 is receiving first, then transmitting. The actual radio operation is again delayed 500 usec after REQUEST because the configured request window.
How to add radio activity signals
For debug purposes, it is wise to enable radio RX/TX signals however these are not mandatory in real world application.
Adding the radio activity signals can be done in few steps. See this KBA about the process:
This KBA summarizes the COEX feature itself then walks through how to enable the feature in a Bluetooth SDK project. Finally, it shows how the COEX signals behaves while the Bluetooth device advertising, scanning or in connection.
What is COEX?
COEX feature is a 3 wire PTA implementation introduced in Silicon Labs Bluetooth SDK v2.6.0 release.
What is PTA?
PTA stands for Packet Traffic Arbitration and PTA is described in IEEE 802.15.2 (2003) Clause 6 and is a recommendation, not a standard. The PTA mechanism coordinates sharing of the medium dynamically, based on the traffic load of the two wireless networks, in this case Bluetooth and Wi-Fi.
3-Wire PTA
There are 1, 2, 3 and 4 wire PTA implementations exist. Silicon Labs Bluetooth SDK supports the 3 wire PTA implementation which is the most common used in Wi-Fi devices.
In 3-Wire PTA 3 signals defined
GRANT
REQUEST
PRIORITY
The Wi-Fi device asserts a GRANT signal when Wi-Fi is not busy transmitting or receiving. When GRANT is asserted, the Bluetooth radio can transmit or receive.
The REQUEST signal is allowing the Bluetooth radio to request the 2.4 GHz ISM band. The Wi-Fi device internally controls the prioritization between Bluetooth and Wi-Fi and, on a conflict, the Wifi device can choose to either GRANT Bluetooth or Wi-Fi.
The PRIORITY signal is allowing the Bluetooth radio to signify a high or low priority message is either being received or transmitted. The Wi-Fi device compares this external priority request against the internal Wi-Fi priority, which may be high/low or high/mid/low and can choose to either GRANT Bluetooth or Wi-Fi.
Note: PRIORITY can be implemented as static or time-shared (enhanced) priority. As of PTA support implementation in Silicon Labs SDKs only supports static priority.
• Static: PRIORITY is either high or low during REQUEST asserted for the transmit or receive operation.
• Time-Shared: PRIORITY is either high or low for a typically 20 µs duration after REQUEST asserted, but switches to low during receive operation and high during transmit operation. Given the relatively low RF duty cycle of 802.15.4, static PRIORITY can be always asserted at the Wi-Fi/PTA input with the EFR32 PTA operating in 2-Wire mode. This frees a GPIO pin on the EFR32 and eliminates a circuit board trace.
Project setup
To enable the COEX feature in a Bluetooth SDK project the libcoex.a library has to be added to the project.
The library can be used only with Bluetooth stack, not compatible with other Silicon Labs stacks. The library increases flash consumption by ~1kB. It has dependencies to em_gpio.c, gpiointerrupt.c files which are provided by the gecko sdk suit.
In Simplicity Studio, the library name and the library path has to be added to the project.
COEX library path is depending on the MCU variant and the complier. See the default path for EFR32BG1B device using GCC complier
The COEX library name and the library path can be specified in the project properties dialog as shown below. In case using GCC the lib prefix has to be removed from the library name.
COEX configuration
Once the libcoex.a library added to the project the COEX feature has to be configured for the system needs. There are options which can be configured in compile time via preprocessor switches (#defines) and there are options which can be configured runtime via API calls.
Compile time options
The following #define-s must be set in hal-config.h. The file can be found in Bluetooth SDK example-s root.
// Enable 802.11 co-ex feature in gecko_init
#define HAL_COEX_ENABLE 1
// Request window in microseconds
// How many us before the TX/RX request signal is enabled
#define HAL_COEX_REQ_WINDOW 500
// Grant signal polarity, pin and port
#define BSP_COEX_GNT_ASSERT_LEVEL 0
#define BSP_COEX_GNT_PIN 12
#define BSP_COEX_GNT_PORT gpioPortD
// Priority signal polarity, pin and port
#define BSP_COEX_PRI_ASSERT_LEVEL 0
#define BSP_COEX_PRI_PIN 11
#define BSP_COEX_PRI_PORT gpioPortD
// Request signal polarity, pin and port
#define BSP_COEX_REQ_ASSERT_LEVEL 0
#define BSP_COEX_REQ_PIN 10
#define BSP_COEX_REQ_PORT gpioPortD
// Shared request in case multiple EFR32 radios are used
#define HAL_COEX_REQ_SHARED 0
// Enable priority signal (set both to 1)
#define HAL_COEX_TX_HIPRI 1
#define HAL_COEX_RX_HIPRI 1
// Abort TX if grant is denied during ongoing TX operation
#define HAL_COEX_TX_ABORT 1
COEX API
The COEX feature have to be initialized by calling gecko_initCoexHAL() API function. For convenience this is done by the void gecko_init(const gecko_configuration_t *config) API by default.
Runtime options
The gecko_cmd_coex_set_options(uint32_t mask, uint32_t options) API can be used for modify COEX options in runtime. The following option can be configured:
Enable/disable coexistence: coex_option_enable
Abort TX in GRANT denial: coex_option_tx_abort
Enable/disable high PRIORITY: coex_option_high_priority
See the API documentation and chapter 2.1 in the Bluetooth API reference
Shared REQUEST feature
The Shared REQUEST feature is needed when one master (Wi-Fi) controls multiple EFR32 slaves. In this case all devices share the same REQUEST, PRIORITY, and GRANT signals therefore it is mandatory that GPIO configuration (polarity, open drain/source mode, pull-up/down resistor) is consistent across the devices. This feature can be turned on by the #define HAL_COEX_REQ_SHARED preprocessor switch.
COEX signals in practice
In this setup, all 3 COEX signals and the radio RX/TX signals of the Bluetooth device connected to a logic analyzer.The radio TX/RX signals are active high signals so they are high if there is a radio activity ongoing
The GRANT signal configured to active low and it is always low. So, the Wi-Fi device always let the Bluetooth device to transmit or receive once it requested.
The REQUEST signal configured to active low. So, it is low when Bluetooth device requests the radio usage.
The PRIORITY signal is active low so the priority is high when the signal is low.
COEX signals in connectable advertising
At A1 marker, the REQUEST signal is active with high priority. After 500 usec at A2 marker, the TX starts followed by RX. Note that the actual radio operation starts 500 usec later then the REQUEST signal is active. This is because the HAL_COEX_REQ_WINDOW defined to 500 in hal-config.h.
The RX/TX sequence repeated for all 3 advertising channels. After the last RX, the REQUEST signal deactivated and the PRIORITY set to low.
COEX signals in scannig
During the scan interval, the REQUEST signal is active and the radio get RX interrupts as it is indicated by the RX signal.
COEX signals in connection
In a connection as slave device, EFR32 is receiving first, then transmitting. The actual radio operation is again delayed 500 usec after REQUEST because the configured request window.
How to add radio activity signals
For debug purposes, it is wise to enable radio RX/TX signals however these are not mandatory in real world application.
Adding the radio activity signals can be done in few steps. See this KBA about the process:
This KBA summarizes the COEX feature itself then walks through how to enable the feature in a Bluetooth SDK project. Finally, it shows how the COEX signals behaves while the Bluetooth device advertising, scanning or in connection.
What is COEX?
COEX feature is a 3 wire PTA implementation introduced in Silicon Labs Bluetooth SDK v2.6.0 release.
What is PTA?
PTA stands for Packet Traffic Arbitration and PTA is described in IEEE 802.15.2 (2003) Clause 6 and is a recommendation, not a standard. The PTA mechanism coordinates sharing of the medium dynamically, based on the traffic load of the two wireless networks, in this case Bluetooth and Wi-Fi.
3-Wire PTA
There are 1, 2, 3 and 4 wire PTA implementations exist. Silicon Labs Bluetooth SDK supports the 3 wire PTA implementation which is the most common used in Wi-Fi devices.
In 3-Wire PTA 3 signals defined
GRANT
REQUEST
PRIORITY
The Wi-Fi device asserts a GRANT signal when Wi-Fi is not busy transmitting or receiving. When GRANT is asserted, the Bluetooth radio can transmit or receive.
The REQUEST signal is allowing the Bluetooth radio to request the 2.4 GHz ISM band. The Wi-Fi device internally controls the prioritization between Bluetooth and Wi-Fi and, on a conflict, the Wifi device can choose to either GRANT Bluetooth or Wi-Fi.
The PRIORITY signal is allowing the Bluetooth radio to signify a high or low priority message is either being received or transmitted. The Wi-Fi device compares this external priority request against the internal Wi-Fi priority, which may be high/low or high/mid/low and can choose to either GRANT Bluetooth or Wi-Fi.
Note: PRIORITY can be implemented as static or time-shared (enhanced) priority. As of PTA support implementation in Silicon Labs SDKs only supports static priority.
• Static: PRIORITY is either high or low during REQUEST asserted for the transmit or receive operation.
• Time-Shared: PRIORITY is either high or low for a typically 20 µs duration after REQUEST asserted, but switches to low during receive operation and high during transmit operation. Given the relatively low RF duty cycle of 802.15.4, static PRIORITY can be always asserted at the Wi-Fi/PTA input with the EFR32 PTA operating in 2-Wire mode. This frees a GPIO pin on the EFR32 and eliminates a circuit board trace.
Project setup
To enable the COEX feature in a Bluetooth SDK project the libcoex.a library has to be added to the project.
The library can be used only with Bluetooth stack, not compatible with other Silicon Labs stacks. The library increases flash consumption by ~1kB. It has dependencies to em_gpio.c, gpiointerrupt.c files which are provided by the gecko sdk suit.
In Simplicity Studio, the library name and the library path has to be added to the project.
COEX library path is depending on the MCU variant and the complier. See the default path for EFR32BG1B device using GCC complier
The COEX library name and the library path can be specified in the project properties dialog as shown below. In case using GCC the lib prefix has to be removed from the library name.
COEX configuration
Once the libcoex.a library added to the project the COEX feature has to be configured for the system needs. There are options which can be configured in compile time via preprocessor switches (#defines) and there are options which can be configured runtime via API calls.
Compile time options
The following #define-s must be set in hal-config.h. The file can be found in Bluetooth SDK example-s root.
// Enable 802.11 co-ex feature in gecko_init
#define HAL_COEX_ENABLE 1
// Request window in microseconds
// How many us before the TX/RX request signal is enabled
#define HAL_COEX_REQ_WINDOW 500
// Grant signal polarity, pin and port
#define BSP_COEX_GNT_ASSERT_LEVEL 0
#define BSP_COEX_GNT_PIN 12
#define BSP_COEX_GNT_PORT gpioPortD
// Priority signal polarity, pin and port
#define BSP_COEX_PRI_ASSERT_LEVEL 0
#define BSP_COEX_PRI_PIN 11
#define BSP_COEX_PRI_PORT gpioPortD
// Request signal polarity, pin and port
#define BSP_COEX_REQ_ASSERT_LEVEL 0
#define BSP_COEX_REQ_PIN 10
#define BSP_COEX_REQ_PORT gpioPortD
// Shared request in case multiple EFR32 radios are used
#define HAL_COEX_REQ_SHARED 0
// Enable priority signal (set both to 1)
#define HAL_COEX_TX_HIPRI 1
#define HAL_COEX_RX_HIPRI 1
// Abort TX if grant is denied during ongoing TX operation
#define HAL_COEX_TX_ABORT 1
COEX API
The COEX feature have to be initialized by calling gecko_initCoexHAL() API function. For convenience this is done by the void gecko_init(const gecko_configuration_t *config) API by default.
Runtime options
The gecko_cmd_coex_set_options(uint32_t mask, uint32_t options) API can be used for modify COEX options in runtime. The following option can be configured:
Enable/disable coexistence: coex_option_enable
Abort TX in GRANT denial: coex_option_tx_abort
Enable/disable high PRIORITY: coex_option_high_priority
See the API documentation and chapter 2.1 in the Bluetooth API reference
Shared REQUEST feature
The Shared REQUEST feature is needed when one master (Wi-Fi) controls multiple EFR32 slaves. In this case all devices share the same REQUEST, PRIORITY, and GRANT signals therefore it is mandatory that GPIO configuration (polarity, open drain/source mode, pull-up/down resistor) is consistent across the devices. This feature can be turned on by the #define HAL_COEX_REQ_SHARED preprocessor switch.
COEX signals in practice
In this setup, all 3 COEX signals and the radio RX/TX signals of the Bluetooth device connected to a logic analyzer.The radio TX/RX signals are active high signals so they are high if there is a radio activity ongoing
The GRANT signal configured to active low and it is always low. So, the Wi-Fi device always let the Bluetooth device to transmit or receive once it requested.
The REQUEST signal configured to active low. So, it is low when Bluetooth device requests the radio usage.
The PRIORITY signal is active low so the priority is high when the signal is low.
COEX signals in connectable advertising
At A1 marker, the REQUEST signal is active with high priority. After 500 usec at A2 marker, the TX starts followed by RX. Note that the actual radio operation starts 500 usec later then the REQUEST signal is active. This is because the HAL_COEX_REQ_WINDOW defined to 500 in hal-config.h.
The RX/TX sequence repeated for all 3 advertising channels. After the last RX, the REQUEST signal deactivated and the PRIORITY set to low.
COEX signals in scannig
During the scan interval, the REQUEST signal is active and the radio get RX interrupts as it is indicated by the RX signal.
COEX signals in connection
In a connection as slave device, EFR32 is receiving first, then transmitting. The actual radio operation is again delayed 500 usec after REQUEST because the configured request window.
How to add radio activity signals
For debug purposes, it is wise to enable radio RX/TX signals however these are not mandatory in real world application.
Adding the radio activity signals can be done in few steps. See this KBA about the process:
This KBA summarizes the Coexistence feature then walks through on how to enable the feature in a Bluetooth SDK project. Finally, it shows how the Coexistence signals behave while the Bluetooth device advertising, scanning or in connection.
What is Coexistence?
Coexistence feature is a 3 wire PTA implementation introduced in Silicon Labs Bluetooth SDK v2.6.0 release.
What is PTA?
PTA stands for Packet Traffic Arbitration and described in IEEE 802.15.2 (2003) Clause 6. PTA is a recommendation, not a standard. The PTA mechanism coordinates sharing of the medium dynamically, based on the traffic load of the two wireless networks, in this case, Bluetooth and Wi-Fi.
3-Wire PTA
There are 1, 2, 3 and 4 wire PTA implementations exist. Silicon Labs Bluetooth SDK 2.6.0 supports the 3 wire PTA implementation which is the most common used in Wi-Fi devices. In later SDK versions the 1 and 2 wire options will be supported also.
In 3-Wire PTA 3 signals defined
GRANT
REQUEST
PRIORITY
The Wi-Fi device asserts a GRANT signal when Wi-Fi is not busy transmitting or receiving. When GRANT is asserted, the Bluetooth radio can transmit or receive.
The REQUEST signal is allowing the Bluetooth radio to request the 2.4 GHz ISM band. The Wi-Fi device internally controls the prioritization between Bluetooth and Wi-Fi and, on a conflict, the Wifi device can choose to either GRANT Bluetooth or Wi-Fi.
The PRIORITY signal is allowing the Bluetooth radio to signify a high or low priority message is either being received or transmitted. The Wi-Fi device compares this external priority request against the internal Wi-Fi priority, which may be high/low or high/mid/low and can choose to either GRANT Bluetooth or Wi-Fi.
Note: PRIORITY can be implemented as static or time-shared (enhanced) priority. As of PTA support implementation in Silicon Labs SDKs only supports static priority.
• Static: PRIORITY is either high or low during REQUEST asserted for the transmit or receive operation.
• Time-Shared: PRIORITY is either high or low for a typical 20 µs duration after REQUEST asserted, but switches to low during receive operation and high during transmit operation. Given the relatively low RF duty cycle of 802.15.4, static PRIORITY can be always asserted at the Wi-Fi/PTA input with the EFR32 PTA operating in 2-Wire mode. This frees a GPIO pin on the EFR32 and eliminates a circuit board trace. Unfortunately, the BLE SDK 2.6.0 release does not let to disable a PTA pin. However, it is possible to redirect PRIORITY to a not connected GPIO or even to an unbonded GPIO pad for given package.
Project setup
To enable the Coexistence feature in a Bluetooth SDK project the libcoex.a library has to be added to the project.
The library can be used only with Bluetooth stack, not compatible with other Silicon Labs stacks. The library increases flash consumption by ~1kB. It has dependencies to em_gpio.c, gpiointerrupt.c files which are provided by the gecko sdk suit.
In Simplicity Studio, the library name and the library path has to be added to the project.
Coexistence library path is depending on the MCU variant and the compiler. See the default path for EFR32BG1B device using GCC compiler
The Coexistence library name and the library path can be specified in the project properties dialog as shown below. In case using GCC the lib prefix has to be removed from the library name.
Coexistence configuration
Once the libcoex.a library added to the project the Coexistence feature has to be configured for the system needs. There are options which can be configured at compile time via preprocessor switches (#defines) and there are options which can be configured runtime via API calls.
Compile time options
The following #define-s must be set in hal-config.h. The file can be found in Bluetooth SDK example-s root.
// Enable 802.11 co-ex feature in gecko_init
#define HAL_COEX_ENABLE 1
// Request window in microseconds
// How many us before the TX/RX request signal is enabled
#define HAL_COEX_REQ_WINDOW 500
// Grant signal polarity, pin and port
#define BSP_COEX_GNT_ASSERT_LEVEL 0
#define BSP_COEX_GNT_PIN 12
#define BSP_COEX_GNT_PORT gpioPortD
// Priority signal polarity, pin and port
#define BSP_COEX_PRI_ASSERT_LEVEL 0
#define BSP_COEX_PRI_PIN 11
#define BSP_COEX_PRI_PORT gpioPortD
// Request signal polarity, pin and port
#define BSP_COEX_REQ_ASSERT_LEVEL 0
#define BSP_COEX_REQ_PIN 10
#define BSP_COEX_REQ_PORT gpioPortD
// Shared request in case multiple EFR32 radios are used
#define HAL_COEX_REQ_SHARED 0
// Enable priority signal (set both to 1)
#define HAL_COEX_TX_HIPRI 1
#define HAL_COEX_RX_HIPRI 1
// Abort TX if grant is denied during ongoing TX operation
#define HAL_COEX_TX_ABORT 1
Coexistence API
The Coexistence feature has to be initialized by calling gecko_initCoexHAL() API function. For convenience, this is done by the void gecko_init(const gecko_configuration_t *config) API by default.
Runtime options
The gecko_cmd_coex_set_options(uint32_t mask, uint32_t options) API can be used for modify COEX options in runtime. The following option can be configured:
Enable/disable coexistence: coex_option_enable
Abort TX in GRANT denial: coex_option_tx_abort
Enable/disable high PRIORITY: coex_option_high_priority
See the API documentation and chapter 2.1 in the Bluetooth API reference
Shared REQUEST feature
The Shared REQUEST feature is needed when one master (Wi-Fi) controls multiple EFR32 slaves. In this case, all devices share the same REQUEST, PRIORITY, and GRANT signals, therefore, it is mandatory that GPIO configuration (polarity, open drain/source mode, pull-up/down resistor) is consistent across the devices. This feature can be turned on by the #define HAL_COEX_REQ_SHARED preprocessor switch.
Coexistence signals in practice
In this setup, all 3 Coexistence signals and the radio RX/TX signals of the Bluetooth device connected to a logic analyzer.The radio TX/RX signals are active high signals so they are high if there is a radio activity ongoing
The GRANT signal configured to active low and it is always low. So, the Wi-Fi device always let the Bluetooth device to transmit or receive once it requested.
The REQUEST signal configured to active low. So, it is low when Bluetooth device requests the radio usage.
The PRIORITY signal is active low so the priority is high when the signal is low.
Coexistencesignals in connectable advertising
At A1 marker, the REQUEST signal is active with high priority. After 500 usec at A2 marker, the TX starts followed by RX. Note that the actual radio operation starts 500 usec later then the REQUEST signal is active. This is because the HAL_COEX_REQ_WINDOW defined to 500 in hal-config.h.
The RX/TX sequence repeated for all 3 advertising channels. After the last RX, the REQUEST signal deactivated and the PRIORITY set to low.
Coexistence signals in scannig
During the scan interval, the REQUEST signal is active and the radio gets RX interrupts as it is indicated by the RX signal.
Coexistence signals in connection
In a connection as slave device, EFR32 is receiving first, then transmitting. The actual radio operation is again delayed 500 usec after REQUEST because of the configured request window.
How to add radio activity signals
For debug purposes, it is wise to enable radio RX/TX signals however these are not mandatory in real-world application.
Adding the radio activity signals can be done in few steps. See this KBA about the process:
Or you can configure the radio signals directly with the code snippets below:
#include <em_cmu.h>
#include <em_gpio.h>
CMU_ClockEnable(cmuClock_PRS, true); // Enable PRS clock
CMU_ClockEnable(cmuClock_GPIO, true); // Enable GPIO clock
GPIO_PinModeSet(gpioPortC, 10, gpioModePushPull, 0); // Set PC10 GPIO mode to push-pull
GPIO_PinModeSet(gpioPortC, 11, gpioModePushPull, 0); // Set PC11 GPIO mode to push-pull
PRS->CH[10].CTRL = PRS_RAC_RX | PRS_CH_CTRL_EDSEL_OFF; // Set PRS channel 10 for RX
PRS->CH[11].CTRL = PRS_RAC_TX | PRS_CH_CTRL_EDSEL_OFF; // Set PRS channel 11 for TX
PRS->ROUTELOC2 &= ~_PRS_ROUTELOC2_CH10LOC_MASK; // Route the PRS ch 10 to LOC4(PC10)
PRS->ROUTELOC2 |= PRS_ROUTELOC2_CH10LOC_LOC4;
PRS->ROUTELOC2 &= ~_PRS_ROUTELOC2_CH11LOC_MASK; // Route the PRS ch 11 to LOC4(PC11)
PRS->ROUTELOC2 |= PRS_ROUTELOC2_CH11LOC_LOC4;
PRS->ROUTEPEN |= PRS_ROUTEPEN_CH10PEN | PRS_ROUTEPEN_CH11PEN; // Enable PRS signals
GPIO pins
On the Bluetooth device 3 GPIO pin needs to be assigned for the REQUEST, PRIORITY and GRANT signals. For the optional RX/TX signals 2 more GPIO pin is needed.
PRS channel allocation
The REQUEST, PRIORITY and GRANT signals does not require PRS channels. But for the optional RX/TX signals 2 PRS channel is needed.
In Bluetooth SDK 2.6.0 PRS channel 7 is allocated to the Bluetooth stack so it can not be used for the RX/TX signals. PRS channel allocation may change in the future so please check the UG136 chapter 7 for the unused PRS channels.
NCP mode
In case of NCP mode the ncp_gecko_bgapi_class_coex_init() need to be called additionaly after gecko_init().
Custom boards
On custom boards, the init_board.c is empty. For using the coexistence feature the GPIO clock has to be enabled as shown below.
Bluetooth Knowledge Base
BLE112 module antenna performance
The carrier board design and the placement of the module strongly determine the module's antenna performance. In order to achieve the possible best RF performance the layout guidelines described in the module datasheet must be carefully followed.
Additionally, here are some highlights in regards to the module placement recommendations below.
- Place the module in the corner of the carrier board.
- If placing the module in the corner is not possible then place the module at the carrier PCB edge and ensrue an at least 20 mm copper clearance keep-out area from the module antenna.
- If the module is not being placed at the carrier board edge then the antenna gets de-tuned even if copper clearnace area is also ensured to the top direction from the antenna.
- So, placing the module exactly to the corner or board edge of the carreir PCB is essential.
- Also, try to avoid having any material in the close proximity (~ a few mm) of the module antenna. For metal material this minimum clearance is even higher, like 10-20 mm.
[Deprecated] KBA_BT_1601: Custom communication over NCP
Note: This KBA has been deprecated because this information was added to AN1042: Using the Silicon Labs Bluetooth® Stack in Network Co-Processor Mode
Introduction
This article is demonstrating how to implement custom binary protocol between NCP target and host using specific features of BGAPI.
BGAPI support
Since Bluetooth SDK 2.6.0 the stack provides the following commands and events for that:
See the details in API reference manual [1].
The cmd_user_message_to_target command can be used by an NCP host to send a message to the target application on device. To send a custom message with this API command the host have to send the byte sequence specified below to the target. Byte 4..255 can be the custom messsage itself.
Once the target receives this byte sequence it must response with the byte sequence specified below. Byte 6 to 255 can be used for the custom response.
Additionally, the evt_user_message_to_host event can be used by the target to send a message to NCP host. The target must send the byte sequence specified below. Byte 4..255 can be the custom messsage itself.
The native_gecko.h provides a utility function which can send out the required byte sequence. See the declaration below.
Example project
In the attached example a user command handling framework has been added to the NCP example for demonstarting the feature. The framework calls handle_user_command function if a command ID is gecko_cmd_user_message_to_target_id.
Default handle_user_command() is declared as weak so that user can override it in other source file of the application. In this example the handle_user_command() function overrided in the main.c
The following codesnippets highlights the modifiaction against the default NCP example.
Declaration of handle_user_command in ncp.h:
The default implementation of handle_user_command() in ncp.c:
Application example
The attached example echoes back the payload received from the host immediatly. Receiving the user message starts a 2 second long one shot timer. To achive this the handle_user_command() has to be overridden as it shown below.
Once the timer fires the target sends the previous payload again.
Testing the example
In SDK 2.6.0 the BGTool not supports the user event and command APIs. Therefore a terminal needed which supports binary communcation. On PC you may use H-Term [2].
Terminal settings
The attached example is using 115200 baud 8N1 with no flow control over J-Link USB CDC virtual COM port.
Communication sequence
The caputered log below shows that first we sent a user message from the host to target with the payload 0x02 0x55 0xAA then the target sent back a response with the same payload.
Then a timer event happened. After that a user message event occured with the same payload.
References
[1] c:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.0\app\bluetooth_2.6\doc\bluetooth-api-reference.pdf
[2] http://www.der-hammer.info/terminal/
[Deprecated] How to use Voice over Bluetooth Low Energy example for Thunderboard Sense
Note: This example has been modified after 2.6.x SDK and there is an updated version of this KBA here covering newer SDK versions.
Introduction
The SDK version 2.6.0 introduces a new example for the Thunderboard Sense (TB Sense) called SOC – Voice over Bluetooth Low Energy which samples data from the analog microphone on TB Sense, runs it through a filter and codec and sends it over the Bluetooth link to a GATT client.
The GATT client application is also made available as source code in C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.0 \app\bluetooth_2.6\examples_ncp_host\voice_over_bluetooth_low_energy_app. You need to install a tool such as cygwin to build the project into an executable.
How to Use It
To test this solution you need one TB Sense and one WSTK with any of our EFR32xG or BGM radio boards.
Thunderboard Sense (GATT Server)
For the TB Sense side you can simply open the SOC – Voice over Bluetooth Low Energy and flash it as is. The only option available in this application is which type of filter you want to use. The filter types are listed in filter_type_t in filter.h.
The default filter is HPF which is defined in DEFAULT_FILTER in the same file so here you can change to any other of the available filters.
WSTK (GATT Client)
On the WSTK side you can simply flash the pre-compiled NCP target – Empty example for the specific radio board that you are using to enable communication with the PC.
Then open a command line prompt, navigate to the directory where the host side executable is located and run voice_over_bluetooth_low_energy_app.exe to get the help menu.
Let’s go through each the options here:
Running the Solution
With the firmware SOC – Voice over Bluetooth Low Energy flashed into the TB Sense and the NCP – empty flashed into the radio board on the WSTK you can bring up the command prompt and navigate to the directory where the GATT client application executable is located. Then call the executable with your chosen sampling rate, resolution and output file name. In the example below we are using the maximum for both sampling rate and resolution (16kHz and 12 bits respectively) and saving the audio data in a file called my_audio_file.
If you have activated verbose as in the above image you will get status messages from the GATT client application. The application will stop printing status messages after is has written all the configurations which in the above image is after enabling filtering. At this stage the application is just waiting for notifications from the GATT client with the audio data so it can be stored in the chosen file.
You can then press SW1 button in the TB Sense to start streaming audio data and SW2 to stop streaming. All the audio data will be saved into the same file and if the file name given as parameter already exists then the audio data will be appended to the existing file.
Importing to Audacity
To listen to the audio you can use a freeware tool such as Audacity to import and decode the data. In Audacity select File -> Import -> Raw Data and select the audio file you have created. The select VOX ADPCM encoding and write down the sample rate that you used, either 8000 or 16000 Hz. In this example 16000 Hz was used.
Once the file is imported you can listen to it by pressing the Play button on the top left corner. Then you can export the file to wav format through File -> Export Audio and upload it to Watson’s Speech to Text to get a speech transcription.
How it Works
The block diagram below summarizes the data flow from the analog microphone into the Bluetooth link.
The EFR32 on the TB Sense samples the analog microphone using the ADC with the sampling rate and resolution configured by the GATT client. The sampled data is then run through a digital filter (if the filter usage is enabled) and coded using ADPCM codec before being sent via the Bluetooth link to the GATT client using notifications.
On the GATT client side, the application starts by sending the configurations to the TB Sense and then it just waits for the audio data to be sent over notifications and stores into a file.
[Deprecated] How to Import a Bluetooth Project into Simplicity Studio
Note: This article has been marked as deprecated. Please refer to the more updated KBA Exporting/Importing a project in Simplicity studio v4
To import a Bluetooth project into Simplicity Studio IDE do the following steps:
Enabling COEX feature in Bluetooth SDK projects
Introduction
This KBA summarizes the COEX feature itself then walks through how to enable the feature in a Bluetooth SDK project. Finally, it shows how the COEX signals behaves while the Bluetooth device advertising, scanning or in connection.
What is COEX?
COEX feature is a 3 wire PTA implementation introduced in Silicon Labs Bluetooth SDK v2.6.0 release.
What is PTA?
PTA stands for Packet Traffic Arbitration and PTA is described in IEEE 802.15.2 (2003) Clause 6 and is a recommendation, not a standard. The PTA mechanism coordinates sharing of the medium dynamically, based on the traffic load of the two wireless networks, in this case Bluetooth and Wi-Fi.
3-Wire PTA
There are 1, 2, 3 and 4 wire PTA implementations exist. Silicon Labs Bluetooth SDK supports the 3 wire PTA implementation which is the most common used in Wi-Fi devices.
In 3-Wire PTA 3 signals defined
The Wi-Fi device asserts a GRANT signal when Wi-Fi is not busy transmitting or receiving. When GRANT is asserted, the Bluetooth radio can transmit or receive.
The REQUEST signal is allowing the Bluetooth radio to request the 2.4 GHz ISM band. The Wi-Fi device internally controls the prioritization between Bluetooth and Wi-Fi and, on a conflict, the Wifi device can choose to either GRANT Bluetooth or Wi-Fi.
The PRIORITY signal is allowing the Bluetooth radio to signify a high or low priority message is either being received or transmitted. The Wi-Fi device compares this external priority request against the internal Wi-Fi priority, which may be high/low or high/mid/low and can choose to either GRANT Bluetooth or Wi-Fi.
Note: PRIORITY can be implemented as static or time-shared (enhanced) priority. As of PTA support implementation in Silicon Labs SDKs only supports static priority.
• Static: PRIORITY is either high or low during REQUEST asserted for the transmit or receive operation.
• Time-Shared: PRIORITY is either high or low for a typically 20 µs duration after REQUEST asserted, but switches to low during receive operation and high during transmit operation. Given the relatively low RF duty cycle of 802.15.4, static PRIORITY can be always asserted at the Wi-Fi/PTA input with the EFR32 PTA operating in 2-Wire mode. This frees a GPIO pin on the EFR32 and eliminates a circuit board trace.
Project setup
To enable the COEX feature in a Bluetooth SDK project the libcoex.a library has to be added to the project.
The library can be used only with Bluetooth stack, not compatible with other Silicon Labs stacks. The library increases flash consumption by ~1kB. It has dependencies to em_gpio.c, gpiointerrupt.c files which are provided by the gecko sdk suit.
In Simplicity Studio, the library name and the library path has to be added to the project.
COEX library path is depending on the MCU variant and the complier. See the default path for EFR32BG1B device using GCC complier
C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.0\protocol\bluetooth_2.6\lib\EFR32BG1B\GCC\libcoex.a
The COEX library name and the library path can be specified in the project properties dialog as shown below. In case using GCC the lib prefix has to be removed from the library name.
COEX configuration
Once the libcoex.a library added to the project the COEX feature has to be configured for the system needs. There are options which can be configured in compile time via preprocessor switches (#defines) and there are options which can be configured runtime via API calls.
Compile time options
The following #define-s must be set in hal-config.h. The file can be found in Bluetooth SDK example-s root.
COEX API
The COEX feature have to be initialized by calling gecko_initCoexHAL() API function. For convenience this is done by the void gecko_init(const gecko_configuration_t *config) API by default.
Runtime options
The gecko_cmd_coex_set_options(uint32_t mask, uint32_t options) API can be used for modify COEX options in runtime. The following option can be configured:
See the API documentation and chapter 2.1 in the Bluetooth API reference
Shared REQUEST feature
The Shared REQUEST feature is needed when one master (Wi-Fi) controls multiple EFR32 slaves. In this case all devices share the same REQUEST, PRIORITY, and GRANT signals therefore it is mandatory that GPIO configuration (polarity, open drain/source mode, pull-up/down resistor) is consistent across the devices. This feature can be turned on by the #define HAL_COEX_REQ_SHARED preprocessor switch.
COEX signals in practice
In this setup, all 3 COEX signals and the radio RX/TX signals of the Bluetooth device connected to a logic analyzer.The radio TX/RX signals are active high signals so they are high if there is a radio activity ongoing
The GRANT signal configured to active low and it is always low. So, the Wi-Fi device always let the Bluetooth device to transmit or receive once it requested.
The REQUEST signal configured to active low. So, it is low when Bluetooth device requests the radio usage.
The PRIORITY signal is active low so the priority is high when the signal is low.
COEX signals in connectable advertising
At A1 marker, the REQUEST signal is active with high priority. After 500 usec at A2 marker, the TX starts followed by RX. Note that the actual radio operation starts 500 usec later then the REQUEST signal is active. This is because the HAL_COEX_REQ_WINDOW defined to 500 in hal-config.h.
The RX/TX sequence repeated for all 3 advertising channels. After the last RX, the REQUEST signal deactivated and the PRIORITY set to low.
COEX signals in scannig
During the scan interval, the REQUEST signal is active and the radio get RX interrupts as it is indicated by the RX signal.
COEX signals in connection
In a connection as slave device, EFR32 is receiving first, then transmitting. The actual radio operation is again delayed 500 usec after REQUEST because the configured request window.
How to add radio activity signals
For debug purposes, it is wise to enable radio RX/TX signals however these are not mandatory in real world application.
Adding the radio activity signals can be done in few steps. See this KBA about the process:
https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/07/04/enabling_tx_rx_activ-V4T1
Or you can configure the radio signals directly with the code snippets below:
References
IEEE 802.15.2 (2003) Clause 6
https://www.silabs.com/documents/public/application-notes/an1017-coexistence-with-wifi.pdf
http://www.embedded-computing.com/embedded-computing-design/driving-wi-fi-zigbee-and-thread-coexistence-in-the-2-4-ghz-band-part-2-managed-coexistence
Enabling COEX feature in Bluetooth SDK projects
Introduction
This KBA summarizes the COEX feature itself then walks through how to enable the feature in a Bluetooth SDK project. Finally, it shows how the COEX signals behaves while the Bluetooth device advertising, scanning or in connection.
What is COEX?
COEX feature is a 3 wire PTA implementation introduced in Silicon Labs Bluetooth SDK v2.6.0 release.
What is PTA?
PTA stands for Packet Traffic Arbitration and PTA is described in IEEE 802.15.2 (2003) Clause 6 and is a recommendation, not a standard. The PTA mechanism coordinates sharing of the medium dynamically, based on the traffic load of the two wireless networks, in this case Bluetooth and Wi-Fi.
3-Wire PTA
There are 1, 2, 3 and 4 wire PTA implementations exist. Silicon Labs Bluetooth SDK supports the 3 wire PTA implementation which is the most common used in Wi-Fi devices.
In 3-Wire PTA 3 signals defined
The Wi-Fi device asserts a GRANT signal when Wi-Fi is not busy transmitting or receiving. When GRANT is asserted, the Bluetooth radio can transmit or receive.
The REQUEST signal is allowing the Bluetooth radio to request the 2.4 GHz ISM band. The Wi-Fi device internally controls the prioritization between Bluetooth and Wi-Fi and, on a conflict, the Wifi device can choose to either GRANT Bluetooth or Wi-Fi.
The PRIORITY signal is allowing the Bluetooth radio to signify a high or low priority message is either being received or transmitted. The Wi-Fi device compares this external priority request against the internal Wi-Fi priority, which may be high/low or high/mid/low and can choose to either GRANT Bluetooth or Wi-Fi.
Note: PRIORITY can be implemented as static or time-shared (enhanced) priority. As of PTA support implementation in Silicon Labs SDKs only supports static priority.
• Static: PRIORITY is either high or low during REQUEST asserted for the transmit or receive operation.
• Time-Shared: PRIORITY is either high or low for a typically 20 µs duration after REQUEST asserted, but switches to low during receive operation and high during transmit operation. Given the relatively low RF duty cycle of 802.15.4, static PRIORITY can be always asserted at the Wi-Fi/PTA input with the EFR32 PTA operating in 2-Wire mode. This frees a GPIO pin on the EFR32 and eliminates a circuit board trace.
Project setup
To enable the COEX feature in a Bluetooth SDK project the libcoex.a library has to be added to the project.
The library can be used only with Bluetooth stack, not compatible with other Silicon Labs stacks. The library increases flash consumption by ~1kB. It has dependencies to em_gpio.c, gpiointerrupt.c files which are provided by the gecko sdk suit.
In Simplicity Studio, the library name and the library path has to be added to the project.
COEX library path is depending on the MCU variant and the complier. See the default path for EFR32BG1B device using GCC complier
C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.0\protocol\bluetooth_2.6\lib\EFR32BG1B\GCC\libcoex.a
The COEX library name and the library path can be specified in the project properties dialog as shown below. In case using GCC the lib prefix has to be removed from the library name.
COEX configuration
Once the libcoex.a library added to the project the COEX feature has to be configured for the system needs. There are options which can be configured in compile time via preprocessor switches (#defines) and there are options which can be configured runtime via API calls.
Compile time options
The following #define-s must be set in hal-config.h. The file can be found in Bluetooth SDK example-s root.
COEX API
The COEX feature have to be initialized by calling gecko_initCoexHAL() API function. For convenience this is done by the void gecko_init(const gecko_configuration_t *config) API by default.
Runtime options
The gecko_cmd_coex_set_options(uint32_t mask, uint32_t options) API can be used for modify COEX options in runtime. The following option can be configured:
See the API documentation and chapter 2.1 in the Bluetooth API reference
Shared REQUEST feature
The Shared REQUEST feature is needed when one master (Wi-Fi) controls multiple EFR32 slaves. In this case all devices share the same REQUEST, PRIORITY, and GRANT signals therefore it is mandatory that GPIO configuration (polarity, open drain/source mode, pull-up/down resistor) is consistent across the devices. This feature can be turned on by the #define HAL_COEX_REQ_SHARED preprocessor switch.
COEX signals in practice
In this setup, all 3 COEX signals and the radio RX/TX signals of the Bluetooth device connected to a logic analyzer.The radio TX/RX signals are active high signals so they are high if there is a radio activity ongoing
The GRANT signal configured to active low and it is always low. So, the Wi-Fi device always let the Bluetooth device to transmit or receive once it requested.
The REQUEST signal configured to active low. So, it is low when Bluetooth device requests the radio usage.
The PRIORITY signal is active low so the priority is high when the signal is low.
COEX signals in connectable advertising
At A1 marker, the REQUEST signal is active with high priority. After 500 usec at A2 marker, the TX starts followed by RX. Note that the actual radio operation starts 500 usec later then the REQUEST signal is active. This is because the HAL_COEX_REQ_WINDOW defined to 500 in hal-config.h.
The RX/TX sequence repeated for all 3 advertising channels. After the last RX, the REQUEST signal deactivated and the PRIORITY set to low.
COEX signals in scannig
During the scan interval, the REQUEST signal is active and the radio get RX interrupts as it is indicated by the RX signal.
COEX signals in connection
In a connection as slave device, EFR32 is receiving first, then transmitting. The actual radio operation is again delayed 500 usec after REQUEST because the configured request window.
How to add radio activity signals
For debug purposes, it is wise to enable radio RX/TX signals however these are not mandatory in real world application.
Adding the radio activity signals can be done in few steps. See this KBA about the process:
https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/07/04/enabling_tx_rx_activ-V4T1
Or you can configure the radio signals directly with the code snippets below:
References
IEEE 802.15.2 (2003) Clause 6
https://www.silabs.com/documents/public/application-notes/an1017-coexistence-with-wifi.pdf
http://www.embedded-computing.com/embedded-computing-design/driving-wi-fi-zigbee-and-thread-coexistence-in-the-2-4-ghz-band-part-2-managed-coexistence
[Deprecated] Enabling COEX feature in Bluetooth SDK projects
Note: This KBA is deprecated. For Wi-Fi and Bluetooth coex please refer to AN1128: Bluetooth® Coexistence with Wi-Fi
Introduction
This KBA summarizes the COEX feature itself then walks through how to enable the feature in a Bluetooth SDK project. Finally, it shows how the COEX signals behaves while the Bluetooth device advertising, scanning or in connection.
What is COEX?
COEX feature is a 3 wire PTA implementation introduced in Silicon Labs Bluetooth SDK v2.6.0 release.
What is PTA?
PTA stands for Packet Traffic Arbitration and PTA is described in IEEE 802.15.2 (2003) Clause 6 and is a recommendation, not a standard. The PTA mechanism coordinates sharing of the medium dynamically, based on the traffic load of the two wireless networks, in this case Bluetooth and Wi-Fi.
3-Wire PTA
There are 1, 2, 3 and 4 wire PTA implementations exist. Silicon Labs Bluetooth SDK supports the 3 wire PTA implementation which is the most common used in Wi-Fi devices.
In 3-Wire PTA 3 signals defined
The Wi-Fi device asserts a GRANT signal when Wi-Fi is not busy transmitting or receiving. When GRANT is asserted, the Bluetooth radio can transmit or receive.
The REQUEST signal is allowing the Bluetooth radio to request the 2.4 GHz ISM band. The Wi-Fi device internally controls the prioritization between Bluetooth and Wi-Fi and, on a conflict, the Wifi device can choose to either GRANT Bluetooth or Wi-Fi.
The PRIORITY signal is allowing the Bluetooth radio to signify a high or low priority message is either being received or transmitted. The Wi-Fi device compares this external priority request against the internal Wi-Fi priority, which may be high/low or high/mid/low and can choose to either GRANT Bluetooth or Wi-Fi.
Note: PRIORITY can be implemented as static or time-shared (enhanced) priority. As of PTA support implementation in Silicon Labs SDKs only supports static priority.
• Static: PRIORITY is either high or low during REQUEST asserted for the transmit or receive operation.
• Time-Shared: PRIORITY is either high or low for a typically 20 µs duration after REQUEST asserted, but switches to low during receive operation and high during transmit operation. Given the relatively low RF duty cycle of 802.15.4, static PRIORITY can be always asserted at the Wi-Fi/PTA input with the EFR32 PTA operating in 2-Wire mode. This frees a GPIO pin on the EFR32 and eliminates a circuit board trace.
Project setup
To enable the COEX feature in a Bluetooth SDK project the libcoex.a library has to be added to the project.
The library can be used only with Bluetooth stack, not compatible with other Silicon Labs stacks. The library increases flash consumption by ~1kB. It has dependencies to em_gpio.c, gpiointerrupt.c files which are provided by the gecko sdk suit.
In Simplicity Studio, the library name and the library path has to be added to the project.
COEX library path is depending on the MCU variant and the complier. See the default path for EFR32BG1B device using GCC complier
C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.0\protocol\bluetooth_2.6\lib\EFR32BG1B\GCC\libcoex.a
The COEX library name and the library path can be specified in the project properties dialog as shown below. In case using GCC the lib prefix has to be removed from the library name.
COEX configuration
Once the libcoex.a library added to the project the COEX feature has to be configured for the system needs. There are options which can be configured in compile time via preprocessor switches (#defines) and there are options which can be configured runtime via API calls.
Compile time options
The following #define-s must be set in hal-config.h. The file can be found in Bluetooth SDK example-s root.
COEX API
The COEX feature have to be initialized by calling gecko_initCoexHAL() API function. For convenience this is done by the void gecko_init(const gecko_configuration_t *config) API by default.
Runtime options
The gecko_cmd_coex_set_options(uint32_t mask, uint32_t options) API can be used for modify COEX options in runtime. The following option can be configured:
See the API documentation and chapter 2.1 in the Bluetooth API reference
Shared REQUEST feature
The Shared REQUEST feature is needed when one master (Wi-Fi) controls multiple EFR32 slaves. In this case all devices share the same REQUEST, PRIORITY, and GRANT signals therefore it is mandatory that GPIO configuration (polarity, open drain/source mode, pull-up/down resistor) is consistent across the devices. This feature can be turned on by the #define HAL_COEX_REQ_SHARED preprocessor switch.
COEX signals in practice
In this setup, all 3 COEX signals and the radio RX/TX signals of the Bluetooth device connected to a logic analyzer.The radio TX/RX signals are active high signals so they are high if there is a radio activity ongoing
The GRANT signal configured to active low and it is always low. So, the Wi-Fi device always let the Bluetooth device to transmit or receive once it requested.
The REQUEST signal configured to active low. So, it is low when Bluetooth device requests the radio usage.
The PRIORITY signal is active low so the priority is high when the signal is low.
COEX signals in connectable advertising
At A1 marker, the REQUEST signal is active with high priority. After 500 usec at A2 marker, the TX starts followed by RX. Note that the actual radio operation starts 500 usec later then the REQUEST signal is active. This is because the HAL_COEX_REQ_WINDOW defined to 500 in hal-config.h.
The RX/TX sequence repeated for all 3 advertising channels. After the last RX, the REQUEST signal deactivated and the PRIORITY set to low.
COEX signals in scannig
During the scan interval, the REQUEST signal is active and the radio get RX interrupts as it is indicated by the RX signal.
COEX signals in connection
In a connection as slave device, EFR32 is receiving first, then transmitting. The actual radio operation is again delayed 500 usec after REQUEST because the configured request window.
How to add radio activity signals
For debug purposes, it is wise to enable radio RX/TX signals however these are not mandatory in real world application.
Adding the radio activity signals can be done in few steps. See this KBA about the process:
https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/07/04/enabling_tx_rx_activ-V4T1
Or you can configure the radio signals directly with the code snippets below:
References
IEEE 802.15.2 (2003) Clause 6
https://www.silabs.com/documents/public/application-notes/an1017-coexistence-with-wifi.pdf
http://www.embedded-computing.com/embedded-computing-design/driving-wi-fi-zigbee-and-thread-coexistence-in-the-2-4-ghz-band-part-2-managed-coexistence
[Deprecated] KBA_BT_0303: Enabling Coexistence Feature in Bluetooth SDK projects
Note: This KBA is deprecated. For Wi-Fi and Bluetooth coex please refer to AN1128: Bluetooth® Coexistence with Wi-Fi
Introduction
This KBA summarizes the Coexistence feature then walks through on how to enable the feature in a Bluetooth SDK project. Finally, it shows how the Coexistence signals behave while the Bluetooth device advertising, scanning or in connection.
What is Coexistence?
Coexistence feature is a 3 wire PTA implementation introduced in Silicon Labs Bluetooth SDK v2.6.0 release.
What is PTA?
PTA stands for Packet Traffic Arbitration and described in IEEE 802.15.2 (2003) Clause 6. PTA is a recommendation, not a standard. The PTA mechanism coordinates sharing of the medium dynamically, based on the traffic load of the two wireless networks, in this case, Bluetooth and Wi-Fi.
3-Wire PTA
There are 1, 2, 3 and 4 wire PTA implementations exist. Silicon Labs Bluetooth SDK 2.6.0 supports the 3 wire PTA implementation which is the most common used in Wi-Fi devices. In later SDK versions the 1 and 2 wire options will be supported also.
In 3-Wire PTA 3 signals defined
The Wi-Fi device asserts a GRANT signal when Wi-Fi is not busy transmitting or receiving. When GRANT is asserted, the Bluetooth radio can transmit or receive.
The REQUEST signal is allowing the Bluetooth radio to request the 2.4 GHz ISM band. The Wi-Fi device internally controls the prioritization between Bluetooth and Wi-Fi and, on a conflict, the Wifi device can choose to either GRANT Bluetooth or Wi-Fi.
The PRIORITY signal is allowing the Bluetooth radio to signify a high or low priority message is either being received or transmitted. The Wi-Fi device compares this external priority request against the internal Wi-Fi priority, which may be high/low or high/mid/low and can choose to either GRANT Bluetooth or Wi-Fi.
Note: PRIORITY can be implemented as static or time-shared (enhanced) priority. As of PTA support implementation in Silicon Labs SDKs only supports static priority.
• Static: PRIORITY is either high or low during REQUEST asserted for the transmit or receive operation.
• Time-Shared: PRIORITY is either high or low for a typical 20 µs duration after REQUEST asserted, but switches to low during receive operation and high during transmit operation. Given the relatively low RF duty cycle of 802.15.4, static PRIORITY can be always asserted at the Wi-Fi/PTA input with the EFR32 PTA operating in 2-Wire mode. This frees a GPIO pin on the EFR32 and eliminates a circuit board trace. Unfortunately, the BLE SDK 2.6.0 release does not let to disable a PTA pin. However, it is possible to redirect PRIORITY to a not connected GPIO or even to an unbonded GPIO pad for given package.
Project setup
To enable the Coexistence feature in a Bluetooth SDK project the libcoex.a library has to be added to the project.
The library can be used only with Bluetooth stack, not compatible with other Silicon Labs stacks. The library increases flash consumption by ~1kB. It has dependencies to em_gpio.c, gpiointerrupt.c files which are provided by the gecko sdk suit.
In Simplicity Studio, the library name and the library path has to be added to the project.
Coexistence library path is depending on the MCU variant and the compiler. See the default path for EFR32BG1B device using GCC compiler
C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.0\protocol\bluetooth_2.6\lib\EFR32BG1B\GCC\libcoex.a
The Coexistence library name and the library path can be specified in the project properties dialog as shown below. In case using GCC the lib prefix has to be removed from the library name.
Coexistence configuration
Once the libcoex.a library added to the project the Coexistence feature has to be configured for the system needs. There are options which can be configured at compile time via preprocessor switches (#defines) and there are options which can be configured runtime via API calls.
Compile time options
The following #define-s must be set in hal-config.h. The file can be found in Bluetooth SDK example-s root.
Coexistence API
The Coexistence feature has to be initialized by calling gecko_initCoexHAL() API function. For convenience, this is done by the void gecko_init(const gecko_configuration_t *config) API by default.
Runtime options
The gecko_cmd_coex_set_options(uint32_t mask, uint32_t options) API can be used for modify COEX options in runtime. The following option can be configured:
See the API documentation and chapter 2.1 in the Bluetooth API reference
Shared REQUEST feature
The Shared REQUEST feature is needed when one master (Wi-Fi) controls multiple EFR32 slaves. In this case, all devices share the same REQUEST, PRIORITY, and GRANT signals, therefore, it is mandatory that GPIO configuration (polarity, open drain/source mode, pull-up/down resistor) is consistent across the devices. This feature can be turned on by the #define HAL_COEX_REQ_SHARED preprocessor switch.
Coexistence signals in practice
In this setup, all 3 Coexistence signals and the radio RX/TX signals of the Bluetooth device connected to a logic analyzer.The radio TX/RX signals are active high signals so they are high if there is a radio activity ongoing
The GRANT signal configured to active low and it is always low. So, the Wi-Fi device always let the Bluetooth device to transmit or receive once it requested.
The REQUEST signal configured to active low. So, it is low when Bluetooth device requests the radio usage.
The PRIORITY signal is active low so the priority is high when the signal is low.
Coexistence signals in connectable advertising
At A1 marker, the REQUEST signal is active with high priority. After 500 usec at A2 marker, the TX starts followed by RX. Note that the actual radio operation starts 500 usec later then the REQUEST signal is active. This is because the HAL_COEX_REQ_WINDOW defined to 500 in hal-config.h.
The RX/TX sequence repeated for all 3 advertising channels. After the last RX, the REQUEST signal deactivated and the PRIORITY set to low.
Coexistence signals in scannig
During the scan interval, the REQUEST signal is active and the radio gets RX interrupts as it is indicated by the RX signal.
Coexistence signals in connection
In a connection as slave device, EFR32 is receiving first, then transmitting. The actual radio operation is again delayed 500 usec after REQUEST because of the configured request window.
How to add radio activity signals
For debug purposes, it is wise to enable radio RX/TX signals however these are not mandatory in real-world application.
Adding the radio activity signals can be done in few steps. See this KBA about the process:
https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2017/07/04/enabling_tx_rx_activ-V4T1
Or you can configure the radio signals directly with the code snippets below:
GPIO pins
On the Bluetooth device 3 GPIO pin needs to be assigned for the REQUEST, PRIORITY and GRANT signals. For the optional RX/TX signals 2 more GPIO pin is needed.
PRS channel allocation
The REQUEST, PRIORITY and GRANT signals does not require PRS channels. But for the optional RX/TX signals 2 PRS channel is needed.
In Bluetooth SDK 2.6.0 PRS channel 7 is allocated to the Bluetooth stack so it can not be used for the RX/TX signals. PRS channel allocation may change in the future so please check the UG136 chapter 7 for the unused PRS channels.
NCP mode
In case of NCP mode the ncp_gecko_bgapi_class_coex_init() need to be called additionaly after gecko_init().
Custom boards
On custom boards, the init_board.c is empty. For using the coexistence feature the GPIO clock has to be enabled as shown below.
References
IEEE 802.15.2 (2003) Clause 6
https://www.silabs.com/documents/public/application-notes/an1017-coexistence-with-wifi.pdf
http://www.embedded-computing.com/embedded-computing-design/driving-wi-fi-zigbee-and-thread-coexistence-in-the-2-4-ghz-band-part-2-managed-coexistence
https://www.silabs.com/documents/login/user-guides/ug136-ble-c-soc-dev-guide.pdf
BGM12x模块在layout的时候PIN53与PIN54一定不要直接相连
产品持续时间
问题:
我想知道Silabs的无线产品会卖多长时间?
答案:
关于产品的持续时间在我们的网站上有一个专门的页面:
https://www.silabs.com/products/wireless/longevity-commitment