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.

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

Tile is the leading maker of Bluetooth trackers that help you track your belongings such as keys, backpacks, teddy bears or, more generally, any object you want to be able to locate easily when needed. There are two basic building blocks needed; the Tile hardware device that you attach to the item you want to track and the Tile mobile application that you can use to locate the Tile.

Now, with the introduction of Find with Tile, Tile technology can now be embedded into any product quickly and easily.

For a generic introduction to the Tile, see the “how-it-works” section on the Tile website.

Find with Tile hardware (i.e. devices with Tile technology embedded) is typically physically small and needs to be consume minimal energy so that it can be battery powered. The required range of operation is in the order of tens of meters and therefore it is a perfect match for Bluetooth Low Energy that has been designed exactly for use cases like this.

The Tile embedded application (i.e. the code that runs on the Tile itself) can be run on Silicon Labs EFR32 based SoCs and modules. It can be used with any Blue Gecko part. For easy demonstration, this article includes a project that runs on the Thunderboard Sense 2.

Thunderboard Sense 2 is small, low cost and it can be powered off a CR2032 coin cell battery so it’s a good platform for prototyping Tile functionality. The Tile embedded code is available as a C code library that can be ported also on other Silicon Labs Bluetooth development kits.

At the end of this article you will find pre-built binaries that you can program to your Thunderboard Sense 2. Using the pre-built demo is easiest way to get started. The entire demo project is also available if you want to have a closer look on how it’s done.

Using the pre-built binaries

The pre-built binaries for Tile demo on Thunderboard Sense 2 are provided at the end of this article as attachments. It consists of two files:

· Gecko bootloader for Thunderboard Sense 2 (gecko_bootloader_TBS2-combined.s37)

· The Tile demo application (Tile_on_TBS2.hex)

You can flash the binaries to your TBS2 using Simplicity Commander which is a utility that comes with Simplicity Studio.

Follow these steps to program the demo:

1- Launch Simplicity Studio and connect your TBS2 to your PC with the USB cable

2- Make sure the board is detected by Simplicity Studio as shown below:

3- Launch Simplicity Commander from the Tools menu:

Commander launches in a separate window. Following screenshot shows the required steps to flash binaries to the target.

1. Press Connect button to connect to the embedded J-Link debugger on the TBS2

2. Press Connect (next to the Target label) to connect to the EFR32MG12 device on the TBS2

3. Open the Flash tab from the left side menu

4. Use the Browse… button to locate the binary files on your computer

5. Press Flash button to program the file to target

First program the bootloader file (gecko_bootloader_TBS2-combined.s37). Then repeat the same procedure for the application image (Tile_on_TBS2.hex).

After programming the two binaries, you can either keep running the Tile so that it is powered from the USB cable. Alternatively, you can unplug the cable and insert a CR2032 coin cell to power the device.

How does the demo work?

Once you have programmed the Thunderboard Sense 2 with the provided bootloader and application image, the device starts to advertise using name “Tile”. You can observe it with any Bluetooth LE test utility, but to take advantage of the Tile features you need to use the Tile mobile app that is available for Android and iOS. Install the app on your mobile device from Android Play Store or Apple App Store.

First step in taking a new Tile into use is registering the Tile with the mobile app. The procedure is the same as with “real” Tiles, as explained in the Tile website. However, note that with this demo you do not need to press any button on the Thunderboard Sense 2 to activate it. The device starts to advertise as soon as the board is powered up (either through USB cable or a CR2032 coin cell).

After registering the Tile with the mobile app, the UI should look something like this:

You can give the tile any name you want. In the above screenshot, it is named “Tbsense 2”.

Whenever the Tile is in the range of the phone, the app will make a connection with it. The green Find button in the UI indicates that the connection is established. You can press the Find button to make the tile “Ring”. The Thunderboard Sense 2 does not include a speaker, so the Ring feature is indicated by flashing the RGB leds on each corner of the PCB. The flashing continues until you press “Done” on the mobile app.

The mobile app keeps a connection open with the Tile as long as it is within range. Maintaining a Bluetooth connection is very power-efficient because the protocol has been optimized for battery-operated devices. An estimated current consumption (averaged) for different modes are summarized below. Note that the current consumption is not optimized to the last detail, these figures are just to give a rough estimate about the current consumption.

