Silicon Labs
|
Silicon Labs Community Silicon Labs Community
  • Products
    1. 8-bit MCU
    2. 32-bit MCU
    3. Bluetooth
    4. Proprietary
    5. Wi-Fi
    6. Zigbee & Thread
    7. Z-Wave
    8. Interface
    9. Isolation
    10. Power
    11. Sensors
    12. Timing
  • Development Tools
    1. Simplicity Studio
    2. Third Party Tools
  • Expert's Corner
    1. Announcements
    2. Blog
    3. General Interest
    4. Projects
How to Buy
English
  • English
  • 简体中文
  • 日本語
//
Community // Blog

Official Blog of Silicon Labs

  • Show More
    Publish
    • Immediately
    • Draft
    • At scheduled date and time
     
      • ‘Me, too’ Movement Propels IoT Hero Enseo to Create IoT Employee Safety Products

        Jackie Padgett | 09/273/2019 | 12:36 AM

        Last month, we had the chance to speak with David Simpson, Chief Product Officer, and IoT Product Manager Logan Stover, at Enseo. If you’ve ever stayed in a hotel room and watched an on-demand movie or streaming service on the TV, you’ve probably used the Texas-based company’s technology.

        Enseo reaches more than 84 million people annually through their platform. A few years ago, the company expanded its hospitality offering into safety and created an IoT employee safety device using Silicon Labs’ wireless technology. The new product contributed to an industry-wide conversation in hospitality around steps employers can take to help prevent housekeeping staff assault incidences.

        Today, four years after launching the system, the MadeSafe® product is used by many housekeeping employees across many of the largest hotel brands, including Marriott. David and Logan share some details below about the company and how the safety product came about.

        Can you tell me a little bit about Enseo?

        Today we have four core products in one platform, including in-room entertainment, high-speed Internet, IoT energy management and room control, and the MadeSafe employee safety system. The demand for this platform grew quickly, and we have ventured into other adjacent markets, including education, hospitals and government. Enseo got its start almost 20 years ago after creating one of the first TV channel scroll guides for cable TV. Soon after that, Enseo entered the hospitality market.

        How did MadeSafe come about?

        One reason why MadeSafe is so useful is because hotel employees are often alone during the work day while servicing hundreds of rooms. Several years ago, the press was focused on a sexual assault case involving a New York City housekeeper and a prominent international politician. The case garnered a great deal of media attention about sexual assault in the hospitality sector. Shortly after the case, several New York City hotels approached us about designing an employee safety product. Enseo deployed the first generation of MadeSafe at the J.W. Marriott Essex House in 2015.

        According to the Center for American Progress, 25 percent of all sexual assault charges filed are in industries with a large number of service sector workers who are often women.

        By late 2017, the #metoo movement brought these issues to the attention of everyone. Hoteliers and cities began creating ordinances, while unions brought the issue to a higher level of attention, inspiring several communities and the American Hotel and Lodging Association to be more aggressive in industry requirements around safety. Today most hotels are committed to installing this technology by the end of 2020. The hospitality industry is leading other industries in proactively addressing these safety concerns.

        How does the product work?

        Each employee wears a small wireless device that looks similar to a car key fob. If the employee feels threatened, they simply press the button, and a geolocation signal is immediately sent to designated safety personnel, showing exactly where the employee is located on a 3D property map. Employees can only be tracked when the button is pressed, which was an important privacy element we built into the product.

        Why did you use Silicon Labs to help design the product?

        Silicon Labs’ multiprotocol functionality and performance, along with cost, were the key differentiators for us while considering the design of our latest generation of MadeSafe product. Also, of key importance to us was the multiple protocol capability to keep options open for later generations of the MadeSafe system and other IoT future products. The Silicon Labs multiprotocol Wireless Gecko platform was easy for Enseo developers to use, allowing us to incorporate both Zigbee and Bluetooth protocols into the product. The platform’s capabilities to enable over the air updates and the Simplicity Studio development kit were also critical to our development team, as it helped simplify and speed the design process. Our design team, who was already familiar with Silicon Labs systems, also liked the scalability and flexibility of the software ecosystem.

        Where do you see IoT headed in the next 5-8 years?

        IoT security needs more attention from both silicon and software providers. Hardware, in particular, has a key role to play in security, but up until now, hardware hasn’t had a pivotal role. We see this changing in the future. The future of IoT will bring an enormous number of new devices into the market, many of which we have not even begun to imagine. While cost pressures will be substantial moving forward, we will need flexible and innovative software to meet pricing and development cost demands.

      • Timing 201 #2: The Case of the Phase Noise That Wasn’t - Part 2

        kgsmith | 09/269/2019 | 07:35 PM

        Introduction

        Hello and welcome to the latest article for the blog series, Timing 201. This is a sequel to the article Timing 201 #1: The Case of the Phase Noise That Wasn’t – Part 1. In this post, I follow-up on Part 1 and suggest that both a limiting amplifier and balun are useful accessories to minimize AM and make good phase noise measurements. I include some example data and close with a few rules of thumb.

        A Quick Review from Part 1

        You will recall the basic idea we last explored was that AM (Amplitude Modulation) noise can impact phase noise measurements. (AM noise is the apparent “phase noise that isn’t”.) A spectrum analyzer cannot distinguish between AM and PM (Phase Modulation) or phase noise. Purpose-built phase noise measurement instrumentation can suppress but not eliminate AM to PM conversion. The use of a limiting amplifier can further reduce the impact of AM noise on phase noise measurement. This can be a valuable troubleshooting tool when investigating system-level clock noise and spurs.

        Example Limiting Amplifier AM Rejection

        First, a few words about the particular limiting amplifier used for data collection in this article. The ideal limiting amplifier or LA would be high gain, low noise, wideband, and modestly priced. That combination is hard to find.

        The sample LA used here is the Hittite (now Analog Devices) HMC750 which has a 3 dB bandwidth of 11 GHz. An evaluation board is available from distributors though it’s relatively expensive. There are other LAs available from other vendors, and if you buy units in quantity and/or roll your own PCB, you can certainly lower your costs. 

        Two suggestions if you do use the Hittite evaluation board:

        1. Replace the 0 Ω resistors used in the I/O paths with 1 mF 0402 capacitors. This will allow routine AC-coupled operation without having to attach external DC-blocking caps.
        2. Scrape the EVB solder mask in the vicinity of the SMA connector mounts and fillet solder them to the PCB. This will make the connectors more mechanically secure. I know from personal experience that these can “torque off” if you are not careful. <Thanks to Scott McMullen here for repairing and updating the last board.>

        As a reminder, the time domain operation of the LA is illustrated as follows. Below left is a scope capture for a 100 MHz single-ended sinusoidal clock. The AM depth was 5% and the scope is set to infinite persistence. Below right is the same single-ended clock through the example limiting amplifier.

        While the time domain operation is suggestive, AM rejection is better measured in the frequency domain. In the following measurements, a Keysight E5052B was used both as the measurement instrument and as a stand-in clock receiver. I employed a Keysight 33600A Waveform Generator, operating single-endedly, to apply AM at several frequencies and measured both the AM and phase noise spur amplitude. The carrier was 100 MHz and the AM depth was set to 1%. Getting a consistent AM spur above the noise floor was what I was looking for.

        I then inserted the cited LA and repeated the same measurements. 

        Note the new noise columns that had to be added. The LA effectively eliminated the AM spur completely, reducing it to the noise floor. There is still a corresponding phase noise spur, reduced also. (Subsequent testing indicated this was incidental phase modulation from the source.)

        Here is a sample plot for the 100 kHz case with no intervening limiting amplifier. The phase noise window is displayed at the top and the AM noise window is displayed at the bottom. Marker 1 in each window is set at 100 kHz.

        And here is a corresponding sample plot for the 100 kHz case when using the limiting amplifier. As I mentioned previously, the AM spur is eliminated which I was looking for. The corresponding phase noise spur dropped another 12 dB. For some reason, at least for this sample, the AM noise floor above 10 kHz is not flat as would be ideal.

        In general, we should use a limiting amplifier if AM noise or spurs are significant with respect to phase noise. In a measurement system that can measure both, we typically want AM noise or spurs to be at least 10 dB below phase noise or spurs at the same offset frequencies. (We weren’t quite getting that in the first table above.)

        Ideally, the same would be true for the clock receiver accounting for its AM rejection. For example, if both the input clock’s AM noise floor and phase noise floor were the same at a particular offset frequency, then we would want the clock receiver to reject or attenuate AM noise further by 10 dB. This performance is not always specified and may need to be measured. It is also often a function of the input clock slew rate or rise/fall time. 

        Differential Signaling

        A limiting amplifier is useful for removing AM from both single-ended and differential clocks. However, differential clocks are themselves an important approach to combating AM noise.

        One of the most important reasons for differential signaling on balanced lines is common mode (CM) noise rejection. Since most AM noise on differential signals is CM (e.g. due to power supplies) then differential receivers will tend to reject AM. This can be illustrated pictorially in the figures below.

        First, consider amplitude noise impressed upon a single-ended clock.

        Now, consider the same amplitude noise impressed upon a differential clock.

        There are several aspects to the diagram worth noting:

        1. Differential signaling needs equal CLKP and CLKN path lengths to minimize skew and DM to CM conversion. The PC board should be laid out to enforce this.
        2. A split termination as shown will further minimize CM noise due to any unintended skew. (Please see
          Timing 101: The Case of the Split Termination.)
        3. The differential clock receiver needs good Common Mode Rejection or CMR. Typical differential receivers should have CMR ³ 60 dB. However, this should be verified for the offset frequencies of interest.

        All of these will help to prevent CM AM noise from impacting the measurement.

        Unfortunately, most spectrum and phase noise analysis instruments have single-ended inputs and don’t directly support differential measurements. If we replace the receiver in the diagram with an instrument, what is the best approach?

        A ready measurement would be to route one differential clock polarity, e.g. CLKP, to the instrument and terminate the unmeasured polarity output, e.g. CLKN, in to 50 Ω. Generally you will want to AC-couple these so as to present roughly the same impedance. The necessity for balanced termination is discussed in Timing 101 #10: The Case of the Half-terminated Differential Output Clock. 

        This is a valid measurement but is overly conservative as it neglects the advantage that would actually be experienced in a differential clock system. What we need is a device that will convert the differential signal to a single-ended signal. Such a device is known as a balun (taken from balanced to unbalanced).

        This could be in the form of an amplifier (sometimes called an active balun) or more typically a passive component. As an example of the latter, a classic transformer balun or voltage balun has a center-tapped winding on one side for converting 100 Ω differential to single-ended 50 Ω.

        The example balun used in these tests is the Tektronix (formerly Picosecond Pulse Labs) PSPL5310R. This is a phase matched balun which can operate from 4 MHz to 6.5 GHz. Unfortunately, for some reason, these are no longer available from Tektronix.

        Other vendors which sell baluns include MACOM, Marki Microwave, and Mini-Circuits. (This is not meant to be an inclusive and exhaustive list. These are just companies I am familiar with.)

        Look for a balun wideband enough to pass the necessary waveform with sufficient risetime and with good phase and amplitude balance. The old PSPL balun had anywhere from ± 0.5 to ± 2 degrees differential phase balance and ± 0.1 to +0.3/0.2 dB differential amplitude balance depending on the frequency range. 

        Example DUT with AM Noise

        I have selected for a practical example one of my favorite “desert island” parts, the venerable Si570 which is an older generation programmable oscillator. It was the first 5 mm x 7 mm I2C programmable oscillator that could cover 10 MHz to 1.4 GHz. Radio amateurs may recognize this device as used in some “Softrock” SDR (Software Defined Radio) applications.

        Not only can it support such a wide frequency range but it can also be ordered with “real” LVPECL drivers. By this I mean it can drive DC-coupled LVPECL loads defined as 50 Ω terminated in to VDD – 2V.  (By contrast, clock devices typically provide LVPECL compatible modes where they can supply the right swing when AC-coupled.)  There is some CM (Common Mode) AM noise using this mode. However, this is mitigated when used differentially as intended. 

        Below we will tabulate several measurement scenarios with and without a balun and LA. The DUT is an evaluation board with P/N 570AAA000121DG installed operating AC-coupled.  This is a differential programmable XO with a 100 MHz starting frequency, output format 3.3V LVPECL. 

        Here are the phase jitter results for various configurations.

        The biggest bang for the buck so to speak was using a balun. That got us to the 300fs range or less which is what we expect this device to yield. (The closest Si570 datasheet spec is 360 fs typical for Fout from 125 to 500 MHz.)

        Here are a few plots to go with this table.

        First, the single-ended configuration with the highest phase jitter, over 600 fs. Note the several spurs above 1 MHz in both the AM and phase noise measurement windows. 

        Next is the balun only configuration which eliminates some spurs and drops the phase jitter roughly in half, i.e. below 300 fs.

        Finally, here is the phase noise plot combining the DUT driving the LA differentially which in turn drives the balun connected to the E5052B. This plot eliminates all the spurs above 1 MHz and still keeps the phase noise floor mostly below -150 dBc/Hz beyond this offset frequency.

        Virtual Limiting Amplifier

        Ignoring spurs, it is possible in principle to estimate the DUT’s post-LA phase noise performance by mathematically applying a “virtual limiting amplifier”, if you know what the LA AM noise floor will be and what the AM to PM conversion is for your instrument. However, that is a topic for another time.

        In practice, as one peels the onion to achieve lower and lower phase noise measurements, spurs play an increasingly larger role. This can be problematic for estimation purposes since even if the location of spurs can be predicted, often their amplitudes cannot.

        A Few Rules of Thumb

        Based on this and the previous Timing 201 post, here are a few suggested rules of thumb when making phase noise measurements on sources that may have AM noise:

        Having a good limiting amplifier and a good balun on your bench can help you make more accurate phase noise and jitter measurements, and help distinguish the type of noise contributors you are dealing with. If you are working with differential clocks, you really should use a balun even if AM noise is not that significant.

        Conclusion

        I hope you have enjoyed this Timing 201 article. If you have a favorite balun or limiting amplifier you would like to share with others, please let me know.

        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 201” in the subject line. I will give them consideration and see if I can fit them in. Thanks for reading. Keep calm and clock on.

        Cheers,

        Kevin

      • Silicon Labs Peripheral Examples

        Juan Benavides | 09/266/2019 | 07:32 PM

        Introduction

        The Silicon Labs Examples in Simplicity Studio are very easy to access: You connect your Starter Kit and Simplicity Studio will display the list of examples as shown below:

        Figure 1 Examples in Simplicity Studio

         

        We hope that you can find the most appropriate example to test your starter kit and hopefully base your design from one of the examples featured in Simplicity Studio.

        But, in case you can’t find the example you were looking for, we have a wide variety of unpublished examples in a public repository. Like when you go to a store and ask one of the store's employees to see if the item you want is in the "back room" because you couldn’t find it on the shelves; The Silicon Labs back room for those examples you couldn’t find as part of Simplicity Studio is our repository in GitHub:

        https://github.com/SiliconLabs

        There you will find examples for pretty much all the Silicon Labs devices.

        In this blog, I will show you how to access the EFM32/EFR32 Peripheral Examples.

         

         

        EFM32/EFR32 Peripheral Examples

        This repository contains low-level examples for each peripheral on the EFM32 and EFR32 devices:

        https://github.com/SiliconLabs/peripheral_examples

        The examples are organized by Series and then by Peripheral name as illustrated in Figure 2:

         

        Figure 2 Peripheral Examples GitHub Repo

         

        Device Series

        If you want to find out what Series is your device, you can look at the package marking and the number highlighted in the table below is the series number:

        EFM32/EFR32 Devices Series

        Series 0

        Series 1

        Series 2

        EFM32ZG

        EFM32PG1

        EFR32BG21

        EFM32HG

        EFR32MG1

        EFR32MG21

        EFM32TG

        EFR32BG1

         

        EFM32G

        EFR32FG1

         

        EFM32LG

        EFM32PG12

         

        EFM32GG

        EFR32MG12

         

        EFM32WG

        EFR32BG12

         

         

        EFR32FG12

         

         

        EFR32MG13

         

         

        EFR32BG13

         

         

        EFR32FG13

         

         

        EFR32MG14

         

         

        EFR32BG14

         

         

        EFR32FG14

         

         

        EFM32GG11

         

         

        EFM32TG11

         

        Table 1 Devices by Series

         

        Peripheral Name

        The table below lists all the device peripherals along with their description:

        EFM32/EFR32 Peripherals

        Name

        Description

        ACMP

        Analog comparator (ACMP) Peripheral.

        ADC

        Analog to Digital Converter (ADC) Peripheral.

        AES

        Advanced Encryption Standard Accelerator (AES) Peripheral.

        ASSERT

        Error checking module.

        BURTC

        Backup Real Time Counter (BURTC) Peripheral.

        BUS

        BUS register and RAM bit/field read/write.

        CHIP

        Chip errata workarounds initialization.

        CMU

        Clock management unit (CMU) Peripheral.

        COMMON

        General purpose utilities and cross-compiler support.

        CORE

        Core interrupt handling.

        DAC

        Digital to Analog Converter (DAC) Peripheral.

        DBG

        Debug (DBG) Peripheral.

        DMA

        Direct Memory Access (DMA) Peripheral.

        EBI

        EBI External Bus Interface (EBI) Peripheral.

        EMU

        Energy Management Unit (EMU) Peripheral.

        GPIO

        General Purpose Input/Output (GPIO).

        I2C

        Inter-integrated Circuit (I2C) Peripheral.

        INT

        Safe nesting of interrupt disable/enable.

        LCD

        Liquid Crystal Display (LCD) Peripheral.

        LESENSE

        Low Energy Sensor (LESENSE) Peripheral.

        LETIMER

        Low Energy Timer (LETIMER) Peripheral.

        LEUART

        Low Energy Universal Asynchronous Receiver/Transmitter (LEUART) Peripheral.

        MPU

        Memory Protection Unit (MPU) Peripheral.

        MSC

        Memory System Controller.

        OPAMP

        Operational Amplifier (OPAMP) peripheral.

        PCNT

        Pulse Counter (PCNT) Peripheral.

        PRS

        Peripheral Reflex System (PRS) Peripheral.

        RAMFUNC

        RAM code support.

        RMU

        Reset Management Unit (RMU) Peripheral.

        RTC

        Real Time Counter (RTC) Peripheral.

        SYSTEM

        System.

        TIMER

        Timer/Counter (TIMER) Peripheral.

        USART

        Universal Synchronous/Asynchronous Receiver/Transmitter Peripheral.

        USBD

        USB Device Peripheral.

        VCMP

        Voltage Comparator (VCMP) Peripheral.

        VERSION

        Version.

        WDOG

        Watchdog (WDOG) Peripheral.

        Table 2 Device Peripherals

         

         

        Accessing the Peripheral Examples

        To access the peripheral examples take the following steps:

        Clone or Download the repository to the following path in your Simplicity Studio installation:

        C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v#.#\app\

        where #.# is the Gecko SDK suite version number

         

        Import the example you want from Simplicity Studio by making one of the following series of clicks:

        File -> Import, or

        Project -> Import -> MCU Project

         

        To access the examples from IAR, simply navigate to the desired .eww file and double click on it.

         

         

         

        Further Reading

        • EFM32/EFR32 Peripheral API Reference: 

        https://siliconlabs.github.io/Gecko_SDK_Doc/index.html

        • Simplicity Studio Manual:

        https://www.silabs.com/documents/public/application-notes/AN0822-simplicity-studio-user-guide.pdf

      • New key negotiation protocol vulnerability detected for Bluetooth BR/EDR (Classic) products

        PanuJ | 09/250/2019 | 12:57 PM

        Last week, the Bluetooth SIG announced to its members an update about security vulnerability related to the encryption key negotiation protocols. According to the SIG, researchers of SUTD, CISPA and Oxford University identified a vulnerability with the encryption key negotiation protocol of Bluetooth BR/EDR. The attack makes it possible for a third party to make the victims to agree on an encryption key with only 1 byte (8 bits) of entropy, which then enables the attacker to brute force the negotiated encryption keys, decrypt the eavesdropped ciphertext, and inject valid encrypted messages in real-time. The attack is standard-compliant because all Bluetooth BR/EDR versions require to support encryption keys with entropy between 1 and 16 bytes and do not secure the key negotiation protocol. (More information about the details of the attack for example here www.knobattack.com)

        Our Wireless Gecko Bluetooth products (Blue Gecko) and BLE112, BLE113, BLE113, BLE121LR and BLED112 module products are not affected by this issue because they are based on Bluetooth LE core specification which does not have this vulnerability.

        Our Bluetooth BR/EDR (BT Classic) products, which include the WT12, WT11u, WT41u, WT32, WT32i, BT111 and BT121 modules, are vulnerable to this issue. We plan to release a patches which protect against this vulnerability during October 2019

      Tags

      • Wireless
      • High Performance Jitter Attenuators
      • EFR32FG22 Series 2 SoCs
      • EFR32MG21 Series 2 SoCs
      • Security
      • Bluegiga Legacy Modules
      • Zigbee SDK
      • ZigBee and Thread
      • EFR32BG13 Series 1 Modules
      • Internet Infrastructure
      • Sensors
      • Wireless Xpress BGX13
      • Blue Gecko Bluetooth Low Energy SoCs
      • Z-Wave
      • Micrium OS
      • Blog Posts
      • Low Jitter Clock Generators
      • Bluetooth Classic
      • Makers
      • Flex SDK
      • Tips and Tricks
      • timing
      • Smart Cities
      • Smart Homes
      • IoT Heroes
      • Reviews
      • RAIL
      • Simplicity Studio
      • Tiny Gecko
      • EFR32MG22 Series 2 SoCs
      • Mighty Gecko SoCs
      • Timing
      • Temperature Sensors
      • Blue Gecko Bluetooth Low Energy Modules
      • Ultra Low Jitter Clock Generators
      • General Purpose Clock Generators
      • EFR32BG22 Series 2 SoCs
      • Industry 4.0
      • Giant Gecko
      • 32-bit MCUs
      • Bluetooth Low Energy
      • 32-bit MCU SDK
      • Gecko
      • Microcontrollers
      • Jitter Attenuators
      • EFR32BG21 Series 2 SoCs
      • News and Events
      • Wi-Fi
      • Bluetooth SDK
      • Community Spotlight
      • Clock Generators
      • Biometric Sensors
      • General Purpose Jitter Attenuators
      • Giant Gecko S1
      • WF200
      • Flex Gecko
      • Internet of Things
      • 8-bit MCUs
      • Wireless Jitter Attenuators
      • Isolation
      • Powered Devices
      • Power

      Top Authors

      • Avatar image Siliconlabs
      • Avatar image Jackie Padgett
      • Avatar image Nari Shin
      • Avatar image lynchtron
      • Avatar image deirdrewalsh
      • Avatar image Lance Looper
      • Avatar image lethawicker

      Archives

      • 2016 March
      • 2016 April
      • 2016 May
      • 2016 June
      • 2016 July
      • 2016 August
      • 2016 September
      • 2016 October
      • 2016 November
      • 2016 December
      • 2017 January
      • 2017 February
      • 2017 March
      • 2017 April
      • 2017 May
      • 2017 June
      • 2017 July
      • 2017 August
      • 2017 September
      • 2017 October
      • 2017 November
      • 2017 December
      • 2018 January
      • 2018 February
      • 2018 March
      • 2018 April
      • 2018 May
      • 2018 June
      • 2018 July
      • 2018 August
      • 2018 September
      • 2018 October
      • 2018 November
      • 2018 December
      • 2019 January
      • 2019 February
      • 2019 March
      • 2019 April
      • 2019 May
      • 2019 June
      • 2019 July
      • 2019 August
      • 2019 September
      • 2019 October
      • 2019 November
      • 2019 December
      • 2020 January
      • 2020 February
      • 2020 March
      • 2020 April
      • 2020 May
      • 2020 June
      • 2020 July
      • 2020 August
      • 2020 September
      • 2020 October
      • 2020 November
      • 2020 December
      • 2021 January
      • 2021 February
      Silicon Labs
      Stay Connected With Us
      Plug into the latest on Silicon Labs products, including product releases and resources, documentation updates, PCN notifications, upcoming events, and more.
      • About Us
      • Careers
      • Community
      • Contact Us
      • Corporate Responsibility
      • Privacy and Terms
      • Press Room
      • Investor Relations
      • Site Feedback
      • Cookies
      Copyright © Silicon Laboratories. All rights reserved.
      粤ICP备15107361号
      Also of Interest:
      • Bring Your IoT Designs to Life with Smart,...
      • A Guide to IoT Protocols at Works With...
      • IoT Hero Rainus Enhances the In-Store Shopping...