Last week, the Bluetooth SIG announced to its members an update about security vulnerability related to the encryption key negotiation protocols. According to the SIG, researchers of SUTD, CISPA and Oxford University identified a vulnerability with the encryption key negotiation protocol of Bluetooth BR/EDR. The attack makes it possible for a third party to make the victims to agree on an encryption key with only 1 byte (8 bits) of entropy, which then enables the attacker to brute force the negotiated encryption keys, decrypt the eavesdropped ciphertext, and inject valid encrypted messages in real-time. The attack is standard-compliant because all Bluetooth BR/EDR versions require to support encryption keys with entropy between 1 and 16 bytes and do not secure the key negotiation protocol. (More information about the details of the attack for example here www.knobattack.com)

Our Wireless Gecko Bluetooth products (Blue Gecko) and BLE112, BLE113, BLE113, BLE121LR and BLED112 module products are not affected by this issue because they are based on Bluetooth LE core specification which does not have this vulnerability.

Our Bluetooth BR/EDR (BT Classic) products, which include the WT12, WT11u, WT41u, WT32, WT32i, BT111 and BT121 modules, are vulnerable to this issue. We plan to release a patches which protect against this vulnerability during October 2019

Recently, Tom R. Halfhill, a senior analyst at The Linley Group and a senior editor of Microprocessor Report, contributed a review of our new Wireless Gecko Series 2 SoCs in the June issue of Microprocessor Report. He analyzes key EFR32 Series 2 upgrades and how the next-generation portfolio compares with the EFR32 Series 1 family in areas such as wireless performance, security features, on-chip CPU and package size.

In this report, Halfhill highlights Series 2 security features such as secure boot with Root of Trust and Secure Loader (RTSL) in addition to hardware crypto accelerations with side-channel countermeasures that considerably strengthen resistance to adversary attacks. The report also compares key specifications of EFR32MG21 and EFR32BG21 SoCs, the first products in the Series 2 portfolio. EFR32MG21 supports multiprotocol, Zigbee®, Thread and Bluetooth® mesh networking, and EFR32BG21 is dedicated to Bluetooth Low Energy and Bluetooth mesh connectivity.

Our Wireless Gecko Series 2 portfolio leads a growing crowd of wireless MCUs and SoCs for connected devices. Halfhill compares EFR32MG21 features and performance with several competing products from other large wireless MCU/SoC vendors:

•            NXP’s Kinetis K32W0x

•            ST Microelectronics’ STM32WB

•            Texas Instrument’s SimpleLink CC1352R

Halfhill acknowledges that our new Series 2 portfolio includes the lowest power wireless SoCs on the market while offering the tiniest footprint, boasting a 4 mm x 4 mm surface-mount QFN package with only 32 pins. The SoCs also offer the highest ambient temperature range, making them suitable for applications with extreme heat exposure such as connected LED lighting and various Industrial IoT applications. The latest Series 2 SoCs are ideal for a wide range of line-powered IoT products including gateways, hubs, lights, voice assistants and smart electric meters.

Series 1 customers can easily upgrade to the Series 2 platform. With IoT security threats increasing, Wireless Gecko Series 2 leads the pack in providing improved security features but comes at virtually no additional cost when upgrading to Series 2. The enhanced radios offer a +20 dBm option for longer range, allowing customers to choose the right power level and wireless range for each design. The Series 2 radio also offers better selectivity, which is helpful as more and more wireless devices use the crowded 2.4 GHz band.

Read the full Microprocessor Report: https://www.silabs.com/documents/public/white-papers/the-linley-group-microprocessor-report-silicon-labs-upgrades-wireless-mcus.pdf

Bluetooth Special Interest Group (SIG) has sent out Deprecated and Withdrawal notices for Bluetooth core specification version v4.1 and all earlier versions down to v2.1. In practice it means that the products, using Silicon Labs modules, which use v4.1 or earlier version, need to be Qualified and Declared at the latest by the withdrawal date of the specific version. Yet, despite the deprecated status of the Core specification versions v2.1 to v4.1, Silicon Lab’s modules are already fully Bluetooth SIG tested, listed and qualified as ‘End Products’ or ‘Controller’ subsystems, which means that the modules are valid as such for Bluetooth products and Silicon Labs customers do not need to perform additional testing when using the modules to Bluetooth SIG qualify their end product designs. The withdrawal date also does not impact Silicon Labs capability to manufacture and supply the modules for customers also after the withdrawal.

Table 1. shows the withdrawal dates for the core specifications and corresponding Silicon Labs module products.

Bluetooth Core specfication version	Withdrawal schedule	Impacted Silicon Labs parts
Bluetooth v2.1 and v3.0	Withdrawal date July 1st 2020	WT11, WT11u, WT12, WT32, WT32i, WT41, WT41u and all variations of their Orderable Part Numbers
	Before withdrawal date, customers can still list and qualify using Silicon Labs modules with no additional testing.
	After July 1st 2020, the specification will be completely withdrawn and no new Bluetooth end product listings will be possible.
Bluetooth 4.0	Withdrawal date February 1st 2022	BLE112, BLE113, BLE121LR, BLED112, BT111 and all variations of their Orderable Part Numbers
	Before withdrawal date, customers can still list and qualify using Silicon Labs modules with no additional testing.
	After February 1st 2022, the specification will be completely withdrawn and no new Bluetooth end product listings will be possible.
Bluetooth 4.1	Withdrawal date February 1st 2023	BT121 and and all variations of its Orderable Part Numbers
	Before withdrawal date, customers can still list and certify using the Silicon Labs modules with no additional testing.
	After february 1st 2023, the specification will be completely withdrawn and no new Bluetooth end product listings will be possible
Bluetooth v4.2 to v5.1	are still Active, no deprecation or withdrawal date has been released. Silicon Labs BGMxx products meets these standards and are recommended for new designs.

This blog is part of the Kernel 201: Designing a Dynamic Multiprotocol Application with Micrium OS. The table of contents for this blog series can be found here.

Note: It is recommended to download the Kernel 201 Instructor Application & Electron App and have the code in front of you as you go through this blog post. The code can be downloaded on the Kernel 201: Project Resources page. 

Kernel 201 Instructor Application

The instructor application is designed to be run by the instructor of a Kernel 201 class, or in the case of someone following along this blog post, by a user. The application communicates via Proprietary Wireless with all of the Thunderboard Sense 2s running the Kernel 201 Application in a one-to-many fashion. When the instructor application sends out a command, it acts as a broadcast to all devices listening. Since the Thunderboard Sense 2s are running Dynamic Multiprotocol, it is possible the radio may be operating in Bluetooth mode when the instructor application broadcasts a message. To mitigate this, the instructor application will actually transmit out the same message multiple times in an attempt to ensure all boards receive the message. The instructor application also can receive data from all Kernel 201 Applications. This is why the Kernel 201 Application only transmits data once every 10 seconds, rather than whenever it receives commands.

Note: It is worth noting that even with the multiple broadcasts, it is still possible for a Kernel 201 Application to miss a Proprietary Wireless message. In a real-world application where missing messages is not acceptable, a basic transmit-ack scheme would help or the use of a more complex wireless stack such as SiLab’s Connect Networking Stack. For this application, in order to keep the wireless portion simpler, it is acceptable for messages to be missed.

The entire instructor application acts as a translator between the Electron App and the Proprietary Wireless stack. When a user sends a command in the Electron App, a LAB_MSG_s packet is built up in the Electron App and sent to the instructor application via serial. The instructor application then takes that data and transmits it out using the RAIL API. When data is received via Proprietary Wireless, the instructor application receives the RAIL packet and then sends the data it received via serial to the Electron App. This allows the instructor application to operate without knowing too many details about the command packets.

Proprietary Wireless Task

 

 

The Proprietary Wireless task design in the instructor application is slightly different than the Proprietary Wireless task in the Kernel 201 Application. In the instructor application the Proprietary Wireless task only handles the receive events. Transmit events are triggered by the VCOM task in the instructor application. 

