Official Blog of Silicon Labs

      • Silicon Labs Supports Women in Tech

        LeighPankonien | 10/303/2017 | 05:57 PM

        Silicon Labs CMO Michele Grieshaber takes a moment to review one of Silicon Labs' four core values.

        We hire, foster and empower great talent. 

        • We look for technical skill, creativity, and the potential to do great things. 
        • We value big-picture thinkers and cross-functional doers. 
        • We create an environment of trust and encourage open, two-way communication.

        At Silicon Labs we believe this great talent can come from anywhere and anyone. Therefore we support a diverse workforce, from gender to age to ethnicity to sexual orientation, and so on. We also support and believe in the importance of STEM initiatives around the globe. Venn diagram these and you’ll get Women in Tech. 

        Our Chief People Office, Lori Knowlton, elaborated on our support of women in tech in a recent article: “Women bring new ideas and perspectives to the table. And in doing so, they open the door to well-rounded thought processes that create better, more flexible products and higher performing teams. Successful teams employ a combination of left-brain and right-brain thinking. Companies who deeply understand and invest in the value of diverse, inclusive thinking are outperforming and outthinking their competition. By three times.” 

        Within the last couple of years a grassroots movement was started by a few women at Silicon Labs with the mission focused on support, inclusion and driving change. It started as a get-together by a small group within a specific department and has since expanded to include anyone who wants to participate within the organization. The Women @ SiLabs group is currently lead by Holly Ammerman, a Senior Product Marketing Engineer, and co-chaired by Renee Curfman, our Director of IT Infrastructure Services. One example of this group driving change is its work with the senior leadership team, and one-on-one with current and future women to make sure they’re growing and have all the opportunities awarded to them so they can help Silicon Labs get to where it needs to be.

        Renee Curfman shares her perspective: “We have this opportunity to really bring amazing innovation and change to this industry. I think we can get there faster and we can get there better if we do even more to open up that conversation and include more women. There’s always more work to be done to demonstrate your commitment to diversity and having different values and frames of mind at the table will propel us forward faster.”

        We believe it’s very important to amplify these voices and to engage in a conversation about gender and diversity. Hear the advice some of our employees give to women trying to break into the tech industry:

        While this video represents just a few of the gems these ladies shared, we’ll continue to share more of their powerful thoughts on our social media channels. We encourage you to follow along and join in the conversation. 

        Let’s continue the conversation:

      • Mission to Build a More Connected Community

        deirdrewlahs | 10/301/2017 | 10:14 PM

        Hi, community members! 

        As I'm sure you can tell, we launched an improved Silicon Labs community experience we are calling The Red Planet. 

        But this is more than just a facelift. The community will continue to be a great space for you to ask technical questions, share your ideas, and learn more about our latest solutions; however, we do have some key changes. We now have higher quality search, a product-centric architecture, and improved integration between our technical resource library and the community.

        Here are some things to get you started: 

        1) Update your profile

        2) Review the community guidelines

        3) Read about our new ranking and reputation structure

        4) Please share your feedback on the new experience. 

        Our mission is to help you build something great, and we look forward to hearing from you! 

      • Employee Spotlight – Helge Langen

        Lance Looper | 10/300/2017 | 09:35 AM

        Helge Langen joined Silicon Labs as a summer intern during the summer of 2016. In his current role as Hardware Engineer for the IoT MCU & Wireless team in Oslo, Langen’s responsibilities include hardware design, design testing and firmware development. He said his role requires him to “combine technical knowledge with creative skills to achieve the desired level of esthetically pleasing products.” His typical day at the office entails working on a variety of projects that can range from using a computer, a microscope and tweezers or even a hammer!




        His supervisor, Jørn Norheim said Langen is great at his job and requires little or no detailed information. He continued, “Regularly we get into the situation where I say, ‘Oh, [Langen] already did that thing I was thinking we should do to get the project completed. Well, that’s nice!’” Norheim continued, “He’s the sort of person that does not spend too much time talking, but rather spends his time on doing. Really, really well.”


        Langen’s favorite thing about working at Silicon Labs is he gets to do things he enjoys every day with a team of nice, talented people, while having fun. In addition to his day job, Langen is an avid runner. In fact, Norheim calls him “one of Norway’s best runners.” Langen said his favorite Silicon Labs value is ‘we do the right thing’ because it reminds him of when he’s running. “The competition is sufficiently fierce to force me to do the right things at practice every day to keep up – since there will always be someone else doing the right things most of the time as well,” he said. “Having success in the semiconductor business requires no less attention to continuous improvements.”


        Helge Langan, we’re glad you’re on the Silicon Labs team. Keep up the great work!


        Helge Langen_blog.jpg

      • KRACK Vulnerabilities and Protecting Deployed Products

        Lance Looper | 10/298/2017 | 12:35 PM

        Recently a vulnerability called KRACK in Wi-Fi security, which exploited the Key Reinstallation process part of WPA2, was discovered and published by researchers. This impacts all manner of Wi-Fi-based devices, including phones and laptops, but more importantly it’s affecting connected cameras, bulbs, medical devices, and HVAC systems as well. This class of devices, referred to as IoT devices, are especially vulnerable because they don’t come with an easy way to locate, identify, and update them in the field. Since these devices do not have a user interaction model or attendant management infrastructure such as the ones that are taken for granted with smartphones, they are at risk for an extended period of time.


        Vendors are, rightly, working diligently to make software updates available that will patch the issue. Even after the patch is made available, the issue still remains because distributing these updates to the product fleet is a significant gap. Current retrofitting processes, such as emailing customers or dispatching field service teams to update the products, are simply too slow, expensive, or do not provide enough coverage. According to HD Moore, a network security researcher at Atredis Partners, some of these devices may stay vulnerable for decades[1].


        The solution lies in designing in an efficient device management service for product fleets, be it consumer or commercial connected products, from day one as insurance against future vulnerabilities. The service needs to have three key aspects:


        1. End-to-End security that addresses data at rest security on the product itself, which includes data encryption. This, coupled with data in motion security, ensures data sent to and received from the device from any cloud service is fully protected.
        2. A management platform that can identify, authorize, provision, activate, and deactivate devices from production to in-field deployment and eventual end-of-life of product.
        3. An efficient software update distribution mechanism that can update products in the field reliably without bricking the device fleet at scale.


        Silicon Labs’ offers a solution to this problem in the form a cloud-based service called Zentri Device Management Service. This is a hardware agnostic service that is already helping customers identify the security posture of their fleet and apply software updates gradually or all at once. Additionally, the service can monitor the security fleet and be used to selectively disable or de-activate compromised devices.


        Learn more at and sign up for additional information here.






      • Timing 101: The Case of the Jitterier Divided-Down Clock

        kgsmith | 10/296/2017 | 12:47 PM

        Hello and welcome to the “Clocktoberfest” edition of the Timing 101 blog from Silicon Labs.


        Nice weather is starting to arrive here in central Texas. By late September and October we get hints of cooler and less humid days to come. Those of us of German descent, and plenty who are not, may celebrate Oktoberfest or some local variant such as Wurstfest in nearby New Braunfels. So “Happy Clocktoberfest!” from the Timing group.


        This month I am going to discuss a very common question that arises when measuring the phase noise and phase jitter of relatively low clock frequencies. All things being equal, we generally expect divided-down lower frequency clocks to yield lower phase noise than higher frequency clocks. Quantitatively, you may recall this as the 20log(N) rule.


        However, the 20log(N) rule only applies to phase noise and not integrated phase noise or phase jitter. Phase jitter should generally measure about the same. Further, as we get low enough in frequency we do not find this relation to hold true in actual measurements. So the question this month is - why is that?


        The 20log(N) Rule

        First, a quick review of the 20log(N) rule for those who may not be familiar with it:

        If the carrier frequency of a clock is divided down by a factor of N then we expect the phase noise to decrease by 20log(N). For example, every division by a factor 2 should result in a decrease of phase noise by 20log(2) or about 6 dB.  The primary assumption here is a noiseless conventional digital divider.


        Why is this? The output of a practical digital divider is rising and falling edges with the signal at a logic high or low level otherwise. Jitter is presented at the rising and falling edges only. The proportion of jitteriness to each clock cycle is reduced. Our intuition may suggest that if we reduce the number of jittery edges then we reduce the jitter transmitted by the divided down clock. That turns out to be correct.


        Formally, this can be written as follows:





        What About Phase Jitter?

        We integrate SSB phase noise L(f) [dBc/Hz] to obtain rms phase jitter in seconds as follows for “brick wall” integration from f1 to f2 offset frequencies in Hz and where f0 is the carrier or clock frequency.

        phase jitter.png


        In practice the quantities involved are small enough for good clocks that the RMS phase jitter, for a 12 kHz to 20 MHz jitter bandwidth, is on the order of 10s to 100s of femtoseconds.


        Note that the rms phase jitter in seconds is inversely proportional to f0. When frequency is divided down, the phase noise, L(f), goes down by a factor of 20log(N). However, since the frequency goes down by N also, the phase jitter expressed in units of time is constant. Therefore, phase noise curves, related by 20log(N), with the same phase noise shape over the jitter bandwidth, are expected to yield the same phase jitter in seconds.


        An Example

        Let’s look at a specific example. As an experiment, I took an Si5345 jitter attenuator, input a 25 MHz clock, and configured it so that I only changed an (internal) output divider by factors of 2 to obtain frequencies running from 800 MHz down to 50 MHz. I then measured the phase noise using an Agilent (now Keysight) E5052B and compared the phase noise and phase jitter for each case. Five runs were averaged and correlated for each frequency. I omitted any spurs for clarity and to simplify the experiment.


        Through the magic of MS Paint and use of the “Transparent Selection” feature I am able to overlay all of the E5052B screen caps as follows. (If the runs are identical each time only unique text is obscured.) In the figure below, the traces generally run top to bottom in descending carrier frequency, i.e. 800 MHz, then 400 MHz, etc. on down to 50 MHz. The shapes of the curves are the same except where the curves are compressed at the highest offset frequencies.



        I then tabulated the measured phase jitter results over the 12 kHz to 20 MHz jitter bandwidth as follows:


        Timing Table.png


        There are two immediate observations we can make from the overlaid plots and the table.


        1. The separation between the curves is close to what we would expect applying the 20log(N) rule until the traces begin to appear compressed toward the 100s of kHz to MHz offset


        1. The RMS phase jitter in fs is approximately the same for 800 MHz down to 200 MHz. However, for the 100 MHz and 50 MHz cases the expected phase jitter is way


        Despite the 20log(N) rule, the phase jitter is getting worse as I decrease the output clock frequency, especially below 200 MHz. These lower frequency clocks measure far jitterier than expected. Thus arises the case of the jitterier divided-down clock.  So what’s going on?


        Curve compression due to the apparent phase noise floor appears responsible for the differences in the calculated RMS phase jitter. Let’s verify that by comparing the data from 10 kHz to 20 MHz offset for the 800 MHz and 100 MHz cases. All of the spot phase noise data came from the original markers plotted except for the 20 MHz points which were estimated from the screen cap plots. (Note that for a factor of 8 or 23 we would expect a delta of 3 x 6 dB or 18 dB in phase noise.)



        Taking just these values and entering them in to the Silicon Labs online Phase Noise to Jitter Calculator we obtain the following.


        Table 3.png


        Not too shabby for the online calculator considering it only had 5 data points to work with!


        Now let’s modify the 100 MHz dataset to remove the higher offset frequency compression as follows. The 18 dB Δ is as would be otherwise expected applying the 20log(N) rule.




        Entering the modified values in to the online calculator we add its calculation to the table as highlighted:




        This exercise confirms that the curve compression accounts for the significant difference in phase jitter

        measured between the 800 MHz and 100 MHz cases.


        The Noise Floor

        All of the traces flatten or get close to flattening by 20 MHz offset. So, what is the apparent or effective noise floor? Note that in general this will be some RSS (Root Sum Square) combination of the instrument phase noise floor and the DUT’s far offset phase noise. For example, if both the DUT and the instrument had an effective phase noise of –153 dBc/Hz at 20 MHz offset then the RSS result would be 3 dB higher or –150 dBc/Hz.


        If the instrument noise floor was well below the DUT's we would expect the spot phase noise at 20 MHz offset to decrease by 6 dB, for every division by a factor of 2, from that measured for the 800 MHz clock. But that is not what happened. See the table and accompanying figure below:


        Table 6.png


        Phase Noise.png


        The phase noise floor is not varying monotonically which suggest multiple factors may be involved. Reviewing the E5052B specs indicates that the SSB phase noise sensitivity should decrease slightly as the carrier frequency is lowered. Also, far offset phase noise from the DUT (Device Under Test) is typically dominated by the output driver’s phase noise and that’s unlikely to vary in this way. We are most likely running in to a combination of the instrument's "actual" phase noise floor as a function of input frequency plus aliasing on the part of the DUT. The Si5345's frequency divider edges can be regarded as sampling the phase noise of the internal clock presented to the divider. This factor is independent of the instrument. It is understood that aliasing can occur but quantifying the specific contribution due to aliasing can be problematic.




        This paper suggests that provided the noise BW of the input signal is > 4 x divider output frequency v0 then divided PM (Phase Modulation) noise will degrade via aliasing by 10log[(BW/2v0) +1]. The aliasing described primarily impacts the far offsets where we are interested.


        The authors write:

        "Aliasing of the broadband noise generally has a much smaller effect on the close-to-carrier noise

        because it is typically many orders of magnitude higher than the wideband noise."


        In these particular measurements, estimated noise floor degradation for the lowest carrier frequencies are plausible assuming a given BW and instrument noise floor. However, no one solution appears to accommodate all the data. It might require operating the device at the highest output frequency and then employing external dividers and filters to properly sort this out. Perhaps in some future post.


        Additional Reading

        While this month's post has concentrated on phase noise, it should be noted that divided spurs can be aliased or folded in the same way as the authors cited above discuss. One of my colleagues has demonstrated this also and I recommend his article for further reading.



        We have reviewed the impact that a phase noise instrument’s apparent or effective phase noise floor can have on both the phase noise curve and phase jitter measurement of sufficiently low frequency clocks. After you have worked with your DUTs and phase noise equipment for some time you will recognize what a typical phase noise curve will look like, the approximate phase noise floor of the equipment, and what are reasonable expectations for phase jitter. Certainly, for the cases above, we would take have to take phase jitter measurements below 200 MHz with a grain of salt. If in doubt, try a similar configuration at a higher frequency for comparison. You will only miss the secondary phase noise degradation due to any instrument noise floor variation and/or aliasing due to higher division factors.


        As always, if you have topic suggestions, or there are questions you would like answered, appropriate for this blog, please send them to with the words Timing 101 in the subject line. I will give them consideration and see if I can fit them in. Thanks for reading. Keep calm and clock on.




        1. The derivation here is adapted from a slim but information packed book by Dr. William “Bill” Egan

        called Frequency Synthesis by Phase Lock published in 1981. See section 4.5, “Effect of Modulation

        of a Divided Signal”, pages 75-76. (There is a later and much expanded edition of this book.) Dr. Egan

        has passed on but he was a great engineer, author, and teacher in Silicon Valley. He wrote several

        excellent, clear, and precise books on frequency synthesis, PLLs, and RF systems design.


        2. A. SenGupta and F.L. Walls, “Effect of Aliasing on Spurs and PM Noise in Frequency Dividers”, 2000

        IEEE/EIA International Frequency Control Symposium and Exhibition, pages 541 – 548.

        Retrieved from


        3. H. Mitchell, "Perfect Timing: performing clock division with jitter and phase noise measurements", EE

        Times, 8/25/2011. Howell's paper covers this topic from a different perspective with some additional

        detail using data from the previous generation Si5324. He also demonstrates spur aliasing by mixing the

        outputs of separate RF signal generators. Retrieved from

      • KRACK WPA2 Encryption Protocol Vulnerability

        Lance Looper | 10/292/2017 | 04:57 PM

        There has been significant press coverage regarding the KRACK attack on the WPA2 protocol used in most modern Wi-Fi systems. With the attack, the security of WPA2 becomes equivalent of using an open, insecure Wi-Fi network. Any service using secure protocols at higher level, such as HTTPS, TLS etc. are still secure.


        We are working on patches for our Wi-Fi products.


        In the meantime, the mitigation is to secure the implementations using secure application level protocols, such as HTTPS, TLS etc. This should not only be done due to KRACK, but also because that would protect against open Wi-Fi networks, spoofed access points, or monitoring from ISPs or governments. So all systems should be secured at the application levels regardless of KRACK.


        Links for how to use TLS / HTTPS:


        Links regarding the attack:

      • IoT Hero Revolar: Keeping Loved Ones Safe with the Tap of a Button

        deirdrewalsh | 10/283/2017 | 10:30 AM

        Silicon Labs recently had the opportunity to sit down with Andrea Perdomo to discuss the personal safety company she co-founded, Revolar. Perdomo, who immigrated to the U.S. from Colombia as a child, shares her personal inspiration behind the product and explains some of the design challenges she experienced launching a simple yet powerful IoT technology that alerts loved ones if the user is in danger.




        Can you tell us a little bit about your company Revolar?

        Revolar is a personal safety technology company. We created a small device that you clip onto your clothing, key chain, handbag, etc. The device is for those moments where you just need to connect with your loved one. The device is connected to your phone via Bluetooth. There are three different alert levels. The first is a “hey, I’m home or I’m safe” alert. Two clicks is a yellow alert, which is for when you are uncomfortable or just want someone to be with you virtually. And the third alert is for full blown emergencies. We launched our first product in 2015 and launched the new version in April of this year.


        What prompted you to create the technology and the company?

        My co-founder, Jackie Ros, and I were close friends before we started the company together. Jackie’s younger sister was the ultimate inspiration for Revolar. Her sister was assaulted twice by the age of 17. In both circumstances, her sister didn’t have time to reach for her phone and call for help. Jackie wanted to create a magic button that her sister could press that would let people know where she was and that she needed help. And that’s pretty much what we did. We realized nothing like this existed yet. There were products such as Life Alert and 24/7 trackers for your kids, but nothing in the middle. We had no technology background at all, but we figured out how to do it.


        I’m originally from Colombia and I moved to the U.S. for safety and security reasons after my grandmother was kidnapped for eight months. She’s OK now, but if she would have had Revolar, we would have known her last whereabouts and known something was wrong. Then we could have started looking sooner. Instead, we went a whole month without knowing where she was.


        What were the circumstances? Was she held for ransom?

        Yes, ransom. It was back in the 90s – everybody was getting kidnapped left and right. And my Dad said, “This is it, we can’t live here anymore.” So I’ve been surrounded by the mentality of “stay safe” or “don’t talk to strangers.” Moving to the U.S., it’s definitely safer here. But at the same time, Revolar is for those moments where you just can’t predict it. We started Revolar in Denver – just the two of us – and we slowly grew our team. I went to business school and I’ve always said you don’t know how to start your own business until you do it. We eventually figured it out and found a team of advisors and investors who believed in what we were doing.


        What kind of stories and feedback have you received from the users?

        We have learned that our customer base is broad – we have male and female users from every age group above 13 years old. So customization of the experience is important. Not everybody is the same – a red alert for one person might be totally different for someone who has food allergies versus someone who is a runner. So we started enhancing our software.  Now users can customize messages and change contacts for each alert level. We also learned that people were using Revolar just on the weekends or when they thought something would happen. So in our new version we created ways people can use the device regularly and not just when they need it. For example, the new version will beep so you can find your keys or phone. We also activated step-tracking for active users who want to use Revolar to count steps.


        That’s great you’re learning how people are really using it.

        Interestingly enough, people are using it for reasons that I never thought of. I kid you not, I know people are using it to let friends know what bar they’re at. Or if they go on a hike, they use it to show people what hike they went on. Or they take check-ins while they are shopping to remember where they were.


        Is there a way to aggregate the data about where people of certain ages congregate or use their devices most frequently?

        When we talk to police or governing bodies of cities or universities, we always get that question. They say, “You’re telling me that we will know when people are feeling vulnerable or uncomfortable?” A perfect example is if we’re getting a bunch of yellow or red alerts from a certain fraternity at a college campus. We know a lot of this information is sensitive and personal to our customers and we want to respect everyone’s privacy. But at the same time, if we can get our users to let us know why they are using Revolar, we can help people in the future.


        Can you tell us about the process of building the device?

        Our proof of concept was built by an engineer we contracted with in Colorado. Within three months, we had a functioning prototype. It was jankie and we had to unplug it to set off the alert. We also had to convert our phones to Androids because that was the only way to build the app.  We later brought on an advisor who was both an electrical and a mechanical engineer. In two weeks, he built the prototype we ended up using in the first version of our product. We then found an industrial designer to contract for us and that part was fun – making sure the design was pretty. Once we started the manufacturing process, our contract manufacturer brought on the CTO and started putting all of the pieces together.


        Was the design of the product a challenge since it hadn’t been done before? Or was it a process smooth?

        Oh, no. It was really hard. I remember every engineer I talked to said “Oh, that’s easy, we can do that.” But then there was always something. One of the challenges was size. The battery life was another challenge. And the button, making sure the button was concave enough to remove the risk of false alerts. And features – there were so many features we wanted, but we couldn’t compromise the size or battery life. Initially, we thought it would be a great idea to have four buttons. Then we learned how much it would cost and how much it would drain the battery. Most of the Bluetooth chips that existed at the time powered cell phones or sent  messages with high-bandwidth, and we didn’t need all of that. We ended up going with Bluetooth Low Energy because everything else would have taken longer to make. It took us over a year to have the final product.


        What specific Silicon Labs products are in the device?

        The Wireless Blue Gecko SoC. The product helped us achieve a longer battery life and create our small form factor.


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

        I think we’re going to start seeing  people consolidate IoT. Especially as we hear people say they don’t want to charge another thing – they want devices to do multiple things. Most people have no idea what IoT means – I’d say 80 percent of the world or more. I still run across people who don’t know what Bluetooth is – or what a wearable is. So although technology is moving fast, there is still a big gap in education. I also think we’ll see wearables and IoT in places that you would never imagine, such as clothing and handbags. I believe tech will become fashion. Probably not in the next 5-8 years, but in the next 20.





      • IoT Device Security: What Designers Need to Know

        Lance Looper | 10/279/2017 | 11:42 AM

        As the number of IoT devices hitting the market continues to explode, the pace of security threats mounting grows right alongside it. If security isn’t addressed seriously by embedded designers, the vulnerabilities of connected products could significantly stall or halt IoT market growth. That being said, security is a serious priority, not an afterthought.

        Fortunately, designers have many options on the best way to build security into connected product designs. Yet the process of building a highly secure IoT device is complicated and requires critical trade-offs by product designers. The trick is weighing the needs of the user and the limitations and strengths of the hardware and wireless infrastructure.

        Lars Lydersen, Senior Director of Product Security at Silicon Labs, just released a whitepaper titled, “Security Tradeoffs and Commissioning Methods for Wireless IoT Protocols,” which provides solid recommendations and guidance on the often perplexing task of commissioning wireless devices onto a network.


        The whitepaper provides a snapshot of some of the key lurking security threats that are relentlessly calculating new ways to hack into connected devices. Several examples mentioned include the passive listeners, who don’t block traffic, but instead listen for valuable data, or the Man-in-the-Middle (MITM) active attacker, who intercepts all traffic while maintaining a disguise to prevent the other communicator or device from knowing it’s talking to an adversary.

        In order for devices to combat these cunning and ever-shifting tactics successfully, a number of scenarios and trade-offs need to be taken into consideration by the embedded designer. For example, when securing wireless or wired links, a secret key must be provided between the devices. During this commissioning phase, strong authentication action must be made by the user, infrastructure or operations on the device side in order to avoid MITM attacks. But this approach can place unforeseen requirements on the device interface or online connectivity for the end device.

        This is just one example of the complexity involved in commissioning - the paper provides specific guidance on a variety of secure IoT approaches. Typically, three different types of commissioning schemes are available for designers. The whitepaper explores the details of these schemes, including permissive, which happens without authentication; a shared key, which allows the commissioning device and onboarding device to authenticate using a shared identical key; and the certificate-based commissioning scheme; which authenticates the key exchange using public key cryptography primitives.

        Today’s most popular IoT protocols include Wi-Fi, Bluetooth Low Energy, Zigbee and Thread. All of the protocols support out-of-band commissioning. Lydersen’s paper provides several specific recommendations for out-of-band commissioning, such as Near-Field Communication or details on how to derive a key from another standard.

        Overall, if you need a quick and informative review of commissioning wireless scheme options and the different levels of security available – this read is a must.

        New IoT security threats are a constant. Therefore, educating ourselves on the best security approaches to safeguard IoT must be, as well. Enjoy the whitepaper!