In a 45-minute webinar, Jean Labrosse explains everything you need to know about an RTOS. An RTOS is software that manages time and resources of a CPU. RTOSs are practically used in almost every embedded and IoT system.

Click here to register: https://attendee.gotowebinar.com/register/3924613694856300300?source=SiLab

About Jean Labrosse: 

Jean Labrosse is a software architect at Silicon Labs. Labrosse, an RTOS expert who founded Micrium in 1999, is a regular speaker and panelist at the Embedded Systems Conference in Boston and Silicon Valley, and other industry conferences. He is the author of three definitive books and many blogs and articles on embedded design. He holds BSEE and MSEE degrees from the University of Sherbrooke, Quebec, Canada.

Earlier this year, we spoke with Ryan Kincaid, an Allegion global hardware architect, who focuses on connectivity and the security of embedded systems. Allegion is a long-standing and trusted brand in mechanical security, with a 100 + year history of building locks and entry systems for residential and commercial buildings. With more than 30 brands in 130 countries, Allegion has been specializing in security since long before electronics of any kind even existed.

True to its pioneering roots, Allegion sees tremendous opportunity in IoT to create even more value within its product portfolio. Over the past few years, the company has been working closely with Silicon Labs to add connectivity to a broad spectrum of smart home and commercial security products in its portfolio.

In the blog below, Ryan shares insight behind some of these new products and use cases for access control technology, including enabling features like granting delivery personnel access into homes without the need for the homeowner to be on-site.

Tell me a little bit about Allegion.

Many people are familiar with Allegion’s brands without even knowing it. For example, if you look at your key chain, there’s probably a key that says Schlage on it, which is one of our core U.S. brands. Schlage can also be found on exterior and interior locks in your house. When you walk through an entry way of a commercial building, people often push our Von Duprin exit devices to open the door (that’s the bar running across the door) or use a credential reader to gain access. Many people first think of these brands as mechanical, but what is happening in the industry is a migration of electrifying mechanical devices. We are adding in connectivity, sensor technologies, and fairly high-end embedded security to make them intelligent.

Can you tell me about how Allegion is working with Silicon Labs?

We use Silicon Labs in a variety of different products, especially related to connectivity and our connected home solutions. We started using Silicon Labs’ technology through the acquisition of BlueGiga and quickly saw the benefit of the support Silicon Labs provided. We have gone on to leverage products like the Silicon Labs Mighty Gecko SoC and others over time. For example, we recently worked with Silicon Labs to develop a Zigbee-certified smart home lock, a solution great for people who want in-home delivery. A homeowner can grant access to a third-party, such as Amazon, and allow that delivery service access on a limited basis to that person’s door (which can also be paired up with a camera). When the delivery person arrives at the home, he or she can unlock the home and lock on their way out.

Another product we launched recently is a networked version of an exit device that allows remote monitoring and access control in commercial settings. This product utilizes the Blue Gecko SoC and is targeted specifically at the K-12 educational vertical. We call it a safe school application, as it enhances perimeter security by providing electronic override of mechanical solutions for an emergency facility lockdown. This product can be invaluable to school administrators as prior to this type of technology, a human would have to go around to every single access point and ensure it was securely locked.

What are some of the major product design challenges you typically run into?

Time to market is always a challenge. We have found Silicon Labs’ offering of both SoC and pre-certified module (FCC certified modules) solutions especially valuable to us. The pre-certified modules accelerate our time to market because we can circumvent some of the compliance and certification processes. For example, the Zigbee product I mentioned earlier was not a new technology to the industry, but it was new for our product line, and being able to use the tools and certification support Silicon Labs provided really sped up our product delivery. One of our other largest challenges is decreasing our time to market while maintaining our high standards for safety and security.

How important is security and how do you see security evolving with IoT?

Security is priority number one – there is no question about that. For example, at schools, connected devices allow for fast and safe lockdowns. At home, you can get an alert when your child arrives home from school and enters the door, allow temporary access to a visitor, and verify that the door is locked before you turn out the lights.

Our reputation is built on security, so when it comes to adding electronics to mechanical solutions, our security mindset comes with us. We have added roles within the company that specifically focus on cybersecurity. When we look to products that we’re using within our embedded system, we’re constantly refreshing our security requirements around those pieces. This includes enabling security updates in the field. When we look for silicon or firmware partners, security is always the first thing we review.

One of the things we want consumers to be mindful of is the market is full of products touting home security, but some of these are companies don’t necessarily have the history or track record that we do.

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

I think consumers are becoming more and more aware of security. They might not know all of the encryption standards and data privacy laws, but they’re getting to the point where they are asking sophisticated security questions, and people developing IoT products need to meet these new demands. This will drive new security standards, data storage requirements and computing at the edge.

There will be an increase in consumers questioning a product’s digital longevity. How long will this be supported? Will I continue to receive updates? Will the pricing model change? To be successful in the IoT market for the long run, manufacturers must have scalability and sustainability product plans in place before delivering each and every IoT device to market.

Finally, we will see a demand for a better user experience in IoT. Devices need to be easily commissioned and seamlessly work within the intended ecosystem. This could include sharing data with a smart devices or cloud services. Products constantly need to be checked for compatibility due to the rapid change in these technologies. Products genuinely need to address customer needs without becoming an annoyance. 