• Beaconing (not connected to the mobile app): 50 uA
• Connected to the mobile app: 310 uA
• Ring function active (red LEDs flashing) : 7.3 mA

Note that the bright RGB LEDs draw a lot of current and therefore the current consumption while device is ringing is high. Do not leave the Ring on for long duration to avoid draining the coin cell battery.

Building the Project from Source

The demo project is also provided as an archived Simplicity Studio project (*.sls file). You can import it in Simplicity Studio via the Project -> Import -> MCU Project… menu.

Note: the project is only for the application, it does not contain bootloader. You can use the pre-built bootloader image or alternatively create a Gecko bootloader project for Thunderboard Sense 2 in Simplicity Studio and build the bootloader yourself.

The archived project is created using Bluetooth SDK 2.10.1 and GCC toolchain 7.2.1. You need to have these installed in Simplicity Studio to be able to use the project.

Here are some tips on how to navigate the project contents:

• The Tile library (provided by Tile, Inc.) and other files are found in subdirectories Tile_Common, Tile_Include, Tile_Lib
• main.c contains some basic initializations, but the application main loop is found in application.c
• application.c is implemented using the same event driven approach as all of Silicon Labs Bluetooth example apps, for more details refer to UG136: Silicon Labs Bluetooth ® C Application Developer's Guide.

The application main loop includes handlers for basic events such as connection opened / closed etc. You can add any custom functionality into the application as you wish. The Tile application is integrated to the project so that at the end of the event loop (your own code), the same Bluetooth stack event is forwarded to the Tile event handler by calling tile_on_ble_evt().

The Tile app requires a valid Tile ID and key pair. These can be obtained from the Tile website by filling out a form here.

The credentials you receive from Tile must be inserted to file Tile_Common\tile_storage.c. Replace the dummy values in variables interim_tile_id, interim_tile_key with the actual credentials that you have received from Tile, Inc. Registration of the Tile will not work unless you replace the dummy values with valid credentials.

The example uses custom advertising packet format and the advertising payload is set in function setup_custom_advertising() (in application.c). You can modify the payload if you wish, as long as the Tile service UUID is included.

The name that is advertised is set in function setup_custom_advertising() and the default name is “Tile”.

In addition to passing BLE stack events to the Tile handler, the demo application needs to have some hook to start and stop the Ring function that is triggered when you press the Find button on the mobile app. The callback functions to start and stop ringing are found in file Tile_Common/tile_service.c. The functions are play_ring_song() / play_ring_song().

In this demo implementation, the above callbacks will call function gecko_external_signal() that triggers an event in the Bluetooth stack. The event is then handled in the application main loop. The mechanism is similar to what is used typically to detect button presses or other interrupts in a Bluetooth application. More details are found in UG136, Chapter 6 Interrupts.

Last week, the Bluetooth SIG announced an update to the Bluetooth specification in response to a security vulnerability related to Secure Simple Pairing and LE Secure Connections.

According to the SIG, researchers at the Israel Institute of Technology identified that the specification recommends, but does not require, that a device supporting these features validate the public key received over-the-air when pairing with a new device. The Bluetooth SIG has now updated the Bluetooth specification to require the validation of such keys.

