Join us for a hands-on virtual workshop to learn how Silicon Labs Bluetooth Xpress shortens your path to wireless development. In this workshop you’ll get an in-depth look at the brand-new Bluetooth Xpress solution plus a hands-on experience connecting a prototype application with Bluetooth.
The speaker for this webinar will be Parker Dorris. Parker is a senior product manager for Xpress interface devices solutions at Silicon Labs. He joined Silicon Labs in 2003 when the company acquired Cygnal Integrated Products. Mr. Dorris specializes in the areas of human interface, wireless connectivity and embedded system design. He holds a Bachelor Science in Electrical Engineering from the University of Texas at Austin.
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:
Secure by Design
EFR32xG21 SoCs provide enhanced security features that enable developers to implement robust security in connected 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:
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.
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:
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
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
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
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:
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
Locate the Micrium OS examples directory, it should be in:
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:
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
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:
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:
Open "fs_storage_cfg.h" and modify the following
#define FS_STORAGE_CFG_MEDIA_POLL_TASK_EN DEF_DISABLED
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.
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:
There are several criteria for the firmware update image to be flashed:
The bootloader storage area will be erased, and the embedded application will try to establish a new HTTP/HTTPS connection, if:
1. Order an EFM32 Giant Gecko GG11 Starter Kit SLSTK3701A from our website
2. Install Simplicity Studio
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:
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.
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:
For more information on the Gecko Bootloader see the following documents:
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:
The development process can take up to a year to complete. Let’s discuss and highlight the unique challenges presented in each development stage.
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.
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.
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
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:
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.