We’re excited to introduce the next generation of our Wireless Gecko platform, Series 2, which has been engineered to make IoT products more reliable, efficient, and powerful.

Developing IoT applications comes with its own set of challenges, including significant storage, power, battery life, and cost constraints. Building on the versatility of the Gecko platform, Series 2 is optimized for the most popular IoT protocols, including Zigbee, Thread, Bluetooth, Z-Wave, and Wi-Fi. It features high-performance wireless radios that deliver up to 2.5X the wireless range of competing solutions and includes a dedicated security core.

RF communications are also more dependable and energy efficient due to the highly integrated SoC options and feature-rich wireless stacks. Developers are able to optimize system cost and performance with Series 2 for a wide range of smart home, commercial and industrial IoT applications.

Developers are increasingly searching for flexible solutions to meet the demands of diverse IoT devices, and Series 2 provides a much-needed path forward for developers to bring differentiated products to market faster while reducing cost and overall design complexity.

Supporting Zigbee, Thread, Bluetooth LE and Bluetooth mesh, the initial Series 2 SoCs are the ideal wireless solution for line-powered IoT gateways, hubs, lights, smart speakers, and smart electric meters.

Key features include:

• Best-in-class RF performance with +20 dBm output power and up to +124.5 dB link budget
• Robust wireless radio with improved blocking performance
• Powerful processing with an 80 MHz Arm® Cortex®-M33 core with TrustZone technology
• Low active current (50.9 µA/MHz) to meet stringent green energy requirements, a benefit from manufacturing on low-power 40 nm process technology
• Industry’s smallest multiprotocol SoCs in a 4 mm x 4 mm QFN package

Secure by Design

EFR32xG21 SoCs provide enhanced security features that enable developers to implement robust security in connected products:

• A dedicated security core enables faster, lower-power encryption than software techniques.
• A true random number generator strengthens device cryptography.
• Secure boot loading ensures authenticity of firmware images and over-the-air updates.
• Secure debug access control helps OEMs prevent unauthorized access to end products.

A Single Mesh Development Kit

The EFR32xG21 Wireless Gecko Starter Kit (SLWSTK6006A) includes everything you need to create a mesh network and evaluate the EFR32xG21 Series 2 Wireless Gecko SoCs. There’s a single kit for Bluetooth LE, Bluetooth mesh, Zigbee and Thread development, consisting of:

• 3 x WSTK main boards
• 3 x Wireless Gecko + 10 dBm radio boards
• 3 x Wireless Gecko +20 dBm radio boards

Learn more at silabs.com/series-2

This blog should serve as a guide to adding Micrium OS File System(NOR device) on a Flex Gecko and get at least the FS core initialized, perform low/high-level if the Storage device requires it and execute a simple read/write application.

I will now share with you my experience while going through this exercise.

Getting Started

I decided to perform a clean installation of Simplicity Studio in order to avoid conflicts inflicted by software updates over time. After installing the tool, before even attempting to add anything, I first had to make sure that I had the necessary SDKs. Here's what I installed:

• Gecko SDK Suite - 2.5.3
• Micrium OS - 5.6.0
• Flex SDK - 2.5.3.0

I then mounted a Flex Gecko, EFR32FG13(BRD4255A) in my case, onto a Wireless Started Kit Mainboard (BRD4001A). After that, I connected it to the PC using the provided USB cable.

Simplicity Studio recognized a Flex Gecko connected to a WSTK and displayed the link to examples from the Flex SDK (see Figure 1).

Figure 1 - Initial Setup Validation

Loading a Basic Flex SDK Example

As a starting point, I decided to go with the "Connect(Soc): Sensor" example from the Flex SDK.

You can find this by expanding the list of projects under the "Connect Examples" link:

Figure 2 - Flex SDK Examples Link

You will then be presented with sensor.isc opened where you can configure Sensor. Since we are adding Micrium OS to the example, let's click on the "Plugins" tab and select the "Micrium RTOS" check box and "Application Task (1)" as shown on Figure 3. Make sure to press 'CRTL + S' to save the modifications and then clicked on "Generate".

Figure 3 - Sensor Project Configuration

Click the 'OK' button on the Generation validation pop-up window.

Figure 4 - Generation validation

At this point, you should now be set with a Flex Gecko example that builds and runs. However, I did find that the default project settings have compiler optimization set to "Optimize for size (-Os)" which will eventually make debugging the project rather difficult. Therefore, I switched optimizations to "None (-O0)".

Figure 5 - Compiler Optimizations

Installing Micrium OS File System

Assuming your credentials have the right access permissions to install Micrium OS File System, you will need to click on the 'Help->Update Software' menu. The "Installation Manager" window should pop-up. Please select the "Package Manager" option as shown on Figure 6. If you are not sure your credentials have the proper access to Micrium OS File System, please contact our sales department.

Figure 6 - Installation Manager

On the "Package Manager" window select the 'SDKs' tab and Micrium OS as Categories, then click on the 'Install' button Figure 7. Close the window once the installation is completed.

Figure 7 - Package Manager

Adding Micrium OS File System to the Workspace

