Wi-SUN FAN is an ideal solution for smart metering, advanced metering infrastructure, power generation, and distribution, as well as street lighting, large scale smart city infrastructure, and other industrial IoT applications. Silicon Labs has decided to strengthen our commitment to this excellent LPWAN protocol and the Wi-SUN Alliance. The alliance is a growing non-profit ecosystem of member companies whose mission is to deliver seamless connectivity via Smart Ubiquitous IoT Network applications using open global standards from organizations, such as IEEE802, IETF, TIA, TTC, and ETSI.
It is my pleasure to take a seat on the Wi-Sun Alliance board of directors on behalf of Silicon Labs to help advance this increasingly popular industrial IoT mesh networking standard. Wi-SUN offers significant advantages versus other LPWAN standards due to its scalability and multi-vendor interoperability. It also enables developers to extend wireless networks used by the utility, smart city infrastructure, and industrial IoT applications to cover deployments spanning miles and kilometers of distance.
I had a chance to talk with Wi-SUN Alliance President and CEO Phil Beecher about Wi-SUN and get his thoughts on a variety of issues. Silicon Labs is a leading provider of industrial IoT solutions, and we believe that Wi-SUN will play an increasingly important role in our portfolio.
Silicon Labs Senior Manager Abhijit Grewal, now a Wi-SUN Alliance Board Member, discusses the technical merits of the Wi-SUN protocol and how Silicon Labs will further the industrial IoT ecosystem.
AG: What is the core mission of the Wi-SUN Alliance, and what are the main activities the alliance is engaged in to achieve your key goals?
PB: The Wi-SUN Alliance’s mission is to drive the global proliferation of secure, interoperable wireless solutions for use in smart cities, smart utility networks, and other IoT applications using open global standards and supported by a rigorous testing and certification program.
AG: What qualities differentiate the Wi-SUN LPWAN standard from other LPWAN standards?
PB: The Wi-SUN Field Area Network (FAN) specification defines everything needed to create secure, reliable, and resilient networks for large scale outdoor applications such as smart utility and smart city networks.
The commercial benefits of Wi-SUN FAN derive from the use of open standards, lowering total costs, and increasing return on investment by providing interoperability, vendor neutrality, flexibility, a greater number of options, and reducing risks through a global ecosystem of member companies and vendors.
Wi-SUN FAN has numerous technical benefits over other LPWAN solutions, including superior coverage and resilience through mesh networking, better interference mitigation through frequency hopping, and enterprise-grade security already proven at a very large scale. One can think of Wi-SUN FAN as a true Internet-like infrastructure optimized for IoT devices.
AG: Silicon Labs is now a Promoter Member of the Wi-SUN Alliance and a member of the Board of Directors. How do you think Silicon Labs can help make an impact on accelerating the adoption of Wi-SUN in smart industrial IoT?
PB: Silicon Labs joins an impressive list of Wi-SUN Alliance Promoter Member companies, and further strengthens the representation of silicon innovators in the alliance. Silicon Labs is a leader in wireless IoT connectivity and has a diverse range of products supporting a wide range of IoT applications. It is particularly good to have Silicon Labs promoting Wi-SUN FAN as the leading large-scale IoT networking technology.
AG: What parts of the world are furthest along in Wi-SUN deployment, and where is there room for growth?
PB: Wi-SUN FAN compatible devices are already extensively deployed in North America and Japan, with deployments growing in LATAM, EMEA, and APAC countries. Wi-SUN FAN is particularly well suited to dense urban networks, so we foresee increased growth in major cities in India, China, and South East Asia for utility and smart city applications. In addition, the ease of configuration and maintenance makes Wi-SUN FAN suitable for rural applications, including smart agriculture.
Ross Sabolcik, Vice President and General Manager of Silicon Labs’ Industrial and Commercial IoT products, shares his thoughts on the company’s leadership in Smart City and why Wi-SUN is a field-proven protocol for mission-critical applications.
AG: What are the fastest-growing types of Wi-SUN deployments you are seeing, and what are the biggest Wi-SUN related market opportunities you think companies like Silicon Labs are positioned to capitalize on?
PB: Wi-SUN Alliance’s origins were in smart utility Network applications such as smart metering and distribution-related applications. However, Wi-SUN FAN provides an ideal communications infrastructure for smart city applications such as street lighting, smart parking, waste management, air quality sensors, and so forth. Installing Wi-SUN FAN as a communications network for street lights provides ubiquitous coverage for connection of a wide range of line powered and battery-powered sensors for monitoring and controlling an urban environment.
Silicon Labs is launching an on-going IoT Energy Management series to explore the potential of energy management technologies and to help commercial buildings reduce energy consumption and costs.
Roughly 40% of global energy consumption and 70% of electricity usage stems from buildings. These numbers are probably not surprising, given that, in normal times, we spend most of our time inside offices, schools, or homes, while simultaneously connected to electrified things. As we start to understand what this world will be like post-COVID, companies are focused now on taking advantage of emerging opportunities to boost building efficiencies and save costs. Data, insights, and most importantly – actions – are transforming the way we use energy, and this is reaching far beyond our smart homes.
Beyond remote control of a thermostat, internet-connected technology is addressing global sustainability, personal inhabitant health, and bottom-line financial savings. The commercial buildings adopting IoT technology are seeing double-digit operating efficiency savings per year. The best part is these efficiency percentages scale with the total size of the building, meaning total energy savings, which drastically increases the larger the building.
Explore the possibilities of energy management and how we at Silicon Labs are reducing our own energy footprint through our Real-World Impact of IoT Energy Management article.
In this Tech Talks session, Field Applications Engineer, Claudio Filho, describes the basics of Silicon Labs' Bluetooth LE Software structure as well as procedures for configuring the stack. Click here to watch the entire presentation and register now for future sessions. Highlights from Claudio's session are below.
Bluetooth LE Software Features
Our Bluetooth LE software stack is 5.2-compliant, featuring dynamic transmission power control, the direction finding capabilities of Bluetooth 5.1, and standard features of Bluetooth 5.0 and 4.0. It is packed with functionality such as simultaneous advertising and scanning and is optimized for low-power consumption with the ability to go into sleep mode when inactive.
The software stack can be used to create standalone Bluetooth applications for Wireless Gecko SoCs or modules or alternatively, network co-processor (NCP) applications. With the SoC model, which is the focus of this Tech Talk, the SoC is at the heart of the application, such as for wearable devices or smart lighting.
The software stack is built on top of the EFR32 platform and includes the following components:
Application Build Flow
The first step to configuring the Bluetooth LE software stack for your application is to open an empty SoC example project from the Simplicity Studio IDE. From here, you will have access to the Visual GATT Editor, a graphical tool for defining the GATT and generating gatt_db.c and gatt_db.h files.
With the GATT configurator, you can start with any pre-defined Bluetooth SIG profiles and drag-and-drop them into the configurator window. Adjustable settings allow you to customize the Bluetooth SIG services, characteristics and descriptors as needed. You can also import GATT data from external XML files.
A compiler will combine the GATT generated database files with your own application source code and begin building your project. Compiling the project generates an object file, which is then linked with the pre-compiled libraries provided in the SDK. The output of the linking is a flash image that can be programmed for production. You can also generate GBL files for enabling over-the-air (OTA) updates if needed.
Configuring Hardware and the BLE Stack
Two important files for configuring hardware within the empty SoC structure are:
These files enable code re-use among different components and peripherals. A forthcoming UI will allow you to generate these files automatically.
The Bluetooth LE stack configuration is managed within the main.c file. From this file, you can customize several parameters of our stack. The file is pre-programmed for low-power management.
Our stacks are event-driven, and events can be blocking or non-blocking. All stack events are handled at App.c.
Visit docs.silabs.com for supporting documentation including application notes, reference manuals, and user guides. Our GitHub pages include library and peripheral examples. For more information about our Bluetooth LE software stack solutions, contact your Silicon Labs sales representative.
Designing a system or product that uses more than one wireless protocol can be challenging. In this Tech Talks session, Silicon Labs Field Applications Engineer, Wendy Warne, discusses various ways to use multiple protocols in a system, with a focus on dynamic multiprotocol. Click here to watch the entire session and register now for future Tech Talks. Highlights from Wendy's presentation are below.
Silicon Labs has a variety of wireless protocol solutions, all built upon a common platform and bootloader. The physical layers of the different protocol stacks sit on top of the Silicon Labs Radio Abstraction Interface Layer (RAIL), so our silicon is well-suited for multiprotocol applications. Additionally, all our protocols are developed and maintained in-house, providing developers a common platform to work in and facilitating a consistent development environment.
Dynamic multiprotocol is a method of dynamically switching protocols to allow multiple protocol operations on one radio. It works by time-slicing radio operations between multiple stacks and changing configurations so that different wireless protocols can operate reliably at the same time.
The Silicon Labs radio scheduler arbitrates between the different protocols to determine which one will have access to the radio. Radio protocols and operations are given a priority, indicating to the scheduler which operation should be executed if there is a timing overlap between multiple operations. The radio scheduler allows the task with the highest priority to access the physical radio hardware.
Priority levels are programmable. In the Tech Talks presentation, the priorities are as follows, from highest to lowest:
1. Bluetooth LE Scheduled Transmit
2. Bluetooth LE Scheduled Receive
3. Other protocol Scheduled Transmit
4. Other protocol Background Receive
A scheduled radio operation may be interrupted if a higher priority radio function is called. Interruption can occur in the following circumstances:
See the Tech Talks video for real application examples of these and other dynamic multiprotocol events using Bluetooth LE and Zigbee.
Dynamic multiprotocol is best used in systems where radio usage is moderate and where one of the radio protocols is deterministic, such as Bluetooth, and another radio protocol is less time-sensitive, such as Zigbee.
Our Series 1 and Series 2 SoCs and pre-certified modules offer a range of low-power, low-cost solutions for your wireless protocol applications. Get up and running quickly with our Getting Started development tools, including WSTK boards, radio boards, tutorials, sample code and technical documentation.
Your local Silicon Labs FAEs are here to assist you. Reach out to them for guidance on which protocol best meets your system requirements. For more information on our wireless solutions, contact your Silicon Labs sales representative.
In this Tech Talk session, Kris Young, Field Applications Engineer for Silicon Labs, talked about the increasing challenges in wireless coexistence, its impacts on IoT application, and how Silicon Labs manage and offer built-in support for solving these challenges. Click here to watch the complete webinar and register now for future Tech Talks. Here are some key points from Kris’ session.
The Wireless Coexistence Challenge
What challenges exist in wireless coexistence? We have an ISM band at 2.4 GHz that’s very heavily used mostly because of different wireless protocols that share or coexist in the same band: Wi-Fi, Bluetooth, and IEEE 802.15.4 (Zigbee and Thread).
Although these wireless protocols have different modulation schemes, channel frequencies, and bandwidths, they all overlap when co-located, making a signal from one protocol sounds like noise interference to the other protocol. This causes problems in receiving messages between protocols because if the desired received signal is weaker than the noise, the radio is then unable to receive messages properly.
In the past, wireless devices seem to work even without specifically addressing coexistence issues. Unfortunately, ignoring the issues does not work anymore because of the following trends:
Looking further on the impacts of coexistence in IoT device development, we’ve determined two categories:
Get Additional Documentation and Support
Either you want to increase your knowledge of Zigbee Coexistence with Wi-Fi, or Bluetooth Coexistence with Wi-Fi, there are several ways to get started with boosting your understanding of Silicon Labs' wireless coexistence strategies. To get answers for more specific and/or complex questions, and access our Training Resources, Community, Forum, and Knowledge Base Articles, visit our Tech Support page.
In this Tech Talk session, Chris League, Field Applications Engineer for Silicon Labs, talked about the Zigbee software structure and demonstrated some helpful plugins and callbacks needed for developing your SoC design. Click here to watch the complete webinar and register now for future Tech Talks. Here are some key points from Chris’ session.
The Power of the Zigbee Alliance
Zigbee is one of the most widely deployed mesh networks in the market today. These primary markets consist of connected home, connected lighting, smart energy, and commercial/industrial IoT. With more than 400 member companies in the world, the Zigbee Alliance has developed more than 2,500 certified devices with more than 300 million products deployed.
The Zigbee Alliance is both the foundation and the future of IoT. The organization develops open, global standards for IoT devices, help certify products to ensure interoperability, and promote the use of standards globally. Silicon Labs sits on the alliance’s Board of Directors, among other IoT leaders in the market.
Zigbee and the Network Protocol Stack
The Zigbee PRO stack starts with the PHY layer at IEEE 802.15.4, which defines the radio characteristics and the receiving of the physical packets. The Zigbee Alliance then specifies the Zigbee stack on top of PHY, from the MAC layer up to the ZCL or the clusters (Zigbee’s standardized way of describing “things”) needed for the design. The Zigbee stack organizes the mesh network – from route discovery, device discovery, message relay, security, and the feature set. The Zigbee PRO stack ends with the User Application layer on top where initiating and joining a network happens, as well as the sending and receiving of messages, network management, and device relationship resolution.
Zigbee devices are members of an intelligent Routing Mesh where protocol packets are not only used to send messages but also to manage the mesh network.
The System-on-Chip Architecture
As a one-chip solution, the System-on-Chip (SoC) architecture is best for applications like sensors or door locks because it features minimal external components, lowest BOM cost, and ease of design.
Getting Things Done with the AppBuilder in Simplicity Studio
The Zigbee code structure can be derived from its application framework architecture categorized into the Silicon Labs code and the User code. The Silicon Labs code is basically a library of the EmberZNet stack and the Main function. We control the Main function while developers access and write codes based on callbacks. The User Code also consists of the application code and the configuration files generated by the AppBuilder.
The AppBuilder resides in Simplicity Studio. It is the developers’ tool for managing profiles and clusters, generating configuration files, putting plugins to work, implementing callbacks, and creating events.
Get Zigbee Documentation and Support
Either you want to start with the basics and learn the Fundamentals of Zigbee or advance your knowledge by reading the Zigbee Application Framework Developer’s Guide, there are several ways to get started with boosting your understanding of Zigbee concepts. To get answers for more specific and/or complex questions, and access our Training Resources, Community, Forum, and Knowledge Base Articles, visit our Tech Support page.
In this Tech Talk session, Alfredo Pérez Grovas, IoT Modules Product Manager for Silicon Labs, presented an overview of Silicon Labs’ Wi-Fi Solutions, including the RS9116 from our newly acquired family – Redpine Signals. Click here to watch the complete webinar and register now for future Tech Talks. Here are some key points from Alfredo’s session.
Redpine Signals is Now Part of Silicon Labs
Our recent acquisition of Redpine Signals added a valuable amount of technology and capability into our existing vault of expertise. The acquisition highlights the RS9116 family of chips, which comes from a line of three generations of wireless products from the previous RS9110 (Gen 1) and RS9113 (Gen 2).
Redpine Signals’ brings broad expertise in Wi-Fi and Bluetooth solutions with these products using the key technologies of ultra-low system power, multi-protocol (802.11, BT/BLE 5), and multi-threaded processors. These high-performance solutions come with an embedded wireless and networking software, along with multiple security levels, edge intelligence, and ultra-small form factor. All of these features are ideal for multiple target markets such as smart homes, fitness/wearables, healthcare, and industrial.
Expanding the Silicon Labs Wi-Fi Product Family
Our current portfolio of Wi-Fi solutions consists of two categories: Transceiver SoCs & Modules and Full-Network Co-processor SoCs & Modules. The former comprises our WF200/WFM200S and RS9116 n-Link, while the latter is our RS9116 WiseConnect.
The WF200/WFM200S module operates on 2.4 GHz Wi-Fi along with higher-level network and security stacks running on the host processor, either MCU or MPU. The RS9116 n-Link operates on 2.4/5 GHz Wi-Fi, as well as BT and BLE 5. This module also runs wireless, network, and security stacks on the host processor (MCU or MPU). The RS9116 WiseConnect runs wireless, network, and security stacks on the RS9116 while the application runs on the host processor (MCU).
IoT Application Examples of the RS9116
What can the RS9116 do to enable your IoT product development? As mentioned, the RS9116 has all the features that could serve multiple markets.
In the world of smart homes, RS9116 uses Wi-Fi communication for local and cloud control of different devices like locks, cameras, thermostats, and others. During installation, BLE communication is used to provision smart home devices to a home’s or site’s Wi-Fi network. This requirement is made possible through the built-in coexistence manager to manage Wi-Fi and Bluetooth LE coexistence. The RS9116 also features low current consumption in ultra-low power mode for battery-operated smart home devices, which is ideal for power efficiency and long battery life.
Another area of application for the RS9116 is wearable devices. This application also features ultra-low power consumption for extended battery life. Still, it is slightly different than a typical smart home device because of the simultaneous multi-protocol communication requirements as follows:
Jumpstart Your IoT Product Development Now
Learn how to develop and deploy more powerful, efficient, and secure IoT products with your own BG22 Thunderboard. Register for a free BG22 Virtual Workshop happening every Tuesday, Wednesday, and Thursday, from 10:00 AM to 11:30 AM CST.
Some five years ago, a customer contacted us thinking they needed to return a clock generator device that would often go into a continuously resetting state after power-up. We had never heard of such unusual behavior and wondered if there was anything wrong with this particular unit’s POR (Power On Reset) circuit.
Fortunately, the customer had a small PC board that frequently exhibited the behavior, and which they could ship to us for troubleshooting in our lab. This enabled us to more quickly determine the root cause and verify the solution.
It turned out that an overlooked spec for a passive component located elsewhere on the board was causing large consequences for the customer’s application. The lessons learned are generally applicable and the subject of this blog article, The Case of the Autonomously Resetting Clock Generator.
BLUF (Bottom Line Up Front)
The clock generator’s POR circuit was not at fault. In fact, it was behaving exactly as it should. Rather, an external 3.3 V regulator circuit was marginally stable. Oscillations on the 3.3 V rail could be sufficiently large to trigger autonomous resets.
Browsing the Power Supply Voltages
The customer board took in +12 V and regulated this down to the +3.3 V and +1.8 V rails required by the Si5341 clock generator. I used a lab power supply with pushbutton Output On/Off to provide the necessary +12 V input. This allowed me to manually and conveniently power cycle many times in order to observe and contrast a passing versus failing (continuously resetting) power-up event. The series of oscilloscope screen captures below display the 3.3 V (orange trace) at the top and the 1.8 V (blue trace) at the bottom.
The figure below shows the nominally settled behavior of the 3.3 V and 1.8 V after a failed power-up. The 1.8 V supply is completely accurate. However, the 3.3 V supply is clearly oscillating and even periodically dropping down to about 2.4 V, far below the POR trip threshold.
What about those occasions where the part successfully powers up? Per the figure below, both the 3.3 V and 1.8 V rails are at their nominal targets but the 3.3 V supply appears much noisier. This is another clue that the 3.3 V regulator circuit may be marginally stable.
I then looked at the start-up behavior. When the device fails, the 3.3 V supply starts oscillating straight away.
Even when the unit successfully powers up, as depicted below, the 3.3 V supply exhibits overshoot before settling down to a noisy nominal voltage.
An Informative Vendor Data Sheet
The customer was using a 500 mA LDO (Low Drop Out) regulator in a SOT-23-5 package. Reading the vendor’s data sheet, I noticed that the typical application drawing showed the output capacitor as a 2.2 uF tantalum. Further, the data sheet explicitly stated that the output capacitor needed an ESR of about 1 Ω and that ultra-low ESR caps could cause oscillation.
Inspecting the output cap on the customer’s board revealed that it was a ceramic capacitor. These can have an ESR with an order of magnitude less than an electrolytic capacitor. So that suggested the next experiment to try.
Demonstrating the Fix
We hacked in a 1 Ω resistor in series with the ceramic capacitor in order to emulate the approximate ESR of a tantalum capacitor. A close-up photo of the hack is shown below. The brown component in the upper part of the “elbow” is the existing capacitor. The component marked “01Y” is the 1 Ω resistor.
The hack was ugly but effective:
As the resulting screen cap shows above, the 3.3 V supply is much less noisy and the start-up transient is very small and quickly damped out. After many attempts, no autonomous resets were observed, current draw was as expected, and the device always yielded output clocks. This outcome was good enough for the customer to take over and do additional verification testing for their particular application.
Some Lessons Learned
This Timing 201 case exemplifies several lessons learned. These are listed below, going from the general to the specific.
I hope you have enjoyed this Timing 201 article.
As always, if you have topic suggestions, or there are questions you would like answered, appropriate for this blog, please send them to email@example.com with the words Timing 201 in the subject line. I will give them consideration and see if I can fit them in. Thanks for reading. Keep calm and clock on.
There is no lack of guidelines or even standards when it comes to designing an industrial human-machine interface (HMI). Some organizations, such as ASM, have guidelines on how to improve operator efficiency using displays. International Society of Automation has an ISA 101 committee focusing solely on HMI design and publishes standards and other helpful content for designers.
Some of the recommended guidelines from ASM include
However, there is a very large number of industrial devices that cannot be equipped with bright, high-resolution displays. The devices can be small in physical size, making it challenging to add large displays; the devices can be located far off from the operator, or the devices are running from a battery. For these and other situations, Bluetooth provides an excellent way to transform the user experience.
Using a widely adopted technology, like Bluetooth, the designers can design the HMI on smartphone or tablet screens and apply much greater design tactics than if they had to fit everything to a tiny pushbutton and seven-segment display. The operator can read the device or adjust the settings remotely, improving safety and convenience. When comparing to galvanically isolated serial interfaces, Bluetooth can provide notable savings in the bill of materials.
The Bluetooth Xpress family of products from Silicon Labs delivers the easiest integration of wireless technology for an industrial HMI. The pre-programmed and pre-certified modules require no previous Bluetooth skills. The accompanying mobile application framework simplifies mobile application development.
If you want to learn more about how Bluetooth can help you to deliver great human-machine interfaces, check out our whitepaper or get your project off the ground by ordering the Bluetooth Xpress starter kit.
The COVID-19 pandemic has turned the world upside down, making it difficult to notice positive developments. As of this writing, more than one-third of COVID-19 cases to date have recovered from the disease. As treatment procedures continue to progress and new pharmaceuticals are approved for use, health experts expect the recovery rate to continue to improve. Until then, recovery rates are primarily driven by the availability of health care providers and the equipment they require.
Many companies around the world have stepped up to increase the supply of essential equipment for fighting COVID-19. In some cases, manufacturers have converted existing production facilities for core products to the production of personal protective equipment (PPE), ventilators, and other medical stocks. Of course, this has a ripple effect on the suppliers to these converted factories. Those suppliers must also ramp up the production of devices and materials used for the construction of the required medical systems.
Silicon Labs is helping with combating the adverse effects of the COVID-19 pandemic at a global level. For example, our isolation products provide safety for patients and noise immunity for sensitive electronic medical equipment such as ventilators that are helping to save lives in this pandemic. We are expediting our supply chain despite the challenges posed by lockdowns and work-from-home policies to make sure that our manufacturing customers are receiving products on time to build critical equipment. For instance, a Silicon Labs customer in Taiwan has tooled up its factories that otherwise produce power supplies for industrial products to help meet the demand for PPE. Besides face masks and protective suits, they are also producing life-saving equipment such as ventilators. The ventilators are sophisticated medical electronic equipment that must run reliably and accurately to provide life support to patients affected by COVID-19. Digital isolation devices inside the ventilators safeguard patients while shielding the equipment from extraneous electrical noise to ensure accuracy and reliability.
Another Silicon Labs customer based in China that produces programmable logic controllers (PLCs) for factory automation has retooled to manufacture PPE. PLCs are complex devices that automate the manufacturing process by reading sensors, processing data, and controlling actuators. Without PLCs, it would be impossible to manufacture PPE in the volume and with the quality needed to stop the transmission of COVID-19. Silicon Labs’ digital isolation devices are built into the inputs and outputs of PLCs to protect the sophisticated controllers from harsh electrical transients common on plant floors and to ensure they can operate reliably around the clock.
It’s reassuring to see the global community of employees, suppliers, customers, and distributors pulling together not only to tackle the COVID-19 pandemic but to make meaningful contributions that will “flatten the curve.” Silicon Labs is honored to provide high-performance, robust, and reliable isolation solutions to help medical equipment manufacturers and factories meet growing demand during this difficult time.