1. RAIL interrupt fires and the labPropRadioEventHandler() function is called. This function determines that a packet has been received, tells RAIL to hold the packet and sends the packet pointer to the Proprietary Wireless task via a Task Message Queue to be processed.
2. The labPropRxTask() runs due to the message being received and calls labPropRadioRxData() to process the RAIL packet.
3. The function labPropRadioRxData() toggles the LED to signal a packet has been received, then it uses the RAIL Peek function to pull out the data from the packet. The use of the peek function replaces the need for a memcopy or similar to pull data from the packet. After the data has been read from the packet, the RAIL packet is released.
4. The function labVCOMTx() is called to send the data that was pulled out of the RAIL packet to the Electron App. The function then puts the data into the transmit ring buffer and triggers the VCOM transmit where it sends one byte at a time. After every byte is transmitted, the interrupt fires and if there’s more data in the ring buffer to send, the next byte is sent. If there is no more data to send, the transmit operation stops.
5. After the data was loaded into the ring buffer, the labVCOMTx() function returns while the transmit is occurring and the Proprietary Wireless task goes back to pending on the Task Message Queue.

 

VCOM Task

 

The VCOM task takes in data from the Electron App over serial and transmits it to the Kernel 201 Application via Proprietary Wireless. The data received from the Electron App comes in the format of two sync bytes, two bytes for the Task ID, a LAB_MSG_s packet and then two end sync bytes. A state machine is used in the UART interrupt to handle the received data. Once a full packet has been received, a semaphore is posted to signal to the VCOM task to signal that it is time to transmit the data received. The VCOM task takes the data received and calls labPropTx() where the data is loaded into the RAIL transmit queue. After the data is successfully transmitted, the task goes back to pending waiting for another message to send.

 

Kernel 201 Instructor Electron App

The Electron App is a cross-platform desktop application that communicates via serial to the Kernel 201 Instructor Application. The app allows you to interact with all Thunderboard Sense 2s running the Kernel 201 application.

To get started, you need to have npm installed on your machine and have the Kernel 201 Instructor Electron App source code from the Kernel 201: Project Resources page.

From the electron app directory run the following commands:

npm install
npm start

The install command will download all necessary packages for the application. The command npm start will run the application. There is also the option to generate executable packages for both Windows and Mac via the following commands:

npm run package-win
OR
npm run package-mac

Windows packages can only be generated on Windows and Mac packages can only be generated on Mac. The advantage of generating packages is you do not need to have npm or node installed on a machine when a package is used.

Using the Kernel 201 Instructor Electron App

 

The first screen that should appear is the Scan Serial Ports window. Make sure the instructor application board is plugged into your computer and click scan.

 

After scanning you should see at least one device. On Mac’s the SiLabs boards show up as /dev/tty.usbmodem and on Windows they will show up as COM. There is a filter in place to not show every serial device connected in an effort to make this simpler. If you find that you can not find the device, look at the file serial.js located in the app/js directory and remove the Silicon Labs filter.

Note: If you have the Blue Gecko and the Thunderboard Sense 2 connected to the same computer, both will show up. Be sure to select the right device!

 

Once connected to the serial device, you will be presented with the window above. To view all Kernel 201 Application devices, click View Devices. To send commands to all Kernel 201 Application devices, click Control Devices.

 

Under View Devices, any Kernel 201 Application devices should show up. Remember, those boards only transmit their status once every 10 seconds so it may take a little while for them to appear. If you make changes to the board via the WebBluetooth App, those changes should eventually be reflected here as well.

 

To send commands to the boards, go to the Control Devices window. Here you have the ability to configure the LEDs and then either send it once or send it repeatedly. If you have the WebBluetooth App open and connected to the Kernel 201 Application, as you push changes out via the Electron App you should see the changes reflected in the WebBluetooth App immediately.

 

Final Thoughts

The instructor application and Electron App provide a simple way to interact with the Kernel 201 Application via Proprietary Wireless. While the response time is very slow compared to Bluetooth and the WebBluetooth App, the Proprietary Wireless provides a way to communicate with more than one board at a time which can be extremely useful. 

This blog is part of the Kernel 201: Designing a Dynamic Multiprotocol Application with Micrium OS. The table of contents for this blog series can be found here.

Note: It is recommended to download the Kernel 201 application and have the code in front of you as you go through this blog post. The code can be downloaded on the Kernel 201: Project Resources page. 

 

Introduction

Up until this point, all of the tasks covered in this blog series have been for wireless communication and the system watchdog. This post will cover the two user interface tasks: LEDs and buttons. These tasks are simple interfaces that take advantage of some of the hardware on the Thunderboard Sense 2. In a real-world application, these tasks would be just part of a number of application tasks that may interact with other sensors, user input or even other processors.

 

LED Task

When the LED Task is first created, there are two sets of LEDs that are initialized. The Thunderboard Sense 2 provides a simple red and green LED controlled by GPIO pins, but it also has RGB LEDs on both sides of the board. The RGB LEDs require the use of a hardware timer to control the color, so they can show any color you wish. To keep the lab simpler, the LEDs only offer red, green and yellow since those colors are available on both the GPIO LED and the RGB LEDs.

 

The LED Task is structured like all other tasks in the system (except for the watchdog task) in that it pends on a task message queue to perform an action.

The Task Message Queue processes two events and one RTOS error. These events are:

• RTOS_ERR_TIMEOUT
• LAB_Q_ID_MSG
• LAB_Q_ID_LED_TMR

 

RTOS_ERR_TIMEOUT

As part of the software watchdog, the LED Task must feed the software watchdog at a specified rate. There is a define in lab.h that all tasks use called LAB_WDOG_TASK_TIMEOUT_MS. This define specifies how often every task should check-in with the software watchdog. If the Task Message Queue does not receive a message before the timeout value is hit, the pend call returns with RTOS_ERR_TIMEOUT. Since it’s a timeout the LED Task knows that no message was received, it only feeds the software watchdog and then starts pending on the Task Message Queue again.

 

LAB_Q_ID_MSG

When another task in the system wishes to send a command to the LED Task, a lab message must be sent to the LED Task via the Task Message Queue. In most cases, this is either the Bluetooth or Proprietary Wireless task relaying LED control messages.

After a valid command message is successfully processed, an update is sent to both the Bluetooth and Proprietary Wireless tasks to alert them that the LEDs have been changed. The Bluetooth Web App will immediately reflect these changes due to the use of Bluetooth notifications. The Kernel 201 Instructor Application will be delayed on updating the LED status due to the Proprietary Wireless task transmitting on a fixed interval.

 

LAB_Q_ID_LED_TMR

When the LED Task is sent a command to blink the LED, a software timer is enabled. When the Micrium OS Software Timer expires, a callback function is executed similar to how an interrupt may trigger an interrupt routine. The software timer callback is treated similar to an interrupt function in that the code must be short because the callback function is executing out of the software timer’s callstack. Rather than controlling the LEDs from the callback, a message is sent to the LED Task via the Task Message Queue sending the message LAB_Q_ID_LED_TMR to signal that a software timer timeout occurred. The LED Task then knows based on the signal from the timer callback that it should blink the LEDs.

 

Button Task

After the Button Task is created, it initializes the two push buttons on the Thunderboard Sense 2. The Button Task is structured like all other tasks in the system (except for the watchdog task) in that it pends on a task message queue to perform an action. The button state is obtained by polling the GPIO state for each button’s GPIO. In low-power systems, interrupt-based buttons would make more sense but in the Kernel 201 Application, it is assumed the board is always powered via USB so low-power is not a concern.

 

The Button Task’s Task Message Queue processes only one event and one error. If there was a desire to add the ability to change the polling rate of the buttons, the Task Message Queue could be adjusted to accept a lab message to change the polling rate.

• RTOS_ERR_TIMEOUT
• LAB_Q_ID_BTN_TMR

 

RTOS_ERR_TIMEOUT