The BRD4255A board has a 8-Mbit Macronix MX25R8035F SPI flash; therefore, our workspace will have all the Micrium OS File System files required to run the NOR(MX25R8035F) device. Since we already generated a Flex Gecko example that builds and runs, let's go ahead and start adding the Micrium OS File System source files into the workspace. First, locate the Micrium OS directory, it should be in:

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.5\platform\micrium_os

Right-click on the 'sensor' workspace and select 'Import->MCU project'.  Once the "Import Project" window pops-up, please select the 'More Import Options" as shown on Figure 8.

Figure 8 - Import Project

During the next window, select the "General->File System" import source and click next. At this point, we will be adding all the necessary Micrium OS File System files to the workspace.

Figure 9 - BSP file for the NOR-SPI device.

Figure 10 Micrium OS common files

Figure 11 Micrium OS drivers for NOR-SPI

Figure 12 Micrium OS File System

Adding Micrium OS FS Examples to the Workspace

Locate the Micrium OS examples directory, it should be in:

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.5\app\micrium_os_example

Make a copy of the "micrium_os_example" folder and place it in the directory where the sensor example was generated. In my case the sensor example workspace was generated at:

C:\Users\UserName\SimplicityStudio\v4_workspace\sensor

Once you place the folder in the sensor directory, make sure to delete the following folders and file:

canopen
common
cpu
io
kernel
net
uC-Probe
usb
ex_main.c

In addition, we need to add the following include path to the project

"${workspace_loc:/${ProjName}/micrium_os_example}"

Configuring Micrium OS  and File System

Now that you have Micrium OS and File System as part of your project, let's go ahead and make some minor adjustments to the default Micrium OS configuration. Start by expanding the Includes section in the Project Explorer panel, then expand the "protocol/flex/connect/plugins/micrium-rtos/config" folder as shown in Figure 13 and 14. The files we will be modifying are "common_cfg.h", "os_cfg.h", and "rtos_description", so please double-click on those to open it in the editor.

Figure 13 Project Explorer Sensor Includes section

Figure 14 Micrium OS configurations.

Let's start by modifying "rtos_description.h" by adding the following File System defines:

/*
 *********************************************************************************************************
 *********************************************************************************************************
 *                                       RTOS MODULES DESCRIPTION
 *********************************************************************************************************
 *********************************************************************************************************
 */

#define  RTOS_MODULE_KERNEL_AVAIL

                                                                /* ------------------- FILE SYSTEM -------------------- */
#define  RTOS_MODULE_FS_AVAIL
#define  RTOS_MODULE_FS_STORAGE_NOR_AVAIL

As soon as you try to edit the "rtos_description.h", you will be presented a Warning indicating you are editing an SDK file. Click on "Make a Copy", and choose the same option when modifying "common_cfg.h" and "os_cfg.h".

Figure 15 Warning

Modify the following defines in "os_cfg.h" file

#define  OS_CFG_MON_EN         DEF_ENABLED
#define  OS_CFG_TASK_Q_EN      DEF_ENABLED

Modify the following defines in "common_cfg.h" file

#define  LIB_MEM_CFG_STD_C_LIB_EN              DEF_DISABLED
#define  LIB_MEM_CFG_HEAP_SIZE                 32768uL

The value of LIB_MEM_CFG_HEAP_SIZE  is used by the FS stack and examples so the value will depend on your application.

It is time to add the File system configurations by locating the configuration templates at:

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.5\platform\micrium_os\cfg

Make a copy of "fs_core_cfg.h" and "fs_storage_cfg.h" and place them in the external_copied_files folder in your sensor directory. In my case the location was at:

C:\Users\UserName\SimplicityStudio\v4_workspace\sensor\external_copied_files

Open "fs_storage_cfg.h" and modify the following

#define  FS_STORAGE_CFG_MEDIA_POLL_TASK_EN                  DEF_DISABLED

Initialize Micrium OS File System and Simple Demo.

The micrium_os_example folder provides examples for initializing the File System and executing a simple Read/Write demo; therefore, let's make additional modifications to the project,which will allow us to run FS and simple demo.

In the Project Explorer, locate the micrium_os_example folder and open ex_description.h. Add the following define:

/********************************************************************************************************
 ********************************************************************************************************
 *                                         EXAMPLES DESCRIPTION
 ********************************************************************************************************
 *******************************************************************************************************/

#define  EX_FS_INIT_AVAIL

Open ex_fs.c located at micrium_os_example/fs and modify the following defines.

#define  EX_CFG_FS_MEDIA_LOW_LEVEL_FMT_EN       DEF_ENABLED
#define  EX_CFG_FS_MEDIA_HIGH_LEVEL_FMT_EN      DEF_ENABLED

#define  EX_FS_MEM_SEG_LEN                      (1u * 1024u) 

We are modifying EX_FS_MEM_SEG_LEN due to memory reasons; however, the original value should be enough to run most of the examples.

Open ex_fs_file_rd_wr.c located at micrium_os_example/fs and modify the following function call in Ex_FS_FileRdWr()

  Ex_FS_FileRdWr_Exec(vol_handle,
                      "file-rdwr.txt",
                      512u,                                    // File size.
                      &err);

At this point, we are ready to modify the flex-callbacks.c file and add the FS initialization and demo. Please open the file and modify the emberAfPluginMicriumRtosAppTask1MainLoopCallback() function as shown below as well as the includes.

Figure 17 - flex-callbacks.c file

