Official Blog of Silicon Labs

      • Introducing New PoE Devices

        Lance Looper | 03/64/2018 | 09:54 PM

        This week we’re at APEC 2018 and we’ve just introduced two new PoE powered device families designed for best-in-class efficiency and integration for the IoT. Power-over-ethernet is ideally suited for application that require both power and data at a device connected to an Ethernet switch. A couple of the advantages include lower equipment costs and lower installation costs  compared to separate data cables and power cables. It also makes use of the massive installed base of UTP cabling for wired Ethernet networks, and is part of IEEE’s 802.3at Ethernet standard, which specifies the technical requirements for the safe and reliable distribution of power over the same CAT-5 UTP cabling.

        Our new Si3406x and Si3404 devices offer the highest level of integration available for high-voltage devices on a single power delivery chip and support IEEE 802.3at PoE+ power functionality, power conversion options with up to 90 percent efficiency, robust sleep/wake/LED support modes, and electromagnetic interference (EMI) performance. These features will help developers reduce system cost and help them get to market faster with high-power, high-efficiency PoE PD-powered applications.

        Designers face a number of challenges in creating new devices, including low power conversion efficiency, electromagnetic interference problems, oversized PCBs with a lot of BOM, and running out of headroom on power. The Si3406x and Si3404 can help relieve all of these through high efficiency, proven EMI results with suppression and control techniques, superior BOM integration, and 30W power headroom.

        IP cameras are a good use case because two cables are needed; one for power and one for data. With PoE, these two cables are combined into one. With a complete power supply built with Si3406x or Si3404 PD devices, designers can focus on their more value-added portions of an IP Camera design.

        The growth of the IoT is raising demand for PoE+ connectivity across application areas, and the increasing popularity of the PoE+ standard, coupled with the requirement to support 30 W designs, these parts represent the next movement in PD interface solutions for homes, businesses, and industrial environments.

        The Si3406x family integrates control and power management functions needed for a PoE+ PD applications, converting the high voltage supplied over a 10/100/1000BASE-T Ethernet connection to a regulated, low-voltage output supply. The highly integrated architecture minimizes printed circuit board (PCB) footprint and external BOM cost by enabling the use of economical external components while maintaining high performance.

        Its high-power PoE+ capabilities also make it possible to develop advanced IoT products including IP cameras with pan/tilt/zoom and heater elements and newer protocol 802.11 wireless access points that demand much from power supplies. The Si3406x family’s on-chip current-mode-controlled switching regulator supports multiple isolated and non-isolated power supply topologies. This flexibility, along with Silicon Labs’ comprehensive PoE/PD reference designs, makes it easier and faster for developers to deploy critical power supply subsystems.

        The S3406x and Si3404 Family bring a large number of additional benefits over our previous, single offering of Si3402. 

        • EFFICIENT: With 90% efficiency options with added BOM (like FET switch to replace a diode for synchronous rectification), the family can make best use of 30W.  Further, with the best high voltage device and BOM integration in the industry, customers enjoy best cost and size.
        • VERSATILE: By supporting major topologies (buck, flyback, isolated, non-isolated), the family is flexible for any PD application type.  It supports switching between PoE and AC adapter-supplied power.
        • ADAPTABLE:  The Si34062 supports sleep and wake modes for lowest possible standby power consumption.  Each IC is resilient to surges per the IEEE specification.  And the tunable switching frequency helps the system designer control and eliminate unwanted harmonic emissions.

        For more information, visit: or





      • Timing 101 #7: The Case of the Spurious Phase Noise Part II

        Lance Looper | 02/57/2018 | 07:17 PM


        Hello and welcome to another chapter in our Timing 101 series from Silicon Labs' Kevin Smith.


        In this article, I want to continue last month’s discussion regarding spurs in clock phase noise measurements. There were a few items I just couldn’t include previously due to lack of time and space.

        You will recall from last time that spurs are discrete frequency components in clock phase noise plots. Spurs are typically few and low amplitude, but generally undesirable as they contribute to a clock’s total jitter. 

        However, spurs can also be used for evaluation and characterization of timing devices. We can use lab sources configured for low-level modulation to apply spurious frequency components, directly or indirectly, as input stimuli to a clock device or system. The resulting output clock spurs are then measured with a spectrum analyzer or phase noise analyzer.  

        In this post, The Case of the Spurious Phase Noise Part II, I will briefly review suitable signal modulation options.  Next I will discuss some notable measurements.  Finally, I will give results for a select example, jitter transfer.


        Modulation Selection, i.e. Not All Spurs are Created Equal

        There are three basic analog modulation options to most lab grade generators, i.e., AM, FM, or PM, referring to Amplitude Modulation, Frequency Modulation, and Phase Modulation, respectively. Each have their place in our “spur toolbox.” But first a digression. Consider each of the spectrum analyzer screen caps below. The carrier is nominal 100 MHz and there are a pair of symmetric spurs on each side at 100 kHz offset from the carrier.  Each spur is about 60 dB down from the carrier.

        Can you tell which screen cap corresponds to AM, FM, or PM? No, not really, not without additional information. In this particular example, the images are in alphabetical order.

        So, why are they so hard to distinguish? There are several reasons:

        1. A spectrum analyzer measures only the amplitude of the spectra, but not the phase.  In this sense, it acts like a voltmeter.  See for example Keysight Technologies’ Spectrum Analysis Basics app note.
        2. FM and PM are both angular modulation methods that behave the same way and really only differ by their modulating function. An FM signal can produce PM and vice-versa.
        3. Finally, at low modulation indices, AM, FM and PM sideband amplitudes look very similar.

        Let’s look at the last couple of points in some detail.  The following relations are adapted from the appendix in Keysight Technologies’ Spectrum Analysis Amplitude and Frequency Modulation app note.


        Note: These FM components are the same magnitude as for AM, but unlike AM there is a minus sign in front of the lower sideband. However, since the spectrum analyzer does not preserve phase information, low modulation AM, FM, and PM components look the same.

        In general, the SSB or single sideband spur to carrier ratio of AM, FM, or PM is 20*log10 (Modulation Index/2). For example, given 200 Hz peak-peak frequency deviation and 100 kHz frequency modulation, we expect a SSB spur as follows:

        SL = 20 log10 {(200/2)/100E3} = -60 dBc

        Now, here’s the practical aspect of using FM versus PM. If your source supports PM, then you can directly enter the amount of peak phase modulation. You need not change this setting as you step the modulation frequency or spur offset frequency.  However, if your source only supports FM, then the frequency modulation index must be maintained per the following relation.

        In this case, you will need to scale the peak frequency deviation Delta-f together with the modulation frequency fm in order to keep Beta constant.

        So What Tests Can We Do with Modulation Spurs?

        Generally, we will measure output clock spurs in the frequency domain using either a spectrum analyzer or a phase noise analyzer. We choose different modulation methods depending on what stimulus we need to apply to the system.  The table below summarizes some notable measurements. I will briefly discuss each of these tests and then focus on the last one in a bit more detail.

        You will note that either FM or PM can be used to generate input clock spurs for jitter transfer testing. The only thing you will need to keep track of is the phase or frequency modulation index. Modern AWGs (Arbitrary Waveform Generators) typically support AM, FM, and PM.  Higher frequency RF and Microwave signal generators also support at least FM.


        Here are some more details about each of the tests mentioned in the table.

        Input AM-to-PM Conversion

        A high gain well designed clock buffer will tend to reject AM and only pass along phase (timing) error. However, no input clock buffer is perfect and some AM-to-PM conversion can take place. The mechanism and amount of such conversion will in general differ depending on the modulation frequency. 

        The set-up for this test is straight forward, i.e. apply an input clock with AM and then check for an output clock spur offset at the amplitude modulation frequency.  There are a few considerations to keep in mind when doing this type of test:

        • Keep the modulation index low so there is practically only a single sideband spur of consequence.
        • Vary the modulation frequency over the regions of interest. 
        • Use a limiter on the input to the spectrum analyzer or phase analyzer so that we needn’t worry about AM-to-PM conversion in the instrument.


        PSR or Power Supply Rejection is similar to the previous test in that AM is applied. However, in this case, it is not the input clock that is modulated.  Rather AM is introduced indirectly via the power supply and then spurs measured as before.  This type of measurement also goes by other names such as PSRR (Power Supply Rejection Ratio) or power supply ripple testing.

        In addition to the earlier AM-to-PM considerations, there are a few others:

        • We usually want to remove all the bypass capacitors if possible. This eliminates one variable and makes it easier to inject fixed amplitude ripple, e.g. 100 mVpp, into the power rail over the frequency range of interest. It is also fairer when comparing devices.
        • AM needs to be injected into the power supply without impacting instruments or other system components.  We generally use a Bias Tee for this purpose.
        • Consistency is important for low level spur measurements, so try to keep set-ups the same when comparing devices.


        This topic alone deserves much separate treatment.  Please see Silicon Labs app note AN491: Power Supply Rejection for Low-Jitter Clocks for further details. Where there are multiple rails, and/or removing bypass caps may be a performance issue, you can leave them in and simply do straightforward performance testing as described in Silicon Labs’ app note AN887: Si534X and Power Supply Noise.


        Jitter Transfer

        A relatively quick way to check the transfer curve of a clock PLL chip is to apply low level PM or FM spurs and step the modulation offset frequency from well below the expected loop bandwidth to well above it. Then using a phase noise analyzer, with Max Hold enabled, you will see how the applied spurs roll off. The intersection of the asymptotes of the spur amplitudes allows one to estimate the loop bandwidth.

        You can kind of tell what’s going on by looking at the phase noise, but using a fixed modulation index input clock allows us to more precisely measure the transfer function. The 2 screen caps below were taken applying a phase modulated 25 MHz input clock (0.2° phase deviation) to an Si5345 jitter attenuator and measuring the phase noise continuously in Max Hold for a 100 MHz output clock.

        In the first case, figure below, the DSPLL bandwidth is set 400 Hz. The plot shows that the annotated asymptotic lines intersect right around 400 Hz, as expected. The roll-off in the vicinity of the corner frequency is a little over 30 dB/dec.


        In the second case, figure below, the DSPLL bandwidth is set to 4 kHz. This time the plot shows that the annotated asymptotic lines intersect around 4.5 kHz, which is a little wider than the nominal target. The roll-off in the vicinity of the corner frequency here looks closer to 25 dB/dec.


        The use of the Max Hold feature allows us to make a “quick and dirty” manual measurement. However, we could make more careful measurements using averaging and storing spur amplitudes across ensembles of runs in order to accurately characterize the loop bandwidth of the DUT.


        Well, that’s it for this month. In this post, I’ve extended our discussion on spurs in phase noise measurements to include some thoughts on using them for test purposes. I hope you have enjoyed this Timing 101 article.  

        As always, if you have topic suggestions, or there are questions you would like answered, appropriate for this blog, please send them to with the words Timing 101 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.




      • Simplify Low-Power, Cloud-Connected Development

        Lance Looper | 02/54/2018 | 08:24 AM

        For the upcoming Embedded World tradeshow in Nuremberg, Germany, the Silicon Labs MCU team is showing off some unique ways to ease the challenges of developing cloud-connected applications. The demo consists of the EFM32 Giant Gecko 11 MCU, which is running Micrium OS and connects to Amazon Web Services via the new XBee3 cellular module from Digi International.


        This particular demo is quite simple – a closed-loop system with an MCU monitoring a temp sensor and controlling a fan. However, the real-world use cases that these building blocks and tools can scale to serve are much more profound.

        For example, many smart city applications including bridge sensors, parking meters, waste management sensors, and others often consist of portable sensor devices that require seamless long-range connectivity to the cloud. They may be battery powered with user demands of 10+ year battery life. They may have lots of sensor inputs and extra features like button inputs and local displays. Finally, they might need to be designed quickly, but with a long field-upgradeable lifetime in mind. These are the types of applications that this demo speaks to, with Micrium OS, Giant Gecko 11, and Digi’s XBee3.

        Micrium OS is running on the MCU and helps modularize the application functions. It’s helping the MCU maintain communication with the cellular module, monitor the temp sensor, drive the TFT display, and update control settings when local push buttons are pressed. By using Micrium, these various pieces can easily be divided and coded in parallel without having to worry about any messy integration at the end. In fact, this is exactly what the Embedded World demo team did – three different development teams in three different cities built the demo, and Micrium was the underlying glue that made it seamlessly come together.

        Another challenge being addressed here is the connectivity piece. As devices are now adding wireless connectivity, there are lots of hurdles to clear: RF design in some cases, FCC certifications, understanding wireless networking, security, and more. Not only does Silicon Labs offer homegrown, low power SoCs and modules, but now Digi helps add simple cellular connectivity. The Digi XBee3 is a plug-and-play NB-IoT module that has built-in security and is pin-compatible with 3G and LTE-M modules. It’s programmable via MicroPython and comes pre-certified so developers can focus more on the application itself.

        This brings us to the developer’s main focus, the application. The Giant Gecko 11 is a new 32-bit energy friendly microcontroller from Silicon Labs, and our the most capable yet. It helps simplify complex, cloud-connected applications with its large on-chip memory (2MB/512kB), lots of flexible sensor interfaces, SW and pin compatibility with other EFM32 MCUs, and unique low power capability to help prolong battery life. For example, not only does Giant Gecko 11 allow for autonomous analog and sensing in “Stop Mode” (1.6 uA), but it also has Octal SPI interface for external data logging, which could be used to reduce cellular transmission duty cycling.

        There is one more unique offering in this demo. Considering that cellular connectivity might not be the solution for all IoT applications, the SW compatibility of Giant Gecko 11 and all EFM32s with Silicon Labs Wireless Geckos makes it easy to migrate to another wireless SoC or module, if needed. For example, some use cases and markets may use NB-IoT (such as this demo), while others might need their own proprietary sub-GHz solution (Flex Gecko).

        For more information about what we’re doing at Embedded World, click here:

      • IoT Hero Play Impossible Puts a New Spin on Playtime

        Lance Looper | 02/47/2018 | 09:26 AM

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


        How did Play Impossible come about?

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


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

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


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

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


        What was Silicon Labs’ value proposition in the beginning?

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


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

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


        What was the Last Gadget Standing competition at CES like?

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


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


        Is all of the production for Gameball done in house?

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


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

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

      • Selecting the Best Mesh Networking Standard

        Lance Looper | 02/43/2018 | 10:23 AM

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

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

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

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

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

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

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

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

        Download the whitepaper.





      • Ethernet’s Role in Hyperscale Computing

        Lance Looper | 02/36/2018 | 11:51 AM

        Significant investment is pouring into data centers as the enterprise market accelerates its increased use of cloud-based computing solutions and the demand for lower latency intensifies. Wireless networks are also experiencing tremendous change as networks move from 4G/LTE to LTE-Advanced and 5G systems.


        In a new whitepaper by James Wilson, Senior Marketing Director of Timing Products at Silicon Labs, details how data centers and wireless networks are equipping themselves to handle these enormous changes by adopting high-speed 100G Ethernet. Although a popular and cost-effective solution, the increased use of optical high-speed Ethernet is driving the need for high-performance clock and frequency control products in both wireless network and data center environments.  

        The new paper details why clock and frequency products are playing a crucial role in these two technological evolutions. For example, several specific technical obstacles have arisen within data centers as they use the Ethernet to support the rapid shift of enterprise workloads to cloud infrastructure. The majority of data center traffic stays within the data center as workload processing is distributed across multiple computer nodes, posing a serious problem to data centers. To clear this hurdle, data centers are starting to optimize their network architecture to support distributed, virtualized computing by connecting every switch to each other, otherwise known as hyperscale computing.

        The Ethernet is critical to making hyperscale possible as data center switches quickly move from 25G, to 50G, to 100G to expedite data transfer and network efficiency. This speedy migration is driving data center equipment manufacturers to upgrade switch and access ports to higher speeds, fueling the need for higher performance, lower jitter timing solutions. Ultra-low jitter clocks and oscillators are necessary in these applications because high clock noise can result in unacceptably high bit-error rates or lost traffic.

        As the paper details, mobile networks are also experiencing seismic change as operators prepare to support mobile data traffic expected to grow by 49 exabytes per month by 2021, a sevenfold increase since 2016. To meet the aggressive bandwidth demands, wireless networks are being re-architected and optimized for data transport with widescale adoption of high-speed Ethernet in radio access networks (RAN). The whitepaper lays out how the wireless industry is starting to re-envision base station architectures. Unlike the distributed model of 4G/LTE, where RF and baseband processing functions were split into separate remote radio heads (RRH) and base band units (BBU), the connection between baseband and radio elements, known as the fronthaul network, are being optimized for LTE-Advanced/5G networks.

        To ensure fronthaul networks can handle the new bandwidth constraints being placed on them with the proposed new architecture, numerous standards have developed. Highlighted in detail within the paper, the new fronthaul standards are driving the need for frequency flexible timing solutions that can support both LTE and Ethernet clocking in radio heads, small cells, and pico cells. These new solutions provide the opportunity for hardware designs to unify all clock synthesis into a single, small-form factor IC.

        For wireless infrastructure and data center architects, the paper is a must read. Providing readers with detailed architecture and IC illustrations, the article will give readers better perspective on effectively leveraging the Ethernet while maintaining flexible, accurate timing and synchronization – which ultimately, prevents the loss of traffic and/or data error in either environment.


        Read the full paper here.






      • Embedded World 2018

        Lance Looper | 02/32/2018 | 11:08 AM

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

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


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


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


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

        Proprietary Wireless

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


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

        Mesh Networking

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

        Securely Managed IoT Solutions

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


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

        Feb. 27th

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


        Feb. 28th

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


        March 1

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


      • Timing 101 #6: The Case of the Spurious Phase Noise Part I

        Lance Looper | 01/29/2018 | 11:19 AM

        Hello and welcome to another edition of the Timing 101 blog from Silicon Labs' Kevin Smith. It’s a new year and time for a new post!

        In this month’s article, I will discuss spurs in clock phase noise measurements. Most everyone in timing will recognize spurs as the distinctive spikes in the phase noise plot below. They are generally undesired and in the frequency synthesis business low level spurs are not uncommon. They are the foam on the beer as it were. This particular plot comes from an AWG or Arbitrary Waveform Generator configured for 100 MHz sinusoidal output with 1 MHz FM. I will be using this plot or similar versions of this data throughout this article.

        What is not always appreciated is their relative significance and how they should be displayed and accounted for in applications and troubleshooting. They can also be generated for device and system evaluation and characterization.

        In this first post, I will briefly review spurs and their distinctive characteristics. Next, I will discuss how to account for them when calculating total RMS phase jitter. Finally, I will sum up with my assessment of the relative merits of the three approaches to displaying spurs (or not) in phase noise plots. Looking ahead to part 2, I will discuss the usefulness of generating spurs on purpose for evaluation and testing.

        What are spurs?

        The technical term spur is short for spurious which comes from the Latin spurius meaning illegitimate or false. See for example the entry here. There is another more general use of the word spur which refers to a spike or protuberance as in cowboy spurs and the San Antonio Spurs. Coincidentally, both meanings are somewhat fitting in this context.

        Here spurs are carrier or clock frequency spectral imperfections measured in the frequency domain just like phase noise. However, unlike phase noise they are discrete frequency components. This gives these features several particular and interesting characteristics:

        1. Spurs are deterministic.
        2. Spur power is independent of bandwidth.
        3. Spurs contribute bounded peak jitter in the time domain.

        Let me expand a little bit on each of these characteristics in turn.

        Spurs are deterministic

        Spurs are generally undesirable and to be distinguished from the harmonics needed to constitute a square wave or trapezoidal wave clock. Their specific frequencies can aid us in determining their origins and relative importance. For example, they can be caused by systemic sources such as board power supply noise, crosstalk, mixing, modulation, PLL architecture, and power line harmonics.

        PLLs effectively sample the input clock, usually through a PFD (Phase Frequency Detector), and therefore must suppress update rate spurs. Further, PLLs that synthesize fractional output frequencies typically yield spurs due to fractional division.

        Spur power is independent of bandwidth

        This is true for discrete frequency components generally and can be observed directly on a spectrum analyzer. By contrast non-deterministic noise power is proportional to bandwidth. Consider the 2 side-by-side plots below displaying a 100 MHz sinusoidal carrier with +/- 100 kHz FM sidebands acting as spurs. The traces were averaged over 5 runs and the span was set to 300 kHz. The only difference between the 2 plots is the RBW or Resolution Bandwidth.

        In the left hand side plot the RBW = 6.25 kHz. In the right hand side plot the RBW = 291 Hz. You can see by the red line annotations that the peaks remain essentially the same magnitude while the noise level dropped going left to right. I “eyeballed” the noise to be about a 10 dB delta between the plots. We expect the noise to decrease narrowing the RBW from 6.25 kHz to 291 Hz by 10*log10(6.25 kHz/291 Hz) = 10*log10(16) = 12 dB which is reasonably close in this case. Note that the discrete frequency components get narrower also.



        Spurs contribute bounded peak jitter in the time domain.

        Each spur can be regarded as a phase modulation sideband to the carrier whose amplitude determines the peak phase deviation contribution. This useful feature can be exploited in testing and I will discuss this topic in the next post. By contrast, peak phase deviation is unbounded for random phase noise.

        Accounting for Spurs

        Phase noise in a phase noise plot is a power spectral density measurement displayed on a per Hertz basis, i.e. in units of dBc/Hz, and then integrated over a jitter bandwidth to yield an RMS phase jitter quantity. The units make sense since [dBc/Hz] x [Hz] = [dBc], a measure of the RMS phase jitter power with respect to the carrier. Statistical methods then have to be used to estimate the peak phase jitter over that same bandwidth. (Phase noise instruments do not actually measure the phase noise in 1 Hz increments but use a larger RBW depending on the offset frequency range.)

        The RMS jitter contribution for each spur can be calculated as follows. (See for example Silicon Labs app note AN256: Integrated Phase Noise.)

        L(f) here is taken to be the spur power in dBc at offset frequency f for carrier frequency f0. The proper way to account for spurs when calculating RMS jitter for both phase noise + spurs is to add each spur’s individual jitter power contribution in RSS (Root Sum Square) with the RMS phase jitter due to noise only.

        We can demonstrate this with an example.

        The left-hand plot below is a phase noise plot for the example nominal 100 MHz clock with spurs omitted. The right-hand plot is the same phase noise plot but with spurs identified and explicitly displayed in dBc. For this instrument, spurs in dBc are displayed in a different color than the phase noise. In the first case the RMS phase jitter measured between 12 kHz to 20 MHz was calculated as 668.837 fs. In the second case, the RMS phase jitter measured was recorded as 878.156 fs. This is an increase of about 209 fs or about a 31% increase.

        An interesting question is how spurs are identified in phase noise test equipment. This particular instrument defines a threshold in terms of how much higher a peak has to be than the standard deviation of the noise based on a moving average. The default spurious sensibility setting is 3 x standard deviation (sigma) which has proven to be a good practical value.

        To see why the spurs contributed this much additional jitter, note that there are 3 spurs shown in band, i.e. between 12 kHz and 20 MHz offset. In the table below I list the 3 spurs together with their individual RMS jitter contributions as calculated per the cited formula. The 1 MHz spur due to FM dominates. (The spur offset frequency location and amplitude came directly from the instrument’s spur list.)

        Now, let’s RSS all these values together:

        This is very close to the 878.156 fs reported by the instrument. You can go through a similar exercise, entering spurious data separately, using our online Phase Noise to Jitter Calculator.


        Displaying Spurs

        You may have noticed that the very first phase noise plot had spikes that looked different (shorter) than the plot with spurs in dBc above. Let's put the two figures together side-by-side. You can see now that the left-hand side plot has the spurs in the same color as the phase noise. The spurs in the left-hand plot are depicted in units of dBc/Hz. That is the instrument scales the spur down by normalizing them with respect to the RBW as follows:

        Spur peak [dBc/Hz] = Spur amplitude [dBc] – 10*log10 (RBW)

        In most instruments the RBW will vary from Hz to MHz, depending on the offset frequency range, usually on the order of 10% down to 1% of the offset frequency. The instrument may or may not explicitly provide the RBW. However, we can always deduce it.

        You will recall the largest spur at 1 MHz was displayed as -72 dBc in the right-hand plot. In the left-hand plot the same spur is depicted roughly speaking as a skinny triangle with the peak measuring about -117.5 dBc/Hz and a base that now extends slightly below and above 1 MHz offset. So we can calculate the RBW at 1 MHz offset as follows:



        You may wonder why the "spurs in dBc/Hz" view is useful. If all you care about is the impact of the RMS phase noise then this view helps puts things in proper perspective versus the non-spurious phase noise. In some cases, sales and field applications engineers may regard the right-hand style plot as unduly alarming though they contain approximately equivalent information.

        On the other hand, the right-hand style plot is more accurate and more useful for troubleshooting. Note that in this particular example, going left to right, the calculated RMS jitter differs increasing from 809.574 fs versus 878.156 fs respectively for an increase of about 8%. Further, it is very useful to know the dBc value of the spur directly without being concerned about the instrument's RBW at a particular offset frequency.

        The table above summarizes my assessment of the relative merits of the three approaches to displaying spurs. Your mileage may vary.



        This month I’ve discussed spurs in phase noise measurements. I hope you have enjoyed this Timing 101 article. This is only a brief introduction as entire books could be written just on this topic. I will return to this subject in The Case of the Spurious Phase Noise Part II next time to discuss generating and using spurs for testing.

        As always, if you have topic suggestions, or there are questions you would like answered, appropriate for this blog, please send them to with the words Timing 101 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.




      • IoT Hero DeviceRadio Levels Playing Field for IoT Innovation

        Lance Looper | 01/22/2018 | 05:32 PM

        IoT Hero DeviceRadio Levels Playing Field for IoT Innovation

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

        Tell me about DeviceRadio – how did it come about?

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


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

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

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

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


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

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

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

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


        What exactly does the horizontal layer include?

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

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


        Have you started selling the product?

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


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

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


        So they don’t understand what’s possible?

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


        What Silicon Labs products are you using?

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


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

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




      • A Certified Great Place to Work

        Lance Looper | 01/15/2018 | 12:39 PM

        Arcade games, big wheel races, and fitness challenges are a few of the things we do at Silicon Labs between developing the silicon, software, and solutions for a smarter, more connected world. After more than 20 years in business, we've created a corporate culture that fosters talent and encourages a healthy work-life balance. 

        2017 was a great year for us being recognized as a great place to work and we were proud to receive recognition from the following organizations:

        2017 Top Workplace (Austin American-Statesman)

        2017 Best CEO (Austin Business Journal)

        2017 Ethics in Business & Community (Recognize Good)

        2017 Best Place to Work (Austin Business Journal)

        Certified as a 2017/2018 Great Place to Work

        If you're interested in a career with Silicon Labs, check out our career page here