As part of the software watchdog, the Button Task must feed the software watchdog at a specified rate. There is a define in lab.h that all tasks use called LAB_WDOG_TASK_TIMEOUT_MS. This define specifies how often every task should check-in with the software watchdog. If the Task Message Queue does not receive a message before the timeout value is hit, the pend call returns with RTOS_ERR_TIMEOUT. Since it’s a timeout the Button Task knows that no message was received, it only feeds the software watchdog and then starts pending on the Task Message Queue again.

 

LAB_Q_ID_BTN_TMR

The Button Task operates by polling the GPIO state for the buttons. The task uses a Micrium OS Software Timer similar to the LED Task. When the timer expires, a callback is executed from the software timer’s call stack. The callback function quickly checks the state of the buttons. The callback function then sends the state of the buttons to the Button Task via the Task Message Queue specifying the button state in the void* parameter.

The Button Task passes the data it receives from the time callback to the function labBtnCheckUpdate(). This function determines if either button state has changed. If one or both buttons have had a state change, the information is sent via the Task Message Queue to both the Bluetooth and Proprietary Wireless tasks. In the Bluetooth Web App the change will be seen immediately due to the use of the Bluetooth notifications. The Kernel 201 Instructor Application will not see the change immediately due to the Proprietary Wireless Task transmitting on a fixed interval. This means if you wish to see a “pushed” state for either button in the Kernel 201 Instructor Application you must hold the button until after the Proprietary Wireless task has transmitted.

 

Final Thoughts

The LED and Button Tasks are two very simple UI tasks implemented in the Kernel 201 Application. In a real-world application, other more complex tasks that communicate with external sensors/hardware would most likely exist alongside simple tasks such as these. These two tasks provide a solid framework to build a more complex application on top of.

As always, if there are any comments, questions or concerns, feel free to leave them below.

This blog is part of the Kernel 201: Designing a Dynamic Multiprotocol Application with Micrium OS. The table of contents for this blog series can be found here.

Note: It is recommended to download the Kernel 201 application and have the code in front of you as you go through this blog post. The code can be downloaded on the Kernel 201: Project Resources page. 

Note: It is important to understand RAIL API calls are not thread-safe. The design of the Proprietary Wireless task is to ensure multiple transmit or receive RAIL calls are not made simultaneously.

 

Introduction

The goal of the Proprietary Wireless task in the Kernel 201 Application is to communicate with another Silicon Labs board running the Kernel 201 Instructor Application. In a lab setting there may be many Thunderboard Sense 2s running the Kernel 201 Application and they would all communicate to one Kernel 201 Instructor Application board.

Just like the Bluetooth task, the Proprietary Wireless task will handle only the wireless communication and pass messages to other tasks in the system as needed. The Proprietary Wireless task will handle both transmitting and receiving in one task rather than having them split into two separate tasks.

 

Kernel 201 Proprietary Wireless Initialization

When the Proprietary Wireless task is started, the first action it needs to perform is to configure the radio. This is a separate configuration than the Bluetooth configuration which has already occurred (Bluetooth task has a higher priority than the Proprietary Wireless task). The configuration of the radio is done in two different locations: the Proprietary Configurator and the labPropRadioInit() function.

 

The kernel201.isc file holds the Proprietary Wireless Configuration in addition to the Bluetooth Configuration. For the Kernel 201 Application, the default configuration in the Proprietary Configurator is all that is needed. In the screenshot above, the second profile was removed, but it is not necessary to do so.

labPropRailHandle = RAIL_Init(&labPropRailCfg, NULL);       // 1

RAIL_SetTxFifo(labPropRailHandle,                           // 2
               labPropTxFifo,
               0,
               LAB_PROP_TX_FIFO_SIZE);


RAIL_TxPowerConfig_t railTxPowerConfig = {
#if HAL_PA_2P4_LOWPOWER
    .mode     = RAIL_TX_POWER_MODE_2P4_LP,
#else
    .mode     = RAIL_TX_POWER_MODE_2P4_HP,
#endif
    .voltage  = HAL_PA_VOLTAGE,
    .rampTime = HAL_PA_RAMP,
};

if (channelConfigs[0]->configs[0].baseFrequency < 1000000000UL) {
    railTxPowerConfig.mode = RAIL_TX_POWER_MODE_SUBGIG;
}

RAIL_EnablePaCal(true);                                     // 3
status = RAIL_ConfigTxPower( labPropRailHandle,
                            &railTxPowerConfig);
APP_RTOS_ASSERT_CRITICAL((status == RAIL_STATUS_NO_ERROR), 1);

RAIL_SetTxPower(labPropRailHandle,
                HAL_PA_POWER);

RAIL_ConfigChannels(labPropRailHandle,                      // 4
                    channelConfigs[0],
                    NULL);

RAIL_ConfigCal(labPropRailHandle,
               RAIL_CAL_ALL);

RAIL_ConfigEvents(labPropRailHandle,                        // 5
                  RAIL_EVENTS_ALL,
                  RAIL_EVENT_SCHEDULER_STATUS
                  | RAIL_EVENTS_TX_COMPLETION
                  | RAIL_EVENTS_RX_COMPLETION
                  | RAIL_EVENT_CAL_NEEDED);

RAIL_SetFixedLength(labPropRailHandle,                      // 6
                    LAB_PROP_PACKET_SIZE);

schedulerInfo.priority = 200;                               // 7
RAIL_StartRx( labPropRailHandle,
              LAB_PROP_RX_CHANNEL,
             &schedulerInfo);

 

The configuration performed in labPropRadioInit() is shown above. There is a great multi-part tutorial on RAIL that walks through each of these calls and can be found here: RAIL Tutorial.

1. The labPropRadioInit() function first initializes the RAIL handle. The same RAIL handle will be used for transmit and receive in the Proprietary Wireless task.
2. The RAIL_SetTxFifo() function passes in the transmit FIFO buffer required for queueing up data to send. It is not necessary to specify a receive buffer because one is already allocated internally in the RAIL stack.
3. Based on the railTxPowerConfig above, the PA calibration is enabled (must be done before RAIL_ConfigTxPower()) and the transmit power is configured. After the transmit power has been configured, a call must be made to RAIL_SetTxPower() to reapply the transmit power configuration.
4. After the radio transmit power has been configured, the channels we will use must be configured. The channelConfigs[0] array comes from the Proprietary Configurator. For the Kernel 201 Application we will use two channels: 0 and 9. Data will be received on channel 0 and transmitted on channel 9.
5. The call to RAIL_ConfigEvents() configures what callbacks events are enabled. The RAIL_EVENTS_TX_COMPLETION and RAIL_EVENTS_RX_COMPLETION will signal when a transmit has completed and we need to start listening for data again or when we’ve received a packet and need to process it.
6. The call to RAIL_SetFixedLength() changes the size of the packet we expect to receive from the default of 32 bytes to LAB_PROP_PACKET_SIZE (48 bytes in this case). This is necessary because the default size of a LAB_MSG_s message is 32 bytes and we must include extra data to indicate what task it must be sent to.
7. After all of the configurations have been made on the RAIL handle, a call is made to RAIL_StartRx() on the LAB_PROP_RX_CHANNEL to begin listening for messages. Because of the way the radio is configured for Bluetooth and Proprietary Wireless, the radio is now shared between the two protocols. Bluetooth has a higher priority than Proprietary so it has the ability to take control of the radio away from the Proprietary stack if it needs to transmit or receive. This is something that must be taken into account when designing the Kernel 201 Instructor Application.

 

Kernel 201 Proprietary Wireless Task Design

The Proprietary Wireless task loop is structured just like all other tasks in the Kernel 201 Application (except for the watchdog task). When the task is created, a call is made to labPropRadioInit() which goes through the initialization as shown above. After the radio is configured for Proprietary Wireless it waits on the Task Message Queue.

 