We need to add one minor modification to bsp_fs_nor_spi.c, so please open the file (Figure16).

Figure 16 BSP for FS-NOR_SPI

Modify bsp_fs_nor_spi.c dependencies section as shown below, but keep in mind that as soon as you try to edit the it, you will be presented a Warning indicating you are editing an SDK file. Click on "Make a Copy"

Figure 18 - bsp_fs_nor_spi.c file

The bsp_fs_nor_spi.c file is very important, since it will be here that you will need to modify SPI pin configurations for the specific NOR device on your board. For the BRD4255A board you do not need to do anything else since all the pin configurations have been implemented; however, if you are using a different board then make sure your schematics match the PIN configurations on this file.

At this point you should be able to compile and flash the board. The example is very simple, the FS performs a low/high level format on the NOR storage device, then it opens a file and does a write/read operation. As soon as it is done, you should see LED0 blinking on the board. Keep in mind the low/high level format takes a few seconds to complete.

Introduction

When it comes to IoT device management, over-the-air (OTA) firmware updates play a key role.

OTA enables product manufacturers to remotely update connected devices with bug fixes, feature enhancements and security patches.

If you are evaluating one of our EFM32 32-bit MCUs such as the one onboard the Giant Gecko GG11 Starter Kit (SLSTK3701A) and want to learn a simple way to enable OTA firmware updates then this blog will get you started by presenting the example illustrated in the following diagram:

• Figure 1-(1): The embedded application acts as an HTTP-client and will connect to your web server to send a GET request to download a firmware update file (myupgrade.gbl). 
• Figure 1-(2): Your server responds with the firmware update file (myupgrade.gbl)
• Figure 1-(3): Once the file myupgrade.gbl is downloaded, the embedded application will store it by using the bootloader interface API to reprogram the bootloader storage area.
• Figure 1-(4): The embedded application will use the bootloader interface API to validate the firmware update image and upgrade the current application.

There are several criteria for the firmware update image to be flashed:

• The file myupgrade.gbl needs to be valid. This is checked by the embedded application using the bootloader interface API. 
• The embedded application checks the version of the firmware update image stored in myupgrade.gbl. If the version of the embedded application is the same or older than the running application, the image file will not be flashed.

The bootloader storage area will be erased, and the embedded application will try to establish a new HTTP/HTTPS connection, if:

• The loaded file is not a valid .gbl image.
• The version of the image stored is the same or older than the running version.
• Anything goes wrong with the HTTP/HTTPS protocol.

Hardware Requirements

• EFM32 Giant Gecko GG11 Starter Kit SLSTK3701A
• Web Server to host the firmware update file

Software Requirements

• Simplicity Studio
• 32-bit MCU SDK
• Micrium OS Kernel
• Micrium OS Network

Getting Started

1. Order an EFM32 Giant Gecko GG11 Starter Kit SLSTK3701A from our website

2. Install Simplicity Studio

• Download and Install the latest version of Simplicity Studio from our website at: http://www.silabs.com/simplicity-studio
• Download the software and follow the installation instructions.
• When asked to sign-in, enter your Silicon Labs username and password. Sign up for a new account if you don’t already have one. This is required to gain access to all of the software components.
• After signing in, register your kit with Simplicity Studio. If the kit is not registered, Simplicity Studio will only enable access to the Micrium Kernel; however, if the kit is registered, Simplicity Studio will enable access to all the other applicable Micrium components as well. The license number is on the box of the kit.

3. Connect the board as shown in the image below:

4. Open Simplicity Studio, from the Launcher perspective, select the example named SLSTK3701A_micriumos_httpcloader as shown below:

5. Open the file httpclient.c located in the /src folder in the Project Explorer and enter the full URL where you plan to host the firmware upgrade image:

#define  FULL_URL   "http://mywebserver.com/myupgrade.gbl"

If your webserver is secured (i.e. https) then this demo includes mbedTLS. Simply make sure that the certificate required by your website is defined in SSL_ROOT_CA[] in the file ssl_certificates.c located in the /src folder of the Project Explorer.

You may also have to tweak the number of bits and bytes that match your website's certificates by setting the proper sizes in MBEDTLS_ECP_MAX_BITS and MBEDTLS_MPI_MAX_SIZE in the configuration file config-ssl-
httpcloader.h located in C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.5\app\mcu_example\SLSTK3701A_EFM32GG11\micriumos_httpcloader\config-ssl-httpcloader.h

#define MBEDTLS_MPI_MAX_SIZE   256
#define MBEDTLS_ECP_MAX_BITS   384

6. Open the file application_properties.c in the /src folder of the Project Explorer and set the version number of the embedded application to 2 to simulate a firmware upgrade:

#define APP_PROPERTIES_VERSION 2

7. Build the project

8. Generate the firmware upgrade file myupgrade.gbl by opening the utility Simplicity Commander located at C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\commander and by providing the path to your binary file .s37 to a command line similar to this:

commander.exe gbl create myupgrade.gbl --app "C:\Users\[YourUsername]\SimplicityStudio\v4_workspace\SLSTK3701A_micriumos_httpcloader\GNU ARM v7.2.1 - Debug\SLSTK3701A_micriumos_httpcloader.s37"

9. Upload the file myupgrade.gbl to your web server

