Official Blog of Silicon Labs

    Publish
     
      • 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.

        Introduction

        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

        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.

        Conclusion

        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 kevin.smith@silabs.com 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.

        Cheers,

        Kevin

         

      • 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: https://www.silabs.com/products/wireless/internet-of-things.

      • 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.

        Wireless

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

        MCU/Micrium

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

        Isolation

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

        Proprietary Wireless

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

        Bluetooth

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

        Mesh Networking

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

        Securely Managed IoT Solutions

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

         

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

        Feb. 27th

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

         

        Feb. 28th

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

         

        March 1

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