while (DEF_TRUE) {
    p_msg = OSTaskQPend( LAB_WDOG_TASK_TIMEOUT_MS,
                         OS_OPT_PEND_BLOCKING,
                        &lab_q_id,
                         0,
                        &err);

    do {
        if(err.Code == RTOS_ERR_TIMEOUT) {
            break;
        } else if(err.Code != RTOS_ERR_NONE) {
            APP_RTOS_ASSERT_CRITICAL(err.Code == RTOS_ERR_NONE, ;);
        }

        switch(lab_q_id) {
            case LAB_Q_ID_PROP_RX:
                labPropRadioRxData((RAIL_RxPacketHandle_t)p_msg);
                break;

            case LAB_Q_ID_PROP_TMR:
                labPropRadioTxData();
                break;

            case LAB_Q_ID_MSG:
                labPropUpdateStatus(p_msg);
                labUtilMsgFree(p_msg);
                break;

            default:
                break;
        }

    } while(0);

    labWDOGFeed(LAB_TASK_PROP);
}

 

The Task Message Queue processes three events and one RTOS error. These events are:

• RTOS_ERR_TIMEOUT
• LAB_Q_ID_MSG
• LAB_Q_ID_PROP_TMR
• LAB_Q_ID_PROP_RX

 

RTOS_ERR_TIMEOUT

As part of the software watchdog, the Proprietary Wireless task must feed the software watchdog at a specified rate. There is a define in lab.h that all tasks use called LAB_WDOG_TASK_TIMEOUT_MS. This define specifies how often every task should check-in with the software watchdog. If the Task Message Queue does not receive a message before the timeout value is hit, the pend call returns with RTOS_ERR_TIMEOUT. Since it’s a timeout the Proprietary Wireless task knows that no message was received, it only feeds the software watchdog and then starts pending on the Task Message Queue again.

 

LAB_Q_ID_MSG

When another task in the system wishes to send data via Proprietary Wireless, a lab message must be sent to the Proprietary Wireless task via the Task Message Queue. In most cases, this is used when a task has completed a request and is updating the remote Kernel 201 Instructor Application. Unlike the Bluetooth task, data is not transmitted immediately. Instead it is stored in a status structure and transmitted on a fixed interval.

 

LAB_Q_ID_PROP_TMR

The Kernel 201 Application is designed to be used in a lab class situation, with many Thunderboard Sense 2 boards running and only one Kernel 201 Instructor Application running. In order to not overwhelm the Kernel 201 Instructor Application, the Kernel 201 Application transmits status data on a fixed time interval. This is necessary because if the Kernel 201 Application responded to changes immediately, this would mean every time the Instructor Application pushed out an LED change every Kernel 201 Application would respond at the exact same time and messages would be dropped.

 

When the status data is transmitted, it must fit into the same packet size as the data we receive, specified by LAB_PROP_PACKET_SIZE. Since there may be multiple devices transmitting on the same channel to the Kernel 201 Instructor Application, each device must be differentiated.

typedef struct {
    CPU_INT16U seq_num;
    CPU_INT08U device_name[LAB_DEVICE_NAME_MAX_LEN];
} LAB_PROP_DATA_TX_s;

 

The struct above is used to inform the Kernel 201 Instructor Application who sent the data it is receiving. The seq_num value is not used in the current revision of the application on the transmit side, but it is used on the receive side which will be covered in another section of this post.

typedef struct {
    LAB_MSG_LED_s led;
    LAB_MSG_BTN_s btn;
    LAB_MSG_SI7021_s si7021;
    CPU_INT32U err_cnt;
    CPU_INT32U updated;
} LAB_PROP_STATUS_s;

 

The LAB_PROP_STATUS_s struct is the second part of the data sent to the Kernel 201 Instructor Application. When lab messages are received from other tasks in the system, the data is stored in this structure and transmitted on a fixed interval. The reason for the separate struct is this data will be peeled away from the LAB_PROP_DATA_TX_s and sent to a desktop application on the Kernel 201 Instructor Application side.

The diagram below shows how the Proprietary Wireless task uses a software timer to trigger transmits. All data that is received from other tasks in the system is stored in a status structure and when the timer expires, the status structure is transmitted.

 

1. When the labPropTmr hits the timeout value, the callback labPropTmrCallback() is executed from the OS Timer stack. The labPropTmrCallback() function sends a signal to the Proprietary Wireless task via the Task Message Queue by sending LAB_Q_ID_PROP_TMR in the msg_size field.
2. The Proprietary Wireless Task Message Queue releases upon receiving a message from the timer callback. It determines based on the lab_q_id that it is a timer callback. The Proprietary Wireless Task then grabs the current status data, writes it to the RAIL Tx FIFO and starts the transmission via RAIL_StartTx(). The RAIL_StartTx() call is a non-blocking call, so it will return as soon as it successfully initiates the transfer.
   Note: Typically in an RTOS application a guard should be placed around the RAIL_WriteTxFifo() and RAIL_StartTx() to prevent a second call to either before receiving the RAIL events callback to signal success or error on the transmit. Since the application only transmits on a fixed interval it is not as important to protect multiple writes since they are spaced out by multiple seconds.
3. After the transmit is complete, the RAIL events callback will execute. The events flag will be set to RAIL_EVENTS_TX_COMPLETION which signals it is now ok to switch the radio to another mode. Since the radio is used by both Bluetooth and Proprietary Wireless, a call must be made to RAIL_YieldRadio() to signal that the radio is free. After yielding the radio we must call RAIL_StartRx() to start background listening for Proprietary Wireless packets in-between Bluetooth transmissions.
   Note: If you were to transmit and receive on the same channel, the RAIL_StartRx() call would not be necessary. Since the Kernel 201 Application transmits and receives on different channels, it is necessary to call RAIL_StartRx() and specify what channel to listen on.

 

LAB_Q_ID_PROP_RX

 

When the radio is not communicating via Bluetooth or transmitting a Proprietary Wireless message, it is in a listening state for Proprietary Wireless messages from the Kernel 201 Instructor Application. All boards running the Kernel 201 Application listen for messages on the same channel. This allows the Kernel 201 Instructor Application to broadcast messages to all boards running the Kernel 201 Application.

typedef struct {
    CPU_INT16U seq_num;
    CPU_INT16U task_dest;
    void* p_data;
} LAB_PROP_DATA_RX_s;

 

When data is received, it is expected to be a specific size and in a specific format. The size was configured during the RAIL configuration; all packets are LAB_PROP_PACKET_SIZE. The format of the data is a combination of the structure above and a LAB_MSG_s. By reusing the LAB_MSG_s structure this allows the Proprietary Wireless task to just “peel off” the LAB_PROP_RX_s data and send the LAB_MSG_s data to the appropriate task. The images below show how an LED message fits into the RAIL Rx packet.

 

After a packet is received, the Proprietary Wireless task will copy the LAB_MSG_s data into a lab message and send it to the task specified in the task_dest field. The following flowchart shows how packets are received in the Kernel 201 Application.

 

1. When a packet is received on the radio, the RAIL stack triggers a callback to the specified callback function labPropRailEventHandler(). Once it is determined that the event triggering the callback is a packet has been received, the RAIL Event Handler must determine if we’ve seen this message before. The Kernel 201 Instructor Application sends out multiple copies of the same message due to the possibility that some Thunderboard Sense 2s may be communicating via Bluetooth or transmitting Proprietary Wireless messages. By using a sequence number, this allows the RAIL Event Handler to quickly determine if the message has already been seen, and if so release the message. If it is a new sequence number that we have not yet seen, the pointer for the packet is passed to the Proprietary Wireless task to be processed.
2. The Task Message Queue releases when the RAIL packet pointer is received from the RAIL Event Handler. The packet pointer is passed into labPropRadioRxData() where a lab message is allocated, a lab message is extracted from the RAIL packet and the message is copied into the allocated buffer. The destination of the lab message is also pulled from the RAIL packet, the data is sent to the appropriate task and then the RAIL packet is released.

 

Final Thoughts

The Proprietary Wireless task is a much more complex task than the Bluetooth task when it comes to wireless communication. This is partially due to the flexibility of the Proprietary Wireless stack but also because the RAIL API calls are the lowest level calls available to interface with the radio. When the Bluetooth stack wishes to use the radio, it also must use RAIL API calls under the hood.This application only uses a small subset of the Proprietary Wireless Configurator and RAIL API. For more detailed information on RAIL, check out the resources on this page. 