10. Open the file application_properties.c in the /src folder of the Project Explorer and set the version number of the embedded application back to 1:

#define APP_PROPERTIES_VERSION 1

11. Build the project again

12. Connect the starter kit as previously shown in Figure 2

13. Open Device Manager in Windows to find out the COM Port number of the USB device listed as J-Link CDC UART Port

14. Open a Serial Console application such as PuTTY to see the debug messages during run time

15. Select the item J-Link Silicon Labs from the list of Debug Adapters, right-click to open the context menu and select the option Upload Application... as shown below:

16. In the field Application Image Path, select the file SLSTK3701A_micriumos_httpcloader.s37 that you just built by browsing to the workspace folder where you have your project, a path similar to the following:

C:\Users\[YourUsername]\SimplicityStudio\v4_workspace\SLSTK3701A_micriumos_httpcloader\GNU ARM v7.2.1 - Debug\SLSTK3701A_micriumos_httpcloader.s37

Tick the checkbox to Upload a Bootloader image and select the bootloader that comes with the example by browsing to the file bootloader-storage-internal-single-combined.s37 in a path similar to this:

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.5\app\mcu_example\SLSTK3701A_EFM32GG11\micriumos_httpcloader\bootloader-storage-internal-single-combined.s37

17. Press the button Ok to flash both images. The bootloader image will be flashed in a reserved area of Flash and from this point forward you can simply Launch a Debug Session from Simplicity Studio to program the device with a different application image as the bootloader image will be stored in a reserved area of Flash that won't be deleted unless you overwrite it with this tool or from the command line with Simplicity Commander.

18. Watch the serial terminal as the embedded application starts the Ethernet interface, connects to your website to download the file myupgrade.gbl and reboots on the new upgraded embedded application. 

Further Reading

The firmware update situation described in this example assume no authentication and no encryption of the firmware update file. However, these features along with secure boot are supported by our system but it is beyond the scope of this blog.

To sign and encrypt a firmware update file, you can use Simplicity Commander as follows:

commander.exe gbl create --app --bootloader --metadata --compress --encrypt --sign --force

For more information on how to use Simplicity Commander see the section GBL Commands on Page 34 of the following document: 

• UG162: Simplicity Commander Reference Guide: 

https://www.silabs.com/documents/public/user-guides/ug162-simplicity-commander-reference-guide.pdf

For more information on the Gecko Bootloader see the following documents: 

• UG266: Gecko Bootloader User's Guide:

https://www.silabs.com/documents/public/user-guides/ug266-gecko-bootloader-user-guide.pdf

• UG103.6: Bootloader Fundamentals:

https://www.silabs.com/documents/public/user-guides/ug103-06-fundamentals-bootloading.pdf

We recently had the opportunity to sit down with the CTO and co-founder of Notion, Ryan Margoles to talk about the release of their Gen 3 sensors and how the IoT will impact homeowners in ways that go beyond just convenience. 

Tell us about the history of Notion. What was the impetus for starting the company and what were the immediate challenges?

The idea for Notion was literally sparked by a sounding alarm in the middle of the night. My wife and I had just adopted a puppy and our carbon monoxide alarm went off at 2am; it was a pretty jarring experience. We jumped out of bed and opened all the windows and exited the house. Fortunately, it was only the furnace fizzling out. The next day, I called my business partner and childhood friend, Brett, with the idea to make a Wi-Fi connected smoke/carbon monoxide alarm. We set out to learn more about the value proposition of a smart smoke alarm, and how we could make it valuable for customers. We learned quickly that people loved the use case, but were not used to buying smoke or CO2 alarms; they are usually already installed in the apartment or in the home you buy. The product evolved and coalesced into a concept of a single sensor that could do multiple things: listen for smoke/CO2 alarms, detect movement, doors and windows opening/closing, freezing temperature, and leak detection. The competition offered several single-function sensors: a door sensor, a temperature sensor or a leak sensor. In our opinion, this was a barrier to entry for people who aren’t as tech savvy. We knew we had found the right idea to pursue.

What is your background?

I have a mechanical engineering degree from the University of Colorado. My background is in product development, manufacturing and big data. I spent most of my early career with Titleist and Callaway developing smart golf clubs.

When you set out to do this, size and battery power were obvious considerations. What were some other known design challenges?

There were three challenges on the onset: 1.) Battery usage: Battery power and replacing batteries every three months is tough for a customer to get used to; it’s a hassle. Our Gen 1 kit had a coin-cell battery that was difficult to swap out. We learned over time that just two AAA alkaline batteries were important since they are readily available and easy to change out. 2.) Ingress protection: Devices that are placed outside, in really cold environments or used for water leaks need to limit the amount of water that gets into the devices. 3.) Simple user

experience: it was a challenge to design a simple user setup. One of the areas of opportunity was the pairing process. With most smart devices, you have to go through a pairing process. We identified that as a pain point for users so we developed our own protocol for pairing devices. Our goal is ease-of use. Every device is the same. It detects all five “senses” and device tasks are 100% configurable in the Notion smartphone app.

How did Silicon Labs become part of Notion?