At initial connection, when pairing Bluetooth devices, the devices use mutual authentication to securely connect. The SIG has discovered the security vulnerability in the reference implementation of the public key validation during this mutual authentication (https://www.bluetooth.com/news/unknown/2018/07/bluetooth-sig-security-update).

This means that an adversary could perform a man-in-the-middle attack during the pairing process, even for authenticated pairing schemes like numeric comparison or passkey entry. This allows the adversary to listen to and/or modify all the communication on the paired connection.

Our Wireless Gecko products (Blue Gecko and Mighty Gecko) are not affected by this issue because they leverage the mbedTLS ECDH implementation that does not have this vulnerability. The BLE112, BLE113, BLE121LR and BLED112 modules are also not affected because they do not implement the feature that contains the vulnerability. Our BT Classic products, which include the BT111 and WTxx modules, are not affected.

Our BT121 Bluetooth dual mode module is vulnerable to this issue. We expect to release a patch that protects against this vulnerability within 17th August 2018.

This week, we’ve introduced a Wireless Gecko software solution created to simplify industrial and commercial IoT applications using sub-GHz wireless connections by adding Bluetooth connectivity. The new hardware and software solution enables simultaneous sub-GHz and 2.4 GHz Bluetooth low energy connectivity for commercial and industrial IoT applications, such as smart metering, home and building automation, and commercial lighting.

This is important for the industrial and commercial sectors for several reasons – for one, it’ll make it much easier for people working in these environments to set-up, control, and monitor sub-GHz IoT devices using Bluetooth low energy mobile apps.

Sub-GHz wireless protocols are used extensively in industrial and commercial settings because many of them require a combination of energy efficiency, long battery life, and extended range for remote sensor nodes. Proprietary sub-GHz protocols allow developers to optimize their wireless solution to their specific needs instead of conforming to a standard that might put additional constraints on network implementation. With our new software solution, sub-GHz protocols can still be utilized for their benefits, but users can also easily manage the system using Bluetooth mobile apps on a variety of devices, such as tablets or smart phones.

Sub-GHz environments are typically low-data-rate systems, such as simple point-to-point connections to large mesh networks and low-power wide area networks (LPWAN). By adding Bluetooth with low energy connectivity to wireless networks in the sub-GHz band, developers can deliver new capabilities such as faster over-the-air (OTA) updates and deploy scalable, location-based service infrastructure with Bluetooth beacons.

Single Chip Reduces Cost by 40 Percent

IoT developers stand to gain tremendous development benefits by avoiding the complexity of two-chip wireless architectures. By using a single chip with both sub-GHz and BLE connectivity, developers can simplify hardware and software development, which can speed time-to-market and reduce bill-of-materials (BOM) cost and size by up to 40 percent.

Accenture estimates industrial IoT could add $14.2 trillion to the global economy by 2030, making the deployment potential of this solution especially massive. Any new technology developments such as this one that helps developers control and monitor industrial and commercial devices and data more easily leads to efficiency and economic gains for both businesses and the users.

Mobile control applications are often a crucial piece of industrial and commercial automation, giving system operators a quick and easy way to control equipment. For instance, commercial lighting depends heavily on mobile devices, which control lighting on/off schedules, energy efficient modes and rules, and dimming based on occupancy using ambient light sensors. Often times, the mobile app may be the only control interface installers, designers and site managers have for project commissioning and configuration.

Bluetooth connectivity allows the device apps and interface to be simple, which can make a difference in user adoption, as many lighting and commercial controls can be complex and difficult to manage.

Our new solution will clearly yield impressive benefits for both developers and the users of the industrial applications. Fortunately, the new multiprotocol software is now available using Silicon Labs’ EFR32MG and EFR32BG Wireless Gecko SoCs. Check out more details here if you’re working on a product that could benefit from the solution.

Play Impossible has reinvented the ball by connecting it to phones and tablets. They’ve managed to do this while maintaining the look and feel like a ball found on any gymnasium floor. Launched in October of last year, Play Impossible won first place at the Last Gadget Standing competition at CES in December. With rave reviews from USA Today, CNN, and Mashable, Play Impossible’s Gameball is capturing the hands and minds of kids as it provides another way to play ball with the modern insight of today’s connected devices. Silicon Labs had the opportunity to sit down with cofounder and CTO Kevin Langdon to hear how the company got its start and what he sees for the future.

How did Play Impossible come about?

All of the founders of the company are dads. And as parents, we have all struggled with the amount of time our kids spend on devices. This particular problem was the impetus for the company - how do we get our kids up off the couch in active play and doing what we call active play. Active play is physical and involves movement, but it’s also social and creative in nature. These are important things that many kids today aren’t getting enough of, and there are plenty of studies saying this is only getting worse. Getting kids to move and play is what Play Impossible is all about.

The quality of Gameball is amazing - it’s a real ball.

Yes. If you couldn’t see the charging part, most people would not know there are electronics inside of the ball. The quality of the ball was important to us, but that aspect of the product definitely was not in our wheelhouse, and we didn’t want to reinvent the process. So we partnered with Baden Sports, which specializes in sports equipment, to build the ball.

What were some of the original design requirements when you set out to create the ball?

We really wanted to create something with a reasonable price point, especially when it’s sitting on a shelf next to $5 balls in a retail setting. The connection range of the device was critical as well. We needed a Bluetooth to stay connected as far as you could throw the ball. Silicon Labs played a big role in helping us do this. Power was another issue – creating a solution that didn’t get in the way in terms of charging.

What was Silicon Labs’ value proposition in the beginning?

I first started looking at Blue Gecko when I was working on another product for SkyGolf. And then with Gameball, we looked at a lot of modules and realized the range and low-power functions were two pieces that we knew Silicon Labs could help with.

Were there any unforeseen challenges that you came across, such as weight, size, etc.

The hardest part for us was getting the durability right with all of the electronics inside. We also came up with a unique solution for the power. There is no battery in the ball, it runs entirely on super capacitors. We needed to do that for both cost reasons and to maintain the durability. I’m pretty happy with the solution we came up with - it’s a real jaw dropper when people see our ball charge up in 20 seconds.

What was the Last Gadget Standing competition at CES like?

There were hundreds of applicants and they narrowed it down to 10 gadgets on stage. I had no expectations of being selected, but when we were, we were honored. One of the gadgets was a Star Wars VR gadget, and it was two months after Star Wars had hit movie theaters. But it went really well and was a lot of fun. The host, David Pogue, was tough and asked a bunch of questions, but he loved the product.

What types of pressures are you under to be innovative – is it developing new games, cost of goods, talent? It’s definitely creating new games. It’s a combination of making the ball new again. Anyone who has a kid knows kids typically like a new toy for a few days, but then on the fourth day, the toy tends to be thrown into the closet. We want to make sure our product is played with a long time beyond those four days. The new games we create make the ball new again and give the kid a reason to get the Gameball back. We are driven to create hit games that are what everyone is talking about.

Is all of the production for Gameball done in house?

When we first started, we hired an experienced gaming designer to build the game, as it’s definitely not a traditional game. We had to do a lot of heavy prototyping and understand the software and hardware capabilities. We had to figure out what the product would be capable of doing socially and with Bluetooth and power. We definitely pushed the limits in terms of what we could do with those functionalities. For example, with a lot of IoT products, real time doesn’t matter. Of course it’s always important to be quick, but real time isn’t critical. With us, if you look at other playables on the market with Bluetooth, I don’t think there are any products as fast as Gameball. The game requires feedback from your fingers on the ball as quickly as possible to get the gestures from the beginning with the ball.

Where do you see the future of IoT going? And where do you see it expanding for the everyday person?

Right now, expectations are low among the average consumer of what IoT is all about. When our product is sitting on a shelf at a retail location, no matter how much we put on that box, there is little a consumer can understand about the product until they actually play with it. It’s going to take years for consumers to change and expect connectivity in everything. The nice thing is it’ll be much easier at that point for businesses such as ours. But today, it’s a critical issue for us in terms of marketing and sales. We see ourselves as a software platform that can interact with many different devices. Gameball is just the first of many devices and accessories that will change how we play in the future.

The benefits of mesh technology continue to gain traction among IoT developers as end-users experience sizeable application performance gains from IoT devices tapping this type of wireless interconnection network.

In the new whitepaper, “Selecting the Appropriate Wireless Mesh Network Technology,” we give IoT developers much-needed advice into considerations required for selecting wireless mesh networks for IoT applications, such as lighting systems, retail beacon systems, or building or home automation.  

Mesh networks use connected devices as nodes to extend connectivity, shortening proximity ranges for connectivity and allowing device-to-device communication often without the need of a cloud gateway. For instance, the connectivity range for lighting systems is extended every time a new light is introduced to the system, enabling any light switch action to stay within the mesh network instead of being transmitted over a cloud gateway. One of the main benefits of mesh networks is their ability to remove latency issues and speed device application performance.

The new whitepaper hits briefly on some of the applications benefiting from mesh networks, yet focuses mainly on explaining the nuances of integrating IoT devices into wireless mesh networks.

Interoperability with already deployed wireless protocols, such as Zigbee and Bluetooth, is discussed in length in the paper, along with best practices using the Thread mesh protocol. Different service providers have requirements for a specific protocol and/or multiple protocols; therefore, designers must be aware of these details when selecting the appropriate connectivity solution. Many existing devices use Zigbee, and for new devices based on a technology such as Bluetooth mesh, an interoperability strategy either through the end device or gateway supporting multiple protocols needs to be considered. Several other important interoperability insights are discussed in the paper, as well as the importance of ensuring the entire connectivity ecosystem is addressed and adaptation of IP at the gateway is successful, as needed.

Another valuable theme conveyed is the use of wireless standards and how to use the protocols depending on the type of device and application. Of the three standards discussed in the paper, the Thread mesh standard is the only protocol based on IPv6, providing several unique benefits, such as end-to-end routing and addressability on the same or across networks. Development tips are also discussed, such as the fact that Bluebooth low energy can be combined with Zigbee to simplify device setup via Bluetooth commissioning, using smart phones for Zigbee devices or to provide the Bluetooth connectivity needed to support Apple Homekit.

Silicon Labs has a multiprotocol software and hardware solution designed to solve many of the issues detailed in this article, which helps designers design a single product supporting multiple wireless connectivity protocols. This can be the same device capable of connectivity to multiple protocols in the field, or a device with the ability to be configured in the field or factory to one of a number of different wireless protocols.

As is often the case, one protocol may not be able to meet the needs of all products and markets, though this paper provides a fair amount of insight into which one to consider depending on the type of application the designer is tackling.

Download the whitepaper.

Trade show season is in full swing, and we’re looking forward to our upcoming trip to Nürnberg, Germany for Embedded World 2018. With over a thousand exhibitors and more than 30,000 attendees, this is the premier event for embedded systems design in the world. And Silicon Labs will be there showing off the latest silicon, software, and solutions that have made us a leader in IoT.

If you’re there, plan on coming by Stand 4A.128 to check out the following demos. And if you want to meet with us, register here.

Wireless

Come discover why our newest Wi-Fi chips and modules with best in class power and sensitivity are the ideal solution for IoT and other embedded applications. We'll also show you how the advanced security features in these devices, like built-in secure link, secure debug and secure boot protect help your devices and code.

MCU/Micrium

Highly capable, low power systems can be hard to develop, especially when adding wireless connectivity. We’re working to solve this challenge. When your application needs long-range wireless, innovative features, and longer battery-life, our new EFM32 Giant Gecko MCU and the pre-certified Digi XBee3 smart modem come to the rescue. Stop by and see how these solutions, along with Micrium OS and advanced development tools address this challenge in IoT.

Isolation

Isolation is critical in wired communication, protecting both hardware and humans operating the hardware from high voltages. This demo will show two industrial EFM8 microcontrollers communicating through Silicon Labs’ isolators for a more robust system.

Proprietary Wireless

Silicon Labs’ multiprotocol solutions enable advanced connectivity without increased cost or complexity. We’ll be showing off our latest innovations in dynamic multiprotocol, combining Bluetooth and Proprietary Sub-GHz in a single multiprotocol, multi-band wireless SoC. 

Bluetooth

See how our Bluetooth solutions seamlessly sync with Apple HomeKit and Bluetooth LE applications. With our Blue Gecko and voice over Bluetooth software and hardware, you can enhance your third party Bluetooth enabled devices.  

Mesh Networking

Silicon Labs is the industry leader in mesh networking. With Zigbee, Thread, Bluetooth mesh and Multiprotocol solutions, Silicon Labs can help customers select the right mesh technology for their application. Come learn about the various mesh protocols and see how Silicon Labs hardware, software, tools and reference designs can get you to market faster. 

Securely Managed IoT Solutions

Silicon Labs is showcasing a commercial-grade managed solution for connected product manufacturers. It is illustrated here with a Silicon Lab’s ZigBee SoC, a reference gateway for OEMs and a cloud-based Device Management Service. Go from concept to market-ready IoT solution faster than ever. 

Silicon Labs experts will also be speaking on the following topics:

Feb. 27th

• What is an IoT OS? - Øivind Loe; 9:30am-10
• How Do You Select Which IoT Protocol to Use? - Matt Saunders; Noon - 12:30       
• Security in Manufacturing: Closing the Backdoor in IoT Products - Josh Norem; 2:30pm - 3
• Understanding Advanced Bluetooth Angle Estimation Techniques for RT Locationing - Sauli Lehtimaki; 4pm-4:30
• Dotdot Unifies Legacy Device Networks – Mark Tekippe; 4pm-4:30

Feb. 28th

• The IoT Requires Upgradable Security – Lars Lydersen; 11:30am – Noon
• ARM Cortex-M and RTOSs Are Meant for Each Other - Jean Labrosse; 11:30am – Noon
• Unraveling Mesh Networking Options: Benchmarking Zigbee, Thread, and Bluetooth Mesh Protocol Stacks – Tom Pannell; Noon-12:30

March 1

• Debugging Live Cortex-M Based Embedded Systems – Jean Labrosse; 4pm-4:30

IoT Hero DeviceRadio Levels Playing Field for IoT Innovation

Just before the holidays, Silicon Labs had the chance to sit down with Christian Klemetsson, the founder of Swedish-based start-up DeviceRadio. The company has created a horizontal connectivity layer of technology that sits on top of various protocols supporting IoT products, such as Wi-Fi, LoRa, Bluetooth, etc. The seamless layer removes the need for specific IoT design expertise, giving companies and designers of all backgrounds immediate ability to build IoT products from the ground up, regardless of designer expertise.

Tell me about DeviceRadio – how did it come about?

The company started out as a hobby project. At the time, I was killing all of my houseplants and it was getting expensive to replace them. I have an electronics background, so I wanted to build some sort of solution to monitor the plants with an application on my phone. I quickly realized that building something cheap, simple, and with long battery life wasn’t available. The solutions I found were based on technology built for other purposes. For example, Bluetooth, at least at the time a few years ago, wasn’t built for IoT, only wireless peripherals. So I created my own radio protocol specifically for IoT and added encryption and plug and play along with additional features. Two and a half years ago, I found the Silicon Labs/Digi-Key competition and entered the device I had just built. I ended up being one of the winners and received $10,000 worth of components from Silicon Labs. I also received media attention in Sweden from the electronics press, and the overall feedback was that I was on the right track – there was a possible missing piece in IoT. From that starting point, I started DeviceRadio.

Was your IoT radio protocol the first one you’ve seen on the market?

At that point, (2014) there wasn’t anything specifically for IoT. There were protocols for low-power communications, such as Z-Wave and peripheral protocols, such as Bluetooth and Wi-Fi, but nothing for IoT.

What I did was transform the protocol into something that could be placed on top of existing protocols, which would provide encryption, plug and play, abstraction, etc. Regardless if you’re using Bluetooth, Wi-Fi, 4G, etc., it would all be the same. Our layer goes on top of whatever protocols you’re using, making everything seamless and consistent. 

The product is sort of like the Internet, but specifically for devices and their sensor data and signals. We create the mechanism to move sensor data between each other and provide the integration to cloud platforms and services.

You call this horizontal connectivity, right? How would you explain the value of this concept to a non-developer?

I think it’s easier to talk about the value of Internet connected devices to help non-developers understand the value of our product. When working with today’s technologies to build connected devices, a lot of custom development and expertise is required. You need to know about security, servers, scaling, protocols, etc., and hook everything up to an IoT platform. This process becomes limiting and IoT development ends up being only available to a select few companies with this level of expertise.

What we’re trying to do is democratize and hide the complexity of IoT by placing a horizontal layer on top of everything. This means if you’re a product company, your developers can create an IoT product without relying on exclusive and hard-to-find talent.

Think about it from a macro perspective – western countries are all trying to increase efficiency, reduce environmental impact, and care for a large aging population. But developed countries are still the minority - the rest of the world doesn’t have basic services or our standard of living. Our resources are limited if we want to bring the entire world up to our living standards. The only way to solve these big problems is with technology. I think IoT can grow core technologies to do so much more. But in order for this to happen, IoT needs to be available to all companies, not just experts.

What exactly does the horizontal layer include?

We host an infrastructure for customers that can be replicated and takes care of access control and gets data to the right place. Our vertical communication layer is a software library that designers place on top of their protocol layers and hardware. By using our software library, designers don’t have to think about cloud APIs, Internet connectivity, etc.

We are giving designers the opportunity to create something fast without thinking much about what technology to use. Designers can create a prototype on their hardware and focus entirely on the benefit and business value of the device up front, worrying about technology and scaling requirements much later on in the process. Designers have the freedom to stretch the product further without having to rewrite the apps and alter the code.

Have you started selling the product?

Right now we’re doing small pilot and proof of concept projects. We also have additional funding from angel investors and government grants. We’re still in the development phase and we want to make sure we’re building the right product. Our pilot projects are giving us critical insights. Our goal is to increase the number of devices using DeviceRadio by 10-fold every six months.

What are some of the design challenges you have run into while building the product?

From a technical standpoint, there were plenty of challenges. But the biggest challenge I have seen is an awareness problem - getting the right awareness and feedback circulating among companies about IoT. There is so much hype and confusion because everyone wants to be a part of IoT. But the companies that can benefit the most don’t really know it exists and what the benefits are – I think that’s a big challenge.

So they don’t understand what’s possible?

Exactly, a lot of the IoT media attention is around must-have killer applications solving luxury problems, such as connecting a water bottle or something. One of the companies I spoke with recently is building drones that work with emergency services to deliver heart defibrillators in a fraction of the time they were previously delivered, using IoT to save lives.

What Silicon Labs products are you using?

The Silicon Labs Blue Gecko BGM123, but we also use your 8-bit processors.

Where do you see the future of IoT going in the next 5-8 years?

Even though there are some cool IoT start-ups and things happening, it’s really going to be about existing companies discovering how to leverage IoT in a way that’s seamless. If you’re building connected washing machines, it should work as a normal washing machine, but then have additional connected features or benefits. It needs to be a gradient, where we move from unconnected to a connected world, and eventually an interconnected one. Right now it’s vertical. The same company that builds the IoT product owns the servers, apps, etc., making everything isolated. In 5-10 years, you’ll have multiple companies building the hardware, IoT enablement technologies, and software services and apps, allowing people to utilize products from multiple companies in ways we can’t even imagine at the moment.

Silicon Labs recently had the opportunity to sit down with Andrea Perdomo to discuss the personal safety company she co-founded, Revolar. Perdomo, who immigrated to the U.S. from Colombia as a child, shares her personal inspiration behind the product and explains some of the design challenges she experienced launching a simple yet powerful IoT technology that alerts loved ones if the user is in danger.

Can you tell us a little bit about your company Revolar?

Revolar is a personal safety technology company. We created a small device that you clip onto your clothing, key chain, handbag, etc. The device is for those moments where you just need to connect with your loved one. The device is connected to your phone via Bluetooth. There are three different alert levels. The first is a “hey, I’m home or I’m safe” alert. Two clicks is a yellow alert, which is for when you are uncomfortable or just want someone to be with you virtually. And the third alert is for full blown emergencies. We launched our first product in 2015 and launched the new version in April of this year.

What prompted you to create the technology and the company?

My co-founder, Jackie Ros, and I were close friends before we started the company together. Jackie’s younger sister was the ultimate inspiration for Revolar. Her sister was assaulted twice by the age of 17. In both circumstances, her sister didn’t have time to reach for her phone and call for help. Jackie wanted to create a magic button that her sister could press that would let people know where she was and that she needed help. And that’s pretty much what we did. We realized nothing like this existed yet. There were products such as Life Alert and 24/7 trackers for your kids, but nothing in the middle. We had no technology background at all, but we figured out how to do it.

I’m originally from Colombia and I moved to the U.S. for safety and security reasons after my grandmother was kidnapped for eight months. She’s OK now, but if she would have had Revolar, we would have known her last whereabouts and known something was wrong. Then we could have started looking sooner. Instead, we went a whole month without knowing where she was.

What were the circumstances? Was she held for ransom?

Yes, ransom. It was back in the 90s – everybody was getting kidnapped left and right. And my Dad said, “This is it, we can’t live here anymore.” So I’ve been surrounded by the mentality of “stay safe” or “don’t talk to strangers.” Moving to the U.S., it’s definitely safer here. But at the same time, Revolar is for those moments where you just can’t predict it. We started Revolar in Denver – just the two of us – and we slowly grew our team. I went to business school and I’ve always said you don’t know how to start your own business until you do it. We eventually figured it out and found a team of advisors and investors who believed in what we were doing.

What kind of stories and feedback have you received from the users?

We have learned that our customer base is broad – we have male and female users from every age group above 13 years old. So customization of the experience is important. Not everybody is the same – a red alert for one person might be totally different for someone who has food allergies versus someone who is a runner. So we started enhancing our software.  Now users can customize messages and change contacts for each alert level. We also learned that people were using Revolar just on the weekends or when they thought something would happen. So in our new version we created ways people can use the device regularly and not just when they need it. For example, the new version will beep so you can find your keys or phone. We also activated step-tracking for active users who want to use Revolar to count steps.

That’s great you’re learning how people are really using it.

Interestingly enough, people are using it for reasons that I never thought of. I kid you not, I know people are using it to let friends know what bar they’re at. Or if they go on a hike, they use it to show people what hike they went on. Or they take check-ins while they are shopping to remember where they were.

Is there a way to aggregate the data about where people of certain ages congregate or use their devices most frequently?

When we talk to police or governing bodies of cities or universities, we always get that question. They say, “You’re telling me that we will know when people are feeling vulnerable or uncomfortable?” A perfect example is if we’re getting a bunch of yellow or red alerts from a certain fraternity at a college campus. We know a lot of this information is sensitive and personal to our customers and we want to respect everyone’s privacy. But at the same time, if we can get our users to let us know why they are using Revolar, we can help people in the future.

Can you tell us about the process of building the device?

Our proof of concept was built by an engineer we contracted with in Colorado. Within three months, we had a functioning prototype. It was jankie and we had to unplug it to set off the alert. We also had to convert our phones to Androids because that was the only way to build the app.  We later brought on an advisor who was both an electrical and a mechanical engineer. In two weeks, he built the prototype we ended up using in the first version of our product. We then found an industrial designer to contract for us and that part was fun – making sure the design was pretty. Once we started the manufacturing process, our contract manufacturer brought on the CTO and started putting all of the pieces together.

Was the design of the product a challenge since it hadn’t been done before? Or was it a process smooth?

Oh, no. It was really hard. I remember every engineer I talked to said “Oh, that’s easy, we can do that.” But then there was always something. One of the challenges was size. The battery life was another challenge. And the button, making sure the button was concave enough to remove the risk of false alerts. And features – there were so many features we wanted, but we couldn’t compromise the size or battery life. Initially, we thought it would be a great idea to have four buttons. Then we learned how much it would cost and how much it would drain the battery. Most of the Bluetooth chips that existed at the time powered cell phones or sent  messages with high-bandwidth, and we didn’t need all of that. We ended up going with Bluetooth Low Energy because everything else would have taken longer to make. It took us over a year to have the final product.

What specific Silicon Labs products are in the device?

The Wireless Blue Gecko SoC. The product helped us achieve a longer battery life and create our small form factor.

Where do you see IoT going in the next 5-8 years?

I think we’re going to start seeing  people consolidate IoT. Especially as we hear people say they don’t want to charge another thing – they want devices to do multiple things. Most people have no idea what IoT means – I’d say 80 percent of the world or more. I still run across people who don’t know what Bluetooth is – or what a wearable is. So although technology is moving fast, there is still a big gap in education. I also think we’ll see wearables and IoT in places that you would never imagine, such as clothing and handbags. I believe tech will become fashion. Probably not in the next 5-8 years, but in the next 20.

A collection of Bluetooth vulnerabilities named “BlueBorne” has just been made public by the security research company Armis. The vulnerabilities are not in the Bluetooth standard itself, but rather in the specific implementations of the Bluetooth standard. The Silicon Labs Bluetooth implementation is different from the affected implementations. Therefore, products based on our Bluetooth software are immune to BlueBorne.

This has been disclosed responsibly, which means that vendors have had time to issue security patches. Therefore, please update and patch all Bluetooth-products based on Android, Windows, iOS or Linux! And if in doubt, follow best practice and update all smart products regardless of protocol and software platform.

As a note, fighting BlueBorne shows the importance of being able to software upgrade connected devices, as discussed here:

http://www.newelectronics.co.uk/electronics-technology/the-iot-requires-upgradable-security/156211/

References:

https://www.armis.com/blueborne/

https://www.wired.com/story/turn-off-bluetooth-security/

https://techcrunch.com/2017/09/12/new-bluetooth-vulnerability-can-hack-a-phone-in-ten-seconds/