Wi-Fi may not be the first wireless technology one thinks of when considering low power IoT applications, but it should be. In this Q&A, Silicon Labs’ senior product manager for Wi-Fi products Siddharth Sundar discusses Wi-Fi's advantages and challenges that developers should keep in mind when choosing the right approach to wireless IoT.

What are the advantages to using Wi-Fi in low power IoT applications?

Being a widely deployed protocol with approximately 13 billion deployed devices means that Wi-Fi connectivity is available in most home and commercial/office environments. This avoids the need for a gateway and lets devices be cloud connected without needing new infrastructure. Wi-Fi is also highly interoperable, so you can have confidence that your devices will connect to most Wi-Fi networks out there. The higher data rates and range offered by Wi-Fi also enable a wider range of applications.

How does Wi-Fi compare to other IoT wireless communication protocols?

Wi-Fi has significantly higher data throughput than most other IoT wireless communication protocols – often 10-100x higher, allowing it to tackle higher throughput applications like audio and video. The broad deployment and range of Wi-Fi is also a significant benefit compared to many other protocols.

These benefits do come at a cost. Wi-Fi products typically have higher power consumption and higher implementation costs than IoT specific protocols like BLE and Zigbee, since the range and throughput offered by Wi-Fi demands higher design complexity. However, most of this design complexity can be managed through using pre-certified modules, and the cost and power consumption of Wi-Fi devices is decreasing to a point where it is competitive for many IoT applications.

Why implement 802.11n rather than 802.11ac for IoT platforms?

There are a few key reasons why 802.11n (Wi-Fi 4) may be better suited for most IoT applications than 802.11ac-based products (Wi-Fi 5). First, 802.11ac is based on 5 GHz versus 802.11n which supports both 2.4 GHz and 5 GHz. 2.4 GHz offers more range and better object penetration compared to 5 GHz. This is a key benefit in home environments with multiple walls and barriers.

Also, IoT Wi-Fi devices like Silicon Labs transceivers and modules are designed with enhanced RF selectivity to maintain reliable communication even in the presence of blockers such as nearby APs, 802.15.4 and Bluetooth devices. The below figure illustrates how advanced interference mitigation techniques help overcome the channel limitations related to the 2.4 GHz band. Learn more in Wi-Fi Learning Center.

One final point, the cost and power consumption of 802.11ac based systems is higher due to the higher protocol complexity. While it does provide enhanced throughput, the data rates provided by 802.11n are more than sufficient for most IoT applications including audio and security/IP camera video streaming.

What are some ways to reduce power requirements using Wi-Fi in IoT applications?

There are a number of ways to reduce power consumption using Wi-Fi:

1. Minimize the time spent in active TX and RX modes: With Wi-Fi’s high data rates, it may make sense to aggregate data and transmit/receive infrequently. It may also make sense to use higher data rates to transmit data more quickly and reduce the amount of time spent in high power transmit modes.
2. Choose the right devices: Not all Wi-Fi chipsets are made the same, so make sure you choose the devices with the lowest possible current consumption for the TX, RX, sleep and DTIM modes you are interested in. Watch out for datasheet tricks and make sure you are comparing apples to apples – this is especially important when looking at “sleep” and “associated” current definitions, as they are defined differently by vendors.
3. Think about the system level: The best power optimizations can be found at the system level, by seeing if you can turn off the radio and only power it on infrequently or using techniques like beacon skipping to reduce idle/sleep current if you are OK with tolerating latency.
4. Use the low power features available in the Wi-Fi standard: The Wi-Fi standard has a number of power optimizing features like DTIM sleep modes and Power Save that can save you a significant amount of power.

Are Wi-Fi solutions as integrated and compact as something like Bluetooth?

Wi-Fi solutions have traditionally been more complex and larger than solutions for Bluetooth. However, this gap is reducing, and there are increasingly smaller, optimized solutions available for Wi-Fi. This new class of IoT Wi-Fi devices takes advantage of Moore’s law to deliver higher performance, and eliminates size/cost adding features like MIMO. For example, Silicon Labs has a pre-certified Wi-Fi SiP module (including a Wi-Fi Radio, RF, XTAL and antenna) in a 6.5 mm x 6.5 mm package, which allows you to add Wi-Fi to small form factor devices.

 

Introduction

If your Wi-Fi connected product is headless, then technically speaking, the obvious solution for exchanging the Wi-Fi credentials required to commission the product onto the customer’s Wi-Fi network is SoftAP.

SoftAP stands for Software Enabled Access Point. Some product manufacturers use SoftAP to create a temporary access point for the unique purpose of getting the customer’s Wi-Fi network name (SSID), security mode and password as illustrated in the following diagram:

The customer connects his smartphone to the connected product’s SoftAP, and then uses either a mobile app or web page that displays the list of Access Points available to select and enter the password.

The connected product, once it has the customer’s Wi-Fi network information (SSID, Password and Security Mode) it connects to the Access Point.

The Access Point lets the connected product join the network and gain access to the Internet.

 

SoftAP used to be the Wi-Fi commissioning solution of choice for early IoT devices, but the two fundamental problems listed below have made it an unreliable solution:

• Once the customer’s smartphone connects to a SoftAP, it will lose Internet connection.
• If the customer’s smartphone loses Internet connection, then the phone’s logic may switch to a different Access Point and thus disconnect from the product.

 

In order to improve the out-of-box experience, product manufacturers have turned to Bluetooth as a solution for commissioning. For the Wi-Fi connected products that already support Bluetooth for a different purpose (e.g. streaming audio or video) then Bluetooth is the go-to mechanism for Wi-Fi commissioning as illustrated in the following diagram:

The customer installs the product manufacturer’s BLE Mobile Application and pairs with the connected product.

The mobile application displays a list of Access Points, the customer selects one of them and enters its password.

The connected product, once it has the customer’s Wi-Fi network information (SSID, Password and Security Mode) it connects to the Access Point.

The Access Point lets the connected product join the network and gain access to the Internet.

 

Because of how important the out-of-box experience is to a product’s success, many product manufacturers should consider going to the extremes of adding a Bluetooth chip exclusively to support the Wi-Fi commissioning of the product. Silicon Labs has BLE chips such as the EFR32MG12 that not only supports BLE but also other wireless protocols in the same chip.

Whatever your case may be, this blog shows you one simple way to use Bluetooth for Wi-Fi commissioning by covering the following topics:

• BLE GATT Server Design
• BLE Mobile Application
• Theory of Operation

 

Prerequisites

It is assumed that you are familiar with Web Technologies such as HTML and JavaScript, and more important, that you are familiar with your own Wi-Fi and Bluetooth stacks regarding the following topics:

BLE Stack

• Tool to create a BLE Generic Attribute Profile (GATT) database.
• Callbacks to handle the BLE Characteristics Read and Write requests.
• API to send Notifications to BLE clients.

Wi-Fi Stack

• API to start a Wi-Fi scan
• Callback to handle the Wi-Fi scan results
• API to join an Access Point
• API to store the Access Point’s credentials in non-volatile memory

 

Hardware Requirements

• Any Wi-Fi chip/module (e.g. Silicon Labs WF200 module)
• Any BLE chip/module (e.g. Silicon Labs EFR32MG12 chip)
• Web Server to host a static web page (e.g. AWS account)

 

Software Requirements

• BLE GATT Configurator
• Google Chrome Web Browser

 

BLE GATT Server Design

Using your GATT Configuration tool, you need to create two BLE GATT Services:

Wi-Fi Scanner Service

This service allows a Bluetooth Client to initiate the scanning of visible Wi-Fi networks and its corresponding information such as SSID, Security Mode and Signal Strength.

Wi-Fi Configurator Service

Allows a Bluetooth Client to configure the connected product with the information necessary to connect to a Wi-FI Access Point (i.e. SSID, Security Mode and Password).

 

The table below shows an example of such GATT database. Notice that the UUIDs have been truncated for sake of simplicity. In reality, they should be 128-bit and it’s important you keep them documented in a table similar to this.

 