First and foremost, the account management team at Silicon Labs is easy to work with. We were able to get the answers we needed to make important decisions and the team availed themselves to all-levels of the Notion organization, from executives to hardware engineers. Second, the Gecko platform allows us to configure specific protocols and free our team to focus on other things. Previously, the Notion team developed everything – from OTA update mechanisms to the security protocols. It was very labor intensive. Silicon Labs helped alleviate much of this burden. Third, the Silicon Labs team spent the time building rapport and working with us on a pricing model that worked for our start-up.

What’s been the market’s response to Notion?

Overwhelmingly positive. It’s the best multi-functional sensor on the market with its simple 15-minutes-or-less set up, increased range, and long battery life. Our channel strategy includes not only B2C, but also B2B; we are partnered with several of the top insurance companies in the U.S. Similar to car sensors that help lower your insurance premiums for good driving, we’ve pursued a similar path for home ownership. Now a homeowner or renter can augment their monthly premium by installing Notion. Additionally, we’re the first IoT company to have

a partnership with HomeAdvisor. So, if you have a water leak, we not only detect it, but we can connect you with an available plumber in your area within 30 seconds.

What do you see is the vision for the future of Notion, and the IoT in general?

We believe the services extension of IoT is changing what it means to have a smart home. Being a homeowner is hard and our mission is to help you take care of your home. We have a 10-year goal of making Notion a requirement to obtain property insurance -- that’s how powerful we think our product and data is. We partnered with one of our insurance partners, Hippo, to be the first fully-integrated smart insurance product on the market. Every customer who buys Hippo insurance receives a Notion starter kit for free. Once the customer sets up their

Notion system, they get an exclusive discount on their premium. We’re driving insurance to make a change while adding thoughtful services to the Notion brand to help homeowners take care of and secure their home.

The most successful loT products make Bluetooth and Wi-Fi connectivity easy for end customers to set up and use. The lack of time and resources in companies with limited in-house wireless design expertise can lead to slipped delivery schedules and multiple product re-designs.

There are four typical stages of the wireless development process:

1. Software/firmware development
2. Hardware design and certification
3. Mobile applications development
4. Cloud connectivity

The development process can take up to a year to complete. Let’s discuss and highlight the unique challenges presented in each development stage.

Software/Firmware Development

In the firmware development stage, developers using unprogrammed modules must become experts in Bluetooth communication or Wi-Fi protocols and vendor-specific software stacks. In traditional Bluetooth and Wi-Fi design, developers must create an embedded host + network co-processor design with a communication link that operates at a low level controlling the network co-processor. Half of the development work includes writing firmware code and the other half is spent on testing.

Hardware Design

Choosing the right hardware is a critical piece of wireless functionality and the integrity of system design. Using unprogrammed modules to add wireless connectivity to their products poses a variety of problems including potential delays, antenna design issues, and RF certification hurdles. FCC certification alone can cost thousands of dollars and take months of testing and validation. Good RF performance is a critical design challenge.

Mobile Applications Development

The mobile app development stage is often the most challenging for companies since many don’t have developers in house with mobile application experience. For this development stage, developers must become experts in both Android and iOS development, which means more APIs to understand. They often outsource to vendors who build the mobile infrastructure, perform testing, etc. which can be very time consuming and costly due to the difficulty in finding subject matter experts in both iOS and Android development.

Cloud Connectivity

This stage of product development is a critical one and can be challenging and prone to errors and potential launch delays that affect the success of the loT applications. Getting and maintaining reliable cloud connectivity and properly collecting data are huge concerns in loT applications today. It’s almost impossible for companies, especially small ones, to develop a cloud-connected framework/infrastructure from scratch. Developers also often have problems with unreliable links and connectivity and they might also be restricted by the MCU. Having reliable connectivity links is a critical piece of product longevity and customer satisfaction. Firmware updates are also an important part of product maintenance and are usually outsourced by companies. Using an integrated solution that already has the infrastructure for adding cloud connectivity can save developers months of framework development.

Benefits of Pre-Programmed Wireless Modules

loT developers today want robust functionality in the smallest footprint possible and they want solutions that support easy Wi-Fi and Bluetooth connectivity. Leveraging integrated modules that already include pre-programmed firmware, pre-certified RF and hardware, easy mobile app framework, and cloud connectivity, streamlines the development process and takes the guesswork out of successful connectivity.

Key Points to Consider

• Select a product with functional and tested system firmware that’s pre-programmed at manufacturing
• Use a model instead of designing with SoC
• Start mobile app development with a wireless interfacing library that’s been optimized for ease of use
• Connect to cloud infrastructure already in place as part of an integrated product

Silicon Labs Wireless Xpress products, powered by Gecko OS, and application firmware running on pre-certified Silicon Labs modules combines these product development cycle stage optimizations to provide a streamlined embedded-to-phone and embedded-to-cloud connectivity.

Value of Gecko OS

Gecko OS is a highly-optimized loT operations system designed specifically to power hardware platforms with secure Wi-Fi networking capability and is the best choice for resource-constrained devices. Hardware running Gecko OS provides products with a powerful and secure wireless connection to a mobile device or the cloud. The Gecko OS API is a huge benefit to loT developers because it provides a common software foundation across multiple product lines.

Gecko OS products maintain much of the wireless interface without external MCU intervention, only exposing critical variables and commands for external MCU control.

To learn more about how Wireless Xpress can help IoT developers deliver ease-of-use to end customers, read the full whitepaper:

