Official Blog of Silicon Labs

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

      • Introducing new PoE Devices

        Lance Looper | 02/51/2018 | 02:10 PM

        This week we’ve introduced two new PoE powered devices designed for best-in-class efficiency and integration for the IoT. The Si3406x and Si3404 devices offer the highest level of 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.

         

        PoE is preferred for situations where a device connected to an Ethernet switch require both power and data. PoE has advantages of lower equipment costs and lower installation costs than separate data cables and power cables, and it makes use of the massive installed base of UTP cabling for wired Ethernet networks. It’s also part of the IEEE’s 802.3 Ethernet standard, which specifies the technical requirements for the safe and reliable distribution of power over the same CAT-5 UTP cabling.

        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 if these through high efficiency, proven EMI results and suppression and control techniques, superior BOM integration, and 30W power headroom.

        IP cameras, the fastest-growing segment of PD applications (with a growth rate of over 20% per year) benefits from the Si3406x IP as do WiFi access points and IP phones; where the application is complex but the power supply shouldn’t be. 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. 

        • Powerful: This family addresses the 30W-capable PoE+ (also called “Type 2” or “Class 4”) power range. 
        • The underlying 120V process technology provides plenty of headroom for the full operating voltage range, and meets or exceeds all competitors.
        • 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.
        • Adaptabe:  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: https://www.silabs.com/products/development-tools/power-over-ethernet

         

         

         

         

      • IoT Hero Play Impossible Puts a New Spin on Play Time

        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

         

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

         

        Conclusion

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

      • 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

      • Timing 101: The Case of the PLL’s VCO High Pass Transfer Function

        Lance Looper | 12/353/2017 | 12:04 PM

        Welcome to another edition of the Timing 101 blog from Silicon Labs' Kevin Smith.

        We have been doing some internal training recently and a common question that comes up is how and why a Phase Locked Loop (PLL) treats phase noise differently depending on whether it comes from the input clock or the VCO (Voltage Controlled Oscillator). Most everyone understands that input clock phase noise is jitter attenuated, i.e. the PLL acts like a low pass filter to input phase noise. However, it is not as readily apparent why a PLL should act like a high pass filter to VCO phase noise. This is the Case of the PLL’s VCO High Pass Transfer Function and the subject of this month’s post.

        First, I will review the basic feedback loop and its transfer function. Next, I will generalize the process for signals injected at different locations around the loop. I will then generate and compare the transfer functions for a PLL both from the input clock and the VCO perspective. Finally, I’ll wrap up by offering some intuition and discussing the application considerations.

        Feedback Review

        Consider the basic feedback diagram in the figure below where the variables and blocks are functions of the Laplace complex frequency variable ‘s’. The intermediate variable S representing  error should be considered likewise. The forward gain is G(s) and the feedback gain H(s). I(s) and O(s) are the input and output signals respectively.

        The closed loop transfer function TF for O(s)/I(s) is derived as follows.

        Now what happens if we break up the forward path gain G(s) in to two separate blocks, G1(s) and G2(s) and inject a new signal X(s) as illustrated below? X(s) is additive as with noise.

         

        By linearity, the transfer function TF for O(s)/x(s) is derived as follows where I(s) is set to 0.

        It turns out we can generalize for any X(s) injection point anywhere around the feedback loop as follows. The term “Loop Gain” refers to the multiplication of all the gain elements going around the closed loop. In this particular example, the Loop Gain = G1(s)*G2(s)*H(s).

        We can now apply these developments to the basic PLL.

         

        Input Clock Phase Noise Transfer Function

        Consider the basic linear “small signal” PLL diagram below.

         

        Going clockwise around the loop, the components in the diagram are as follows.

        • Kp represents the gain of the phase detector, usually a PFD (Phase Frequency Detector).
        • F(s) is the low pass filter as a function of complex frequency ‘s’.
        • Kv is the gain of the VCO and the 1/s term represents the integration action of the VCO. That is, the Laplace transform of the integral of Kv*phase is Kv/s.
        • 1/N is the gain of the feedback divider.

        We can now generate the TF for Theta_o(s)/ Theta_i(s) almost by inspection by noting that the forward gain is KpF(s)Kv/s and the loop gain is [KpF(s)Kv/s]/N.

        For reasons of stability F(s) is always a low pass filter so its value is either constant in value or rolls off with increasing frequency. In either case the overall closed loop behavior for the PLL is itself a low pass filter.

        This PLL transfer function is covered in many textbooks and articles but a more detailed and recent discussion on this topic is contained in the article “Phase Locked Loop Noise Transfer Functions” by Peter Delos published in High Frequency Electronics, January, 2016.

         

        VCO Phase Noise Transfer Function

        Now consider the basic PLL diagram modified below to also inject VCO phase noise via variable Theta_v(s).

         We can generate the TF for Theta_o(s)/ Theta_v(s) by noting that the forward gain from the VCO phase noise injection point is simply unity and the loop gain is [KpF(s)Kv/s]/N as before.

        Again, F(s) is a low pass filter so it is either constant in value or rolls off. Unlike the transfer function for the input clock, the numerator here has a zero at the origin. In this case the overall closed loop behavior for the PLL is now a high pass filter.

        Some Intuition

        OK, I know some of you may be saying, I get the math but I don’t really, intuitively, understand why the PLL acts as a high pass filter to VCO phase noise. Let me offer some food for thought that may provide some intuition.

        Consider the expected difference in behavior for a phase step at Theta_i versus Theta_v:

        • We know that a phase step at Theta_i is not immediately output at Theta_o. Rather, it will take some time, depending on the loop bandwidth, for the PLL to respond and properly step the output phase to track the change in the input clock’s phase. This is analogous to a voltage step applied to a low pass filter.
        • By contrast, a phase step at the output due to Theta_v must be immediately output at Theta_o. There is nothing to prevent this.  The loop then has to put things right in order to correctly track the input clock again. Depending on the loop bandwidth, it will take time for the output clock to lose the excess phase. This behavior is analogous to a voltage step applied to a high pass filter.

        Application Considerations

        The 2 dominant sources of phase noise in a PLL are typically the input clock and the VCO. As we have seen, the PLL treats each source's noise differently, i.e. as a low pass and a high pass filter respectively.

        The application consequences are as follows:

        1. If an input clock has relatively low phase noise versus the VCO, one typically uses a relatively wide bandwidth (BW) PLL in order to attenuate the VCO's phase noise. In this context, a wide bandwidth typically means something on the order of 100s of kHz to MHz. This is how clock generators or clock multipliers are designed. (Note that BW cannot be arbitrarily large for reasons related to stability and the need to suppress phase detector spurs.)

        2. On the other hand, if an input clock has relatively high phase noise versus the VCO, one typically uses a relatively narrow bandwidth PLL in order to attenuate the input clock's phase noise. In this context, a narrow bandwidth means something on the order of kHz or less, usually much less. This is how jitter attenuators are designed.

        Understanding this tradeoff and the ability to adjust the bandwidth "knob" is a key to troubleshooting PLLs and optimizing their application.

         

        Conclusion

        This month I’ve reviewed how a PLL's VCO phase noise transfer function arises and its unique high pass behavior. I’ve also offered some intuition and discussed the application considerations.

        I hope you have enjoyed this Timing 101 article. It’s the last post for 2017. Happy Holidays and

        Happy New Year to all of you!

        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