BLE GATT Configuration
Service		Characteristic
Name	UUID	Name	BLE Variable	UUID	Value Settings		Properties
					Type	Length	Read	Write	Indicate
Wi-Fi Configurator	2b42…5ab3	State	gattdb_wifi_ cfg_state	c519…07da	user	1	Yes	Yes	Yes
		SSID	gattdb_wifi_ cfg_ssid	a4a3…5da7	user	32	No	Yes	No
		Password	gattdb_wifi_ cfg_password	1d4b…c315	user	16	No	Yes	No
		Security	gattdb_wifi_ cfg_security	0420…278c	user	1	No	Yes	No
Wi-Fi Scanner	9b51…af7d	State	gattdb_wifi_ scan_state	cc89…81c8	user	1	Yes	Yes	Yes
		AP List Part 1	gattdb_wifi_ scan_ap_list_1	d07c…d141	user	255	Yes	No	No
		AP List Part 2	gattdb_wifi_ scan_ap_list_2	7e44…99d6	user	255	Yes	No	No
		AP List Part 3	gattdb_wifi_ scan_ap_list_3	d3c1…b004	user	255	Yes	No	No
		AP List Part 4	gattdb_wifi_ scan_ap_list_4	a2a0…7ee0	user	255	Yes	No	No
		AP List Part 5	gattdb_wifi_ scan_ap_list_5	8907…2823	user	255	Yes	No	No

Table 1 BLE GATT Configuration

 

Characteristics

Both services have a characteristic called State that is used to communicate the state of the corresponding operation. Therefore, both characteristics support Read, Write and Notification.

Here are the possible states:

// Wi-Fi Scanner State Machine States
const WIFI_SCANNER_STATE_IDLE     = 0;
const WIFI_SCANNER_STATE_SCAN     = 1;
const WIFI_SCANNER_STATE_SCANNING = 2;
const WIFI_SCANNER_STATE_SCANNED  = 3;
const WIFI_SCANNER_STATE_ERROR    = 4;

// Wi-Fi Config State Machine States
const WIFI_CONFIG_STATE_IDLE      = 0;
const WIFI_CONFIG_STATE_SAVE      = 1;
const WIFI_CONFIG_STATE_SAVING    = 2;
const WIFI_CONFIG_STATE_SAVED     = 3;
const WIFI_CONFIG_STATE_JOIN      = 4;
const WIFI_CONFIG_STATE_JOINING   = 5;
const WIFI_CONFIG_STATE_JOINED    = 6;
const WIFI_CONFIG_STATE_ERROR     = 7;

Code Listing 1 Wi-Fi Scanner and Wi-Fi Configurator Service States

 

The rest of characteristics are meant to exchange the actual data. Notice that the results from the Wi-Fi Scanner need to be communicated in multiple characteristics because of limitations on the maximum length of a BLE Characteristic’s value (i.e. 255 bytes).

Here is an example of the value exchanged by one of such characteristics. It is in JSON format and it is sorted by signal strength such that the closest access point is displayed on top:

[
 {
   "ssid": "WHIFERAPPS",
   "rcpi": "156",
   "sec": "2"
 },
 {
   "ssid": "SiliconLabsMobile",
   "rcpi": "129",
   "sec": "2"
 },
 {
   "ssid": "SiliconLabsGuest",
   "rcpi": "128",
   "sec": "2"
 },
 {
   "ssid": "SiliconLabs",
   "rcpi": "118",
   "sec": "2"
 },
 {
   "ssid": "DIRECT-bc-HP M203 LaserJet",
   "rcpi": "108",
   "sec": "2"
 },
 {
   "ssid": "GLC-WESTON",
   "rcpi": "86",
   "sec": "2"
 },
 {
   "ssid": "FCAAC",
   "rcpi": "81",
   "sec": "2"
 },
 {
   "ssid": "KENGOLENDESIGNS",
   "rcpi": "67",
   "sec": "2"
 },
 {
   "ssid": "DreamPlanTrack",
   "rcpi": "60",
   "sec": "2"
 },
 {
   "ssid": "Ameriprise Guest",
   "rcpi": "60",
   "sec": "2"
 },
 {
   "ssid": "Ketamine1290",
   "rcpi": "55",
   "sec": "2"
 }
]

Code Listing 2 List of Access Points in JSON format

 

 

BLE Mobile Application

For the BLE mobile application you have the choice of creating a native BLE application to support iOS and Android as a minimum or use Web Bluetooth.

Web Bluetooth allows a web browser (e.g. Google Chrome) to see and interact directly with Bluetooth devices as illustrated in the following image:

The BLE mobile application is actually a web page (i.e. HTML and JavaScript) and it's hosted in the product manufacturer's web server. 

The customer opens a web browser (e.g. Google Chrome) and goes to the web server’s URL to download the web page.

The web page displays a list of nearby BLE devices and pairs with the BLE device you want to connect.

 

The advantages of Web Bluetooth over traditional native BLE mobile applications are:

• One single web page hosted in a web server allows much easier updates.
• One single web page can be used to support all mobile devices
• One single web page can also be used not only to connect via Web Bluetooth but also to host in the connected device in SoftAP mode for a line of products that does not support BLE.
• Developers with HTML and JavaScript skills are a lot easier to find than those with BLE Mobile App development skills for iOS and Android.

 

If Web Bluetooth is used instead of a traditional native BLE mobile app, then the revised block diagram for the Wi-Fi commissioning system using Web BLE would look like the following:

The BLE mobile application is actually a web page (i.e. HTML and JavaScript) and it's hosted in the product manufacturer's web server. The web page allows the user to select from a list of Wi-Fi Access Points and enter the Access Point’s password.

The customer opens a web browser (i.e. Google Chrome) and goes to the web server’s URL to download the web page. The web page displays a list of nearby BLE Devices and pairs with the device you want to connect.

The web page sends a scan request to the BLE device which in turn calls the Wi-Fi stack APIs to scan and get the results. Finally, the web page displays a list of Access Points, the customer selects one of them and enters its password.

The connected product, once it has the customer’s Wi-Fi network information (SSID, Password and Security Mode) it connects to the Access Point.

The Access Point lets the connected product join the network and gain access to the Internet.

 

Theory of Operation

The diagram below summarizes the way the entire system works:

Connected Product (BLE GATT Server)		Smartphone (BLE Client)
		To initiate a Wi-Fi Scan procedure, the BLE Client sends a request to write: BLE GATT characteristic: gattdb_wifi_scan_state  Value: WIFI_SCANNER_STATE_SCAN
The BLE GATT Server receives the request to write: BLE GATT characteristic: gattdb_wifi_scan_state Value: WIFI_SCANNER_STATE_SCAN
If the Wi-Fi Scanner State Machine's state is WIFI_SCANNER_STATE_IDLE then it will call the Wi-Fi API to start a scan
The Wi-Fi stack returns the scan results by calling a callback function. There, the list of access points is stored in a data structure with a global scope for general purposes
The Wi-Fi stack signals the completion of the scan procedure by calling another callback function
The embedded application prepares a multi-part JSON payload to be stored in a data structure with a global scope for BLE purposes
The embedded application sets the characteristic gattdb_wifi_scan_state to WIFI_SCANNER_STATE_SCANNED and notifies BLE clients that this characteristic has changed
		The BLE client receives the notification and sends requests to read the following BLE GATT characteristics:  gattdb_wifi_scan_ap_list_1 gattdb_wifi_scan_ap_list_2 gattdb_wifi_scan_ap_list_3 gattdb_wifi_scan_ap_list_4 gattdb_wifi_scan_ap_list_5
The BLE GATT server receives the requests to read the following characteristics and responds with the values: gattdb_wifi_scan_ap_list_1 gattdb_wifi_scan_ap_list_2 gattdb_wifi_scan_ap_list_3 gattdb_wifi_scan_ap_list_4 gattdb_wifi_scan_ap_list_5
		The BLE client receives indication that the values of the characteristics have changed and calls the corresponding event handlers
		The handler for the event characteristic value changed parses the JSON payload into a JavaScript object, merges each part into a single array of access points, sorts the array by signal strength and populates the drop-down box
		The customer selects the Wi-Fi Access Point he wants to join from the web page's drop-down box and enters the password in an input box
		The BLE client sends a request to write the following BLE characteristics: gattdb_wifi_cfg_ssid gattdb_wifi_cfg_password gattdb_wifi_cfg_security