There is a huge demand today for adding Wi-Fi connectivity to IoT applications because of the many advantages over other wireless protocols (Zigbee, Bluetooth, etc.) such as longer range, native IP connectivity, and high bandwidth. For millions of IoT applications, including industrial machines and sensors, Wi-Fi is often the best choice for connectivity because of its robust infrastructure and global reach- Wi-Fi exists almost everywhere in the world today.

Challenges for developers: The biggest challenge for developers has been the high-power consumption of Wi-Fi in IoT systems. Wi-Fi protocols were designed primarily to optimize bandwidth, range, and throughput, not power consumption. This makes it a poor choice for power-constrained applications that rely on battery power. Of the various cons of using standard Wi-Fi protocols, high power consumption is the most impactful (range limitations and busy networks are cons as well). Until today, developers have avoided adding Wi-Fi to their IoT applications as there hasn’t been a viable option for adding Wi-Fi connectivity to battery operated devices that didn’t require high power consumption.

These are the four key challenges when adding Wi-Fi connectivity:

• selecting the appropriate Wi-Fi protocol for energy efficiency
• costly compared to other protocols
• more time and resources needed compared to other wireless protocols
• form factor constraints

Power consumption in Wi-Fi varies dramatically across various modes of operation and it’s important to understand the different modes and optimize them to reduce overall power consumption. One strategy is to stay in the lowest power mode as much as possible and transmit/receive data quickly when needed.

RF performance: Unlike many wireless protocols, Wi-Fi power consumption is significantly impacted by RF performance and network conditions. This is a significant problem with the increasingly crowded Wi-Fi networks today. A busy network leads to many retries/retransmissions which consumes a high level of power. Developers must focus on reducing retransmissions and controlling link budgets to be successful.

Wi-Fi devices typically consume significant power in both Transmit (Tx) and Receive (Rx) modes. There are several ways to reduce power consumption and optimize Tx and Rx modes. First choose devices with high selectivity/out of band rejection. Also, choose devices with high Rx sensitivity, and if possible, choose uncrowded channels for device operation. This might mean using channels not used by chatty connections such as video streaming.

Applications: Power consumption is highly dependent on the application and use case. IoT applications typically fall into one of three categories:

Always on/connected-these devices are always on which allows users to access the device remotely at any time via cloud or mobile application.  A Wi-Fi video camera is a good example of this use case. Latency is a critical factor in these applications and power consumption is dominated by the transmit power mode (the highest power consumption), as the device is transmitting data and it would be detrimental to be inactive or inaccessible.

Periodically connected - These devices are connected to a remote server or cloud platform and only need to transmit occasionally. A good example is a temperature or humidity sensor that sends data every few minutes and it can tolerate the small amount of time it takes to become active. Latency is not a major concern and the power consumption is dominated by receive and sleep currents. It stays in intermediate power levels so it’s never completely awake or asleep so it wakes up faster.

Event-driven - An online shopping order button is a good example of event-driven Wi-Fi connectivity. It’s almost always inactive/asleep, meaning there is no data transmission. It wakes up infrequently, and it takes longer to wake up from this mode. An event occurs that triggers wakeup such as when a user selects the order button. This mode is dominated by the lowest sleep current and is best when needing to use the least amount of power possible for an IoT application.

Design issues -  Lowering Wi-Fi power consumption is also a design system issue and is a critical challenge for developers today. Power management and extended battery life are major factors when developing IoT applications. Although standard Wi-Fi protocols weren’t designed initially for low power operations, there are many techniques to help significantly reduce power consumption. These techniques include optimizing Rx and Tx modes, optimizing power-saving modes (sleep modes, WMM, DTIM, shutdown/standby), choosing the right hardware, using built-in specifications, optimizing RF performance, and system level optimization. Developers must understand all the contributing factors to overall energy consumption in IoT devices.

They must also understand both system-level factors and deep application factors in order to achieve low energy consumption in their applications. Finding the right mix of power-saving Wi-Fi modes and selecting the right hardware are the keys to dramatically reducing power consumption. Leveraging hardware and software designed specifically for IoT devices and low power consumption can reduce long term costs, overcome development challenges, extend battery life, and potentially enhance the life of products and customer satisfaction.

We solve the power management issues for IoT developers by providing drop-in Wi-Fi solutions, including pre-programmed modules (WF200 and WGM160) that can cut power consumption in half. These solutions are designed proactively with low power IoT applications in mind and work in a wide range of applications from home automation to commercial, retail, security, and consumer health-care products. Pre-programmed modules provide a prototype quickly which helps developers get products to market faster.

To read the full whitepaper on this topic. click here:

Recently, we had the opportunity to speak with Alex Rogers, Professor of Computer Science at Oxford University. One of his recent projects exploring technology and zoology resulted in the creation of a small, low-power acoustic device built to record the songs of a potentially extinct cicada. The project began a little more than two years ago and has since morphed into a start-up called Open Acoustic Devices spinning out of the university.

The Open Acoustic device, known as the AudioMoth, is already in the hands of many ecologists and conservation organizations that are using it to track and study hard-to-detect wildlife and/or potential threats to wildlife, such as gun shots by illegal poachers or chain saws in protected forests. Previously, if ecologists or wildlife enthusiasts needed a highly sensitive audio recorder for field research, they had to pay nearly $1,000 per audio recorder. Or they could opt for an open-source recorder built from a low-cost single-board computer, which required large battery packs -- sometimes even car batteries!  The AudioMoth, on the other hand, is slightly larger than a smart phone (batteries included) and costs roughly $50.