The BLE GATT server receives the requests to write to the following characteristics: gattdb_wifi_cfg_ssid gattdb_wifi_cfg_password gattdb_wifi_cfg_security
The BLE GATT server updates the variables only if there is not any Wi-Fi configuration in progress
The BLE GATT server changes the state of the Wi-Fi Configuration state machine to WIFI_CFG_STATE_ONGOING and sends notification to the BLE client that this state has changed
		The BLE client receives the notification and to save the Access Point credentials in non-volatile memory, it sends a request to write:  BLE GATT characteristic: gattdb_wifi_cfg_state Value: WIFI_CFG_STATE_SAVE
The BLE GATT server receives the request to write: BLE GATT characteristic: gattdb_wifi_cfg_state Value: WIFI_CFG_STATE_SAVE and if not saving process in progress, it calls the API to store variables in non-volatile memory
The BLE GATT server changes the state of the Wi-Fi Configuration state machine to WIFI_CFG_STATE_SAVED and sends notification to the BLE client that this state has changed
		The BLE client receives the notification and to restart the Wi-Fi interface and connect to the new Access Point, it sends a request to write:  BLE GATT characteristic: gattdb_wifi_cfg_state Value: WIFI_CFG_STATE_JOIN
The BLE GATT server receives the request to write: BLE GATT Characteristic: gattdb_wifi_cfg_state Value: WIFI_CFG_STATE_JOIN and calls the Wi-Fi API to join a network

Figure 5 Flow Diagram

 

Source Code

To keep the blog relevant to any Wi-FI and BLE stack, the source-code-level details on how to perform the different functions outlined in the previous flow diagram have been omitted. 

The following Wi-Fi and BLE APIs are better described in their corresponding documentation and are beyond the scope of this blog:

• Callbacks to handle the BLE Characteristics Read and Write requests.
• API to send Notifications to BLE clients.
• API to start a Wi-Fi scan
• Callback to handle the Wi-Fi scan results
• API to join an Access Point
• API to store the Access Point’s credentials in non-volatile memory

The web page that makes the actual BLE mobile application however, is provided as an attachment (web_ble.zip) and if you like this approach, feel free to modify it and use it under the terms of the Apache License.

 

Security Considerations

Because of the sensitive nature of the information exchanged, you should consider using the security features of your Bluetooth stack:

• Pairing
• Bonding
• Device Authentication
• Encryption
• Data Signing

Check your Bluetooth stack documentation for more information on  these security features.

 

 

Further Reading

• Silicon Labs GATT Configurator User's Guide: https://www.silabs.com/documents/login/user-guides/ug365-GATT-configurator-users-guide.pdf
• Silicon Labs BLE API Reference: https://www.silabs.com/documents/login/reference-manuals/bluetooth-api-reference.pdf
• Silicon Labs Non-Volatile Data Storage Fundamentals: https://www.silabs.com/documents/public/user-guides/ug103-07-non-volatile-data-storage-fundamentals.pdf
• Silicon Labs Wi-Fi Solutions: https://www.silabs.com/products/wireless/wi-fi
• Web Bluetooth Samples: https://googlechrome.github.io/samples/web-bluetooth/
• Interacting with Bluetooth devices on the Web: https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web

Introduction

Hello and welcome to the inaugural article for a new blog series, Timing 201. My previous blog series, Timing 101, ran for 12 articles over a period of roughly a year and a half.

As the name suggests, I intend to discuss timing topics with a little bit more breadth and depth than might be considered “Timing 101” material. However, that does not mean I won’t cover introductory material, if and when it’s called for, especially if readers ask for it.

When More is Less

You may recall that clock buffers are typically specified in terms of additive jitter. That is because they do not have an intrinsic phase noise source such as an XO (crystal oscillator) or a PLL’s VCXO. They consist of only amplifiers and perhaps dividers. So we would generally expect an XO followed by a clock buffer to have at least somewhat increased phase noise or jitter compared to the XO alone.

All things being equal, this will be the case, except when the amplifier has sufficiently high gain to act as a limiting amplifier or LA. In these situations, the apparent measured source + LA phase noise may actually decrease. I ran in to this phenomena years ago evaluating various clock + buffer combinations. The results weren’t always making sense and it turned out at the time that some of the noise I was measuring was in fact, not really phase noise, hence the title of this case.

To see how this might happen, let’s touch on what is meant here by apparent measured phase noise.

Phasors ON

You may recall I discussed modulation spurs previously in Timing 101 #7: The Case of the Spurious Phase Noise Part II. In that article, I considered carriers with relatively small amounts of AM (Amplitude Modulation) and narrowband FM (Frequency Modulation) or equivalent PM (Phase Modulation). The general ideas comparing AM and FM/PM spurs also apply to AM and FM/PM noise.

One topic I did not touch on at that time was the phasor or phase vector representations of AM and NB FM as shown below. The carrier vector is shown as a thick red arrow and the modulation LSB (lower sideband) and USB (upper sideband) vector components are shown as thinner blue arrows. The vector sum or resultant of the modulation is the thick blue arrow. The modulating frequency is f<subscript>M and the rotating arrows indicate the change in the modulation vectors over time versus the carrier. For the figures below the overall vector sum is the geometric addition of the carrier + modulation resultant.

What’s useful about the phasor representation is that it indicates that random noise modulating the carrier can be regarded as consisting of both AM and PM components. That is, components of the noise contributing to carrier magnitude changes are the AM components. Likewise, components of the noise contributing to carrier angle changes are FM or equivalent PM components.

You may see authors emphasizing this distinction by using script L(f) or ℒ(f) to refer to PM noise or “real” phase noise and script M(f) or ℳ(f) to refer to AM noise. The first paper I know of using this notation is:

Spectral Density Analysis: Frequency Domain Specification and Measurement of Signal Stability, by Donald Halford, John H. Shoaf, and A. S. Risley, National Bureau of Standards, Boulder, CO, published in 27th Annual Symposium on Frequency Control, 12-14 June 1973, https://tf.nist.gov/general/pdf/1558.pdf

The magnitude of noise that is AM + PM will be the RSS or Root Sum Square of the individual modulation contributions. Instruments that treat these noise components the same will then “see” this RSS noise directly as phase noise. This is what is meant by apparent phase noise and it is a particular issue for Spectrum Analyzers as discussed below.

The Spectrum Analyzer in Brief

As I noted in Timing 101 #7, Spectrum Analyzers do not preserve phase information and so a low modulation AM spur appears similar to a narrow band low modulation FM spur. 

Below is a block diagram for a classic swept spectrum analyzer which suggests why. It is essentially a calibrated frequency selective peak responding voltmeter. The difference in phase between the DUT (Device Under Test) and the LO (Local Oscillator) inputs at the mixer is arbitrary. The Spectrum Analyzer doesn’t “know” anything about their relative phases and AM and PM cannot be distinguished. 

The Phase Noise Analyzer in Brief

By contrast, the Phase Noise Analyzer is much less susceptible to AM. The simplified block diagram below gives the basic idea behind the method typically used by Phase Noise Analyzers and Signal Source Analyzers. The mixer is usually a double-balanced mixer to suppress even-order mixing products.

Note that, unlike the Spectrum Analyzer, there is a PLL (Phase Lock Loop) that enforces a specific phase relationship between the DUT and the Reference. Further, it can be shown that AM and PM can be distinguished as follows.

• If phase offset = 90˚ then the mixer detects PM and suppresses AM
• If phase offset = 0˚ then the mixer detects AM and suppresses PM

As designed, the Phase Noise Analyzer will be superior to the spectrum analyzer for rejecting AM.

Take It to the Limit

So how exactly does the limiting amplifier or LA help us here? The clue lies in the behavior of the LA: It removes, or at least minimizes, amplitude variation from the clock signal. Therefore, if a source has both AM and PM noise components, then an ideal limiter will remove the AM component noise leaving only the PM noise (the genuine phase noise) behind.  The exaggerated sketch below gives the basic idea.

Now getting back to the original work which prompted this post:

If a clock source had apparent phase noise that included both AM and PM noise contributions, then following it with a high gain clock buffer or LA would strip away the AM resulting in less than expected measured phase noise. Rather than yielding additive jitter the new component apparently yielded “subtractive” jitter. Thus the case of the phase noise that wasn’t.

When should AM be considered when making phase noise measurements?

The short answer is that AM is always a potential consideration when one is making careful jitter and phase noise measurements. Having a limiter on one’s lab bench is as important as a balun.

However, there are specific instances where AM can be more of an issue than others.

1. Measuring phase noise using a spectrum analyzer or any other instrument that does not sufficiently reject AM.

A limiter can be valuable even when working with a Phase Noise Analyzer by suppressing AM beyond the rejection capability of the mixer. This may be necessary when measuring very low phase noise sources.

2. Measuring low frequency low phase noise sources.

You may recall the 20log(N) rule, i.e. if the carrier frequency of a clock is divided down by a factor of N then we expect the phase noise to decrease by 20log(N); however, this rule only applies to phase noise. If there is significant AM noise also then this component will loom larger, as we decrease the carrier frequency, and potentially impact measurements.

3. Measuring a source known or suspected to have AM noise.

Clock sources with high common mode noise fall in to this category. For example, we specifically inject power supply ripple when testing oscillator power supply rejection. This is why you see a limiting amplifier shown in Figure 5. PSRR Setup in AN491: Power Supply Rejection For Low-Jitter Clocks. See the highlighted block in the diagram below which comes from that app note.

 

4. Troubleshooting

Finally, the ability to distinguish between phase noise and spurs, and AM noise and spurs, can be very helpful when troubleshooting a system and determining the root cause of performance issues. Additional testing may also be needed to determine how sensitive the ultimate receiver is to clock impairments that include AM noise.

Conclusion

I hope you have enjoyed this Timing 201 article. In the next article, I will give some measurement examples and offer a few rules of thumb.

As always, if you have topic suggestions for this blog or timing-related questions, please send them to kevin.smith@silabs.com with “Timing 201” in the subject line. I will give them consideration and see if I can fit them in. Thanks for reading. Keep calm and clock on.

Cheers,

Kevin

 

 

 

 

This blog is part of the Kernel 201: Designing a Dynamic Multiprotocol Application with Micrium OS. The table of contents for this blog series can be found here.

Note: It is recommended to download the Kernel 201 WebBluetooth Application and have the code in front of you as you go through this blog post. The code can be downloaded on the Kernel 201: Project Resources page. 

 

Introduction

WebBluetooth API is a Javascript API that provides Bluetooth support for web pages. The API, which was first published in 2015, is still considered Experimental but it has been supported in Google Chrome since version 56 and Opera since version 43 for desktop and Android devices. At the time of writing this, WebBluetooth API is still not supported on Edge, Firefox, or Safari and it does not work on iPhones at all.

The advantage of using the WebBluetooth API is it allows for a quick way to develop an application that can run on desktop or mobile from the same code. In the past if a developer wished to interact with Bluetooth on both desktop and mobile, typically separate applications were needed. The code provided on the Project Resources page runs on any web server that has HTTPS enabled, and will work on desktop and Android.

The full WebBluetooth API can be found here.

 

WebBluetooth App

The WebBluetooth App that interacts with the Kernel 201 Application is based off of StartBootstrap’s SB Admin 2 template. The template provides the necessary css code to support small screens such as mobile devices and large screens like desktop monitors.

The code included in the WebBluetooth App has been paired back considerably from the full SB Admin template to only include the files needed. If you wish to view the entire SB Admin template, it can be found here.

There are only 3 files and one folder in the WebBluetooth App specific to the Kernel 201 Application. The rest of the files are part of Bootstrap, jQuery and SB Admin files that do not need modification.

• index.html & images directory
• css/bt.css
• js/bt.js

 

index.html & images directory

 

The entire WebBluetooth App’s HTML code is located in this one file. The app’s display is very simplistic, just display fields and buttons for control. All of the different views for the application are already in the index.html page, the Javascript code controls the showing and hiding of different elements based on the different states of the application.

The images folder holds the different images shown in the WebBluetooth App. In the current version of the application it is used only to hold the logos as seen above.

 

bt.css

The bt.css file is the main css file from the SB Admin template. There have been minor changes such as color scheme, screen size and card behavior made to the file.

 

bt.js

This file is what controls the behavior of the WebBluetooth App. It contains the WebBluetooth API code as well as control of what elements are shown on the index.html page.

 

After clicking the Lab 1 button, a user is brought to the screen above. Clicking connect will trigger the function btConnect() in bt.js. This function begins making WebBluetooth API calls that will start the connection process to the Kernel 201 Application.

function btConnect()
{
    navigator.bluetooth.requestDevice({ 
        filters: [{ services: [btServiceUUID] }] 
    })
    .then(device => {
        btDevice = device;
        btDevice.addEventListener('gattserverdisconnected', 
                                  bt_cb_ondisconnected);

        return btDevice.gatt.connect()
    })
    .then(server => {
        bt_view_connection(true);
        return server.getPrimaryService(btServiceUUID)
    })
    .then(service => {
        btService = service;

        return bt_listen(service);
    })
    .then(_ => {
        return bt_update();
    })
    .catch(error => {
        console.log("Error: " + error);
    });
}

 

The Javascript Engine runs in a single thread, so when it hits a function that requires a delay or user input, instead of blocking the entire application it puts that function off until the delay or input is received and continues executing the rest of the code. In order to ensure the WebBluetooth API functions are called in order, the connect code relies on Javascript Promises. The Promises allow the connection events to happen sequentially using the then() keyword. In the example above you can see that the connect() will not occur until the requestDevice() function has finished. If the then() keyword was not used, Javascript would attempt to run connect() before the requestDevice() function completed causing an error.

 

When the requestDevice() function is first executed, a filter is applied. The filter is using the UUID of the Lab Control service. You may recall from the Kernel 201: Bluetooth Task blog that the Lab Control service contains all of the tasks in the lab application. By filtering on the Lab Control service, it allows the Bluetooth Connection Dialog to only show Bluetooth devices running the Kernel 201 Application as shown above.

 

After the connection is made, the WebBluetooth App connects to the Lab Control service and subscribes to notifications from all of the characteristics specified. The notifications allow for the Kernel 201 Application to send a status update to the WebBlueooth App as soon as it occurs, rather than having the WebBluetooth App constantly poll for changes. After its completed the notification subscriptions, the WebBluetooth App makes read requests from the Kernel 201 Application and displays the device state as shown above.

Once the display has been changed to the current state of the Kernel 201 Application, the WebBluetooth App maintains a Bluetooth connection but sit idle until one of two actions occur:

• The user clicks a button
• A notification is received from the Kernel 201 Application

When the user clicks an LED button, the LED write function will call the Bluetooth write function to send a write command to the Kernel 201 Application with the LED data. After the command is sent, the WebBluetooth App does not change the user interface to reflect the command just sent. The change in the user interface will come from the Kernel 201 Application sending a notification that a change has been made to the LED. This prevents the user interface from getting out of sync with the Kernel 201 Application.

When a notification is received from the Kernel 201 Application, the callback bt_cb_onnotify() fires and determines what portion of the UI needs to be updated. It then passes along the received data to the necessary functions to update the UI.

 

Final Thoughts

The WebBluetooth API provides a simple, quick way to create apps that run on both mobile and desktop natively. Unfortunately, since it is still experimental, there is a lack of support for it. Hopefully in the future, it will become a widely accepted way of interacting with Bluetooth devices. If you have any questions or thoughts on this feel free to leave them below.