Check out our conversation below about how a small university project scaled itself to commercialize a one-of-a-kind audio recorder for wildlife.

Tell me a little bit about yourself and how Open Acoustic Devices came about.

As a professor of computer science, my interest has been in deploying machine learning algorithms on devices constrained by computing power and battery power.

My interest in conservation technology stemmed from an event at the Zoology Dept. at Oxford, which was exploring new technology for biodiversity monitoring. The department was interested in using low-cost phones to change how people conduct environmental monitoring. With PhD student Davide Zilli, we set out to use smartphones to listen for a rare cicada insect in the U.K., which we still don’t know is extinct, hidden or just rare. The cicada sings at a very high frequency, at about 15 kilohertz, which most adults can’t hear, but smartphones can.

We didn’t find the cicada with the smartphones, but we started thinking about how we could design a small acoustic device to automatically detect the song of this insect. Two new PhD students, Andy Hill and Peter Prince, joined the project, and we ended up building a prototype device, and then made it available to others about a year ago.

We soon discovered a huge appetite for low-cost, open-source acoustic recorders. We are now working with ecologists who use our device to record bats, birds, insects and other wildlife.  Until now, professional ecologists typically had been surveying wildlife with commercial equipment.

The cost advantage of AudioMoth completely changes the science people can do. It means ecologists can do research that would have been cost-prohibitive before. Previously, if an ecologist had a small budget, they could maybe only deploy three or four recorders. Now they can potentially deploy 100 recorders, meaning different types of wildlife surveys can be conducted.

Who is your buying audience?

It’s a big mix – it’s a split equally between university researchers (ecologists) and conservation organizations. We’ve done some large bat survey deployments with the Zoological Society of London and the Bat Conservation Trust. But then there’s a whole pool of individuals and enthusiasts recording birds and bats on their own.

Can you tell me about the performance of the device?

From the beginning, we were looking to create a minimal device we could run smart algorithms on to only record when hearing a sound of interest. In the first instance, this was the New Forest cicada.

We combined an inexpensive MEMS microphone, similar to what’s inside a smartphone, with an SD card and MCU to create a programmable and highly mobile device. Because of the small size, the microphones are extremely sensitive to high frequencies -- perfect for people interested in bats, where they are recording at 100 kilohertz.

We have a lot of deployments in remote jungles and forests with extremely limited Internet access, but we are still planning to add low-power wireless connectivity to new versions of the device for alerting, streaming and research purposes.

Did you have any design challenges?

The key challenge for a battery-powered device is power -- we knew we had to focus on low power from the beginning. Our users worry most about how much data they will end up recording. We used Silicon Labs’ Wonder Gecko microcontrollers because of their low power capabilities, which results in smaller batteries and longer life in the field.

The non-commercial, open-source recorder alternative is typically based on Raspberry Pi, which uses a much more capable processor running a Linux operating system, and as a result requires a much larger battery pack. In many wildlife applications, the devices have to be carried to the deployment sites in backpacks, making the size and weight of the batteries critical.

Can you give me some idea of the power gains experienced by using the Gecko MCU?

To give an example, right now we have a deployment in Belize that involves listening for gunshots to detect illegal hunting in tropical forests. With a small battery pack (a 6V lantern battery), we can deploy a sensor that lasts for 12 months and listens continuously for 12 hours a day, only making recordings if it thinks it detected a gun shot. With the Gecko MCU, we can do nearly all the listening while the processor sleeps, then it can wake up to run the detection algorithms across a 4-second sound buffer.

How did the Gecko get on your radar?

We originally used an NXP processor and the Arm Mbed development platform in our prototype. We really liked the development platform, but the processor used too much power. Silicon Labs ended up being a better option because of the integrated tool chain, allowing us to directly measure and optimize energy consumption. We can also distribute the code, knowing that the development tools are free and are available on all operating systems, which is a critical benefit.

As a university project, how did you manufacture these devices?

To keep costs low, we started exploring alternative manufacturing routes. With Alasdair Davies of the Arribada Initiative (an organization promoting open, affordable conservation technology), we started running group purchasing campaigns through GroupGets, a low-cost assembly company that facilitates group purchasing. After testing the market with some relatively small orders, GroupGets enabled us to run off a batch of 1,500 devices from a PCB assembler, providing real economy of scale.

This model allows designers the ability to offer various types of devices, yet manufacture at a low risk. We’ve manufactured close to 4,000 devices so far and have a live campaign running at the moment that will likely result in another 1,500 orders. As a small university project, there is no way we would have been able to do without this model.

We also used CircuitHub, which enabled us to post our hardware design and bill of materials on its website. The concept essentially hacks low volume manufacturing. Suddenly, people can share and distribute hardware in the same way people have been able to share and distribute software.

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

Computation on devices is always more energy efficient than storing or transmitting data, meaning devices will continue to become smarter and handle more processing on their own. Many of the deep learning algorithms that researchers are exploring at the moment are still too complex to run on very low-power small devices, but there’s already a huge amount of interest in figuring out how to push these algorithms down to small, low-power devices.

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.