Official Blog of Silicon Labs

    Publish
     
      • Employee Spotlight – Marius Munder

        Lance Looper | 09/272/2017 | 10:00 AM

        This month, we’re highlighting Marius Munder, Senior Staff Applications Engineer. Munder began working at Telegesis in 2002 and officially became a Silicon Labs employee in November 2015 through the Telegesis acquisition. When he is not traveling to the High Wycombe site, he’s based out of his home office near Dortmund, Germany.

         

        spotlight-banner1.jpg

         

        Since the acquisition, Munder has enjoyed working with different business units and meeting new people on the Silicon Labs team. Munder says Telegesis’s culture was very similar to Silicon Labs and the main differences were at the project management level “where Telegesis used to have a certain nativity only a startup could afford.” Marius added the acquisition gave him and his coworkers incredible access to new resources in terms of people and information. His favorite thing about working at Silicon Labs is being able to work with a variety of people “allowing [him] to continuously learn and contribute first hand.”

         

        As a member of the Applications Engineering team, Munder interacts with some of Silicon Labs’ largest and most strategic customers. A typical day for Munder involves writing specs, hands on hardware and software work and of course, answering lots of e-mails! Earlier this year, because of his knowledge of the Zigbee stack, Munder was asked to provide customer support during an “extremely pressure packed situation,” said Senior Director of RF Stacks, Bob Power. He added, “Marius brought a tremendous amount of technical expertise, along with a very calm demeanor and provided tremendous value.”

         

        When asked if he could have one wish granted, what would it be and why, Munder said, “1,000 more wishes. No, seriously, I would wish that I didn’t even need that one wish in the first place, because that would mean that everybody on the planet would live in peace and happiness already.”

         

        Marius Munder, we’re proud to recognize you in our June Employee Spotlight. Thank you for everything you do for Silicon Labs!

         

        Marius Munder photo_Blog.jpg

      • Delivering the Industry’s Best Jitter Performance and Power Efficiency on a Single Chip

        Lance Looper | 09/270/2017 | 10:00 AM

        This week we’ve released the new Si522xx PCIe clock generators, bringing best-in-industry jitter performance and energy efficiency to PCI Express® (PCIe®) Gen1/2/3/4 applications. This new clock family delivers on the stringent requirements of PCIe Gen 4 and Separate Reference Independent Spread (SRIS) standards with 20 percent jitter margin to spare, and its jitter performance (0.4 ps RMS) also provides up to 60 percent jitter margin for PCIe Gen 3.

         

        The PCIe standard, originally developed as a serial interconnect for desktop PCs, and has become popular in blade servers, storage equipment, embedded computing, IP gateways, industrial systems, and consumer electronics. High-output clock generators like the Si522x family reduce the number of buffers needed as data bus usage expands in these types of systems. Designed specifically for clock-distribution-intensive applications, the Si522x family supports up to 12 outputs from a single device. This higher output count per device reduces BOM cost. The clocks’ output drivers take advantage of our innovative push-pull HCSL technology, eliminating external resistors required by conventional constant-current output drivers.

         

        Additionally, internal power filtering prevents power supply noise from affecting jitter performance while reducing component count, saving about 30 percent of board space compared to competing solutions.

         

        Developers designing battery-powered applications like digital cameras are especially concerned about power consumption. The 2-output Si52202 clock is optimized for low-power 1.5 V to 1.8 V applications, offering the lowest power consumption for PCIe applications. Packaged in a small 3 mm x 3 mm 20-pin QFN, the clock is also 45 percent smaller than competing solutions.

         

        For more information, visit www.silabs.com/pcie-learningcenter.

         

         

         

      • Timing 101: The Case of the Ouroboros Clock

        kgsmith | 09/264/2017 | 10:00 AM

        Hello and welcome to another Timing 101 blog article.  

         

        In this post, I will go over an interesting and curious clock chip feedback arrangement that comes up from time to time. It can arise accidentally, or as an attempted recovery or test mode, but should generally be avoided as explained. Further, understanding the Ouroboros clock might help explain some odd behavior in a complicated timing application. Before diving in to exactly what I mean by an "Ouroboros" clock, let's review some basic clock switching terminology and the standard input clock switching configuration.

         

        Some Basic Clock Switching Terminology

        Clock chips often support switching from one input clock to another based on some qualifying criteria such as LOS (Loss of Signal) or an OOF (Out of Frequency) condition. Here’s the terminology most often used:

         

        Freerun Mode:

        Output clock based on an

        attached crystal, or other resonator, or substitute external reference clock. The output clock's frequency stability, wander, and jitter characteristics are determined by the chip's crystal oscillator for example, independent of an input clock.

         

        Holdover Mode:

        Output clock based on historical frequency data of a selected input clock and employed when the input clock is lost and no valid alternate is available.  Usually historical data must be collected over some minimum time window to be considered valid. The frequency accuracy is only as good as the data collected.

         

        Locked Mode:

        Output clock frequency and phase locked to a selected input clock, i.e. normal operation.

         

        The Standard Input Clock Switching Configuration

        Consider the illustration in the figure below where two jitter attenuator clock ICs are cascaded. This could be for additional jitter attenuation or for optimizing frequency plans and distribution. For the purposes of illustration, the devices are depicted as very simplified Si5345 block diagrams. In this figure there are two input clocks supplied to Device #1, IN0 and IN3. In typical applications one clock may be regarded as the "primary" clock and the other as the "secondary" or backup clock. The primary clock might be recovered from network data while the secondary clock relies on a local oscillator. If the primary clock fails or is disqualified by LOS or OOF, then the clock chip switches to the secondary clock. This is usually intended to keep "downstream" devices up and running.  If the primary clock returns and is valid then the clock IC may revert to it, or not, depending on the option selected.

         

        The presumption here is that as long as either of these two clocks is present then a valid locked mode clock will be yielded at OUT0 supplying an input clock to downstream Device #2.  In fact, if both input clocks to Device #1 were lost the device could go in to holdover mode, as described above, or even freerun mode, and still yield a temporary reasonable output clock.

         

        Clock Config.png

         

         

        The Ouroboros Clock Configuration  

        In standard applications, downstream clocks are not fed back to upstream clock inputs. Rather they are usually scaled or jitter attenuated versions of upstream independent stable or data-derived clocks.  

         

        But what if we did attempt the configuration shown in Figure 2 below?  In this case, one of the outputs of downstream Device #2 is being fed back in to upstream Device #1. This might be intended as a temporary expedient backup clock.

         

        Ouroboros.png

         

        Now what happens when we lose our primary clock IN0 as suggested by Figure 3 below? The secondary or backup clock IN3 to Device #1 relies on the output of Device #2. Note that this is just a locked version of Device #1's output.  We generally do not do see this sort of connection with one device but it is proposed occasionally with applications involving 2 devices. Even then, engineers will usually intuit that we are trying to get away with something.

         

        Clock Congif with Arrows.png

         

        This is the Ouroboros clock configuration. (And yes, it does sound almost like a Big Bang Theory episode title.) The Ouroborus clock configuration is so named because its feedback resembles the mythological symbol for a snake chasing (or biting) its tail.  According to the Wiktionary entry the word comes from the Greek words ourá for "tail" and bóros, for "devouring or swallowing".  See the illustration below in Figure 4. It is an ancient symbol for cyclic infinity and the term fits this application.

         

        Ouroboros Snake copy.png

         

        A Gedanken

        Let’s consider a simplified gedanken or thought experiment consisting of a single basic PLL.  Then assume that it has successfully been placed in to the Ouroboros configuration as follows in Figure 5 below.

         

        Gedanken.png

         

        Now we can think through the probable consequences. If everything is ideal and there is no PFD (Phase Frequency Detector) error output then the situation is at least marginally stable. However, even ignoring loop noise, it is most likely in a practical PLL that there is a fixed phase offset between the clocks presented at PFD (+) and PFD (-). In normal PLL operation the VCO can be adjusted so as to frequency and phase lock the output clock to the independent input clock. In the Ouroboros configuration, there is nothing the VCO can do to reduce phase error.

         

        Assume the output clock is measured with phase just a little bit faster, at PFD (+) versus PFD (-). The loop will then attempt to track for that by tuning the VCO to a higher frequency. But a relative phase difference will still be present. So, the loop will continue attempting to correct for the measured phase error until the VCO is “railed” at its highest frequency.  Note that, to generalize, the VCO could be tuned either higher or lower in frequency depending on the polarity of the phase difference. All that matters is that a phase delta be seen by the PFD that leads to a runaway condition.

         

        Trying to accomplish this with two Si5345s is just this problem writ large, albeit with further complications due to clock validation and switching logic. In addition there will always be slight part to part variations in output frequency and calculated HO frequency. These can also drive the PFD in one direction or another where 2 separate devices are involved.

         

        Lab Confirmation

        So, what really happens in the lab? Consider a project plan with these attributes:

        • IN0: 100 MHz
        • IN1: 100 MHz
        • OUT0: 100 MHz
        • Nominal Bandwidth: 100.000 Hz
        • Fastlock Enable Off
        • Ramped Exit from Holdover
        • OOF IN0 and IN1:
          • Assertion Threshold 100 ppm         
          • De-assertion Threshold   98 ppm

         

        Now take such a project plan and apply it to 2 Si5345 evaluation boards, configured as shown in the second figure above, except using IN1 instead of IN3 as the secondary or backup input clock. 

         

        Apply a signal generator to Device #1 IN0 and let both boards run until HOLD_HIST_VALID is true.  What happens when you remove the 100 MHz input clock at IN0?

         

        Initially only LOS[0] is reported by Device #1. Otherwise all is well. However, the output clock frequency from Device #2 starts ramping in frequency (it can be ramping up or down in general but happened to be ramping up in my particular experiment.)

         

        Eventually the output clock from Device #2 being used as the backup input clock goes far enough out of frequency that it fails Device #1’s OOF criterion. The settled conditions are as follows:

         

        • Device #1 goes in to holdover mode
        • Device #2 operates in locked mode.

         

        Note that in general there is no reason why the devices could not be stable with each in the opposite states. Our experience has been that most of the time there is a preferred set of states but you will see the alternate set from time to time, almost as if there is a chaotic element to the results.

         

        In this case, the Ouroboros configuration didn’t really buy us anything except perhaps a little time.  However, note that the output frequency was ramping the entire time until Device #1’s OOF[1] asserted and Device #2 still ends up relying on Device #1 HO clock. That’s just one potential issue for this impractical configuration. But there’s another potentially worse effect.

         

        Ouroboros Oscillation

        This configuration can also result in a positive feedback system that can be made to oscillate, leading to puzzling and odd behavior.  In particular, this can happen if one of the devices can be made to enter and exit HO.  For example, this phenomenon can be observed if the project plan OOF specs are tightened as follows.

         

        • OOF IN0 and IN1:
          • Assertion Threshold 000 ppm      
          • De-assertion Threshold 9375 ppm

         

        Now the two devices will interact with each other and may never settle. Below is an annotated frequency plot of Device #2 output clock data from a logging frequency recorder. You can see that the Device #2 output frequency is slowly oscillating frequency-wise with a varying period on the order of 8 or 9 seconds.

         

        Frequency vs Time copy.png

         

        There are three features noted on the plot above about the state of Device #1 as Device #2's output frequency varies:

        1. Device #1 is in holdover or HO mode
        2. Device #1 is in ramped exit from HO
        3. Device #1 is entering in to HO

        During this time period no alarms are issued by Device #2. This state can last indefinitely. I started one trial of this experiment on a Friday afternoon and it was still cycling on Monday morning.  The devices can even exchange roles as to which one is in the HO state!

        Having a device constantly entering and exiting HO is even worse than simply going straight in to HO.

         

        Conclusion

        The bottom line is that the Ouroboros clock configuration either does nothing useful except delay entering HO or can even trigger an oscillation which produces repetitive wander in the output clock. Downstream clocks should generally stay downstream.

         

        I hope you have enjoyed this Timing 101 article and will understand the implications if you spot an Ouroboros Robot Happy

         

        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,

        Kevin

      • IoT Hero Q-Free Moves Excess Traffic Off-Road by Helping People Park Faster

        deirdrewalsh | 09/262/2017 | 10:00 AM

        Intelligent transportation system provider Q-Free has been working in the transportation management market for the past 30 years. Based in Norway, the global company plans to roll out a new parking IoT product this fall. According to an INRIX study published in USA Today, American drivers spend 17 hours a year searching for parking spots and a whopping $20 billion annually in garage fees, parking tickets, and fuel burned while searching for a spot. Silicon Labs recently had the chance to sit down with Q-Free Project Manager, Brage Blekken, to hear more about the new sensor parking product.

         

        Banner-qfree.jpg

         

        So for people not familiar with Q-Free, can you give us a brief overview of the company?

        Q-Free delivers a broad portfolio of intelligent transportation systems for the global market. Our systems include solutions for electronic road tolling (DSRC systems), vehicle counters and classifiers, traffic control and surveillance technologies, and parking management solutions. Our product installations can be found in more than 20 countries around the world.

         

        How did the company get started?

        Our company started in the eighties after building electronic toll collection technologies in Norway. Since then, we have greatly expanded our product offering to include numerous intelligent transportation technologies, with recent expansions into Europe, Asia, South America, and we are now entering North America. We’ve built some of the largest nationwide road tolling systems found in the world today.

         

        Can you tell us a little bit about your parking sensor technology?

        We actually used technology from our toll road technology products and applied it to our parking sensors. Over the past five years, we’ve been offering indoor parking technology, which are systems you find in indoor parking lots, such as shopping malls. These systems hang over the parking space to detect, track, and monitor parked cars.

         

        Now what is the IoT parking technology you are planning to launch later this year? How does it work?

        Our new smart parking sensor product helps users find parking spots on the street level by using wireless technology. Most people don’t know this, but typically 20 percent of the traffic on the roads in an urban area is generated from people looking for parking spots. So our product is essentially removing excess traffic off the roads, which is Q-Free’s primary mission as a company – remove the Q’s (vehicle flow), or the excess traffic flow on the road.

         

        The product uses radar-based technology to sense with 99% accuracy whether a vehicle is present in a parking space. The sensor transmits the information regarding parking space availability using Narrow Band (NB) IoT communications, which can be sent to a variety of outputs, such as Variable Message Signs located near the parking site, and it can also go straight to end-users through websites or mobile phone applications. The neat thing about NB-IoT is it allows everyday objects to have Internet connectivity to communicate their status and needs with end users.

         

        Is there a product like this on the market right now already?

        The parking sensors currently out there today have an accuracy limitation, which can negatively impact a person’s parking experience. Our new parking NB-IoT product greatly improves the accuracy of the parking guidance for users. We also have a rock solid dual communication interface, which is a real edge for us because it gives sensors the ability to communicate directly over the existing 4G telecom networks or proprietary ISM radio whenever needed. The NB-IoT product uses existing communication infrastructure, which will be a huge step in the right direction towards realizing next generation smarter city connectivity.

         

        What Silicon Labs product is used in this product?

        The Silicon Labs EZR32 Wonder Gecko MCU is used for both sensing and wireless communication.

         

        What kind of design challenges did you have when creating the product?

        The combination of the high accuracy components with extreme low power consumption was our primary challenge when building this product.

         

        The sensor is expected to live for a minimum of 10 years without swapping batteries. This means we cannot afford to use more than a few microamperes on average while maintaining the high performance data link and intensive signal processing required to operate the radar circuits.  

         

        We also have been an early adopter of the NB-IoT standard. Since last autumn, one of the world’s first live mobile networks was built right outside of our headquarters in Trondheim, Norway. I’ll say that was a truly exciting moment when this ultra-low power sensor got access to the powerful 4G network using no more battery resources than a normal Bluetooth connection would have required.

         

        Can you tell us why you picked Silicon Labs as the supplier?

        The main challenges for us in building this product were related to extreme low power consumption. Silicon Labs is one of the top players in the world for low power electronics, and also wireless communications components. That’s the main reason we selected Silicon Labs, you have the top solutions for our specific design challenges that help us design the right product for the market.

         

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

        Look at Internet access on cell phones – everyone has it now, though that was not the case 5 or 10 years ago. I think IoT will definitely go the same way as mobile phones - everything in our lives will all be connected to the Internet. And people will not be thinking about the technology behind it, they will just expect it to be there.

         

        That means that we as solution providers need to converge towards standards for wireless IoT connectivity, which ensures easy interoperability between devices and online services. My bet is that the new low power IoT standards, NB-IoT and LTE Cat M1, which right now are being released into existing 4G and the upcoming 5G networks, will be one of the standardized ways to connect our devices to the Internet.

        Light_park_and_ride2.jpg

      • Silicon Labs Bluetooth Implementations Unaffected by BlueBorne

        Lance Looper | 09/257/2017 | 10:39 AM

        A collection of Bluetooth vulnerabilities named “BlueBorne” has just been made public by the security research company Armis. The vulnerabilities are not in the Bluetooth standard itself, but rather in the specific implementations of the Bluetooth standard. The Silicon Labs Bluetooth implementation is different from the affected implementations. Therefore, products based on our Bluetooth software are immune to BlueBorne.

         

        This has been disclosed responsibly, which means that vendors have had time to issue security patches. Therefore, please update and patch all Bluetooth-products based on Android, Windows, iOS or Linux! And if in doubt, follow best practice and update all smart products regardless of protocol and software platform.

         

         

        As a note, fighting BlueBorne shows the importance of being able to software upgrade connected devices, as discussed here:

        http://www.newelectronics.co.uk/electronics-technology/the-iot-requires-upgradable-security/156211/

         

        References:

        https://www.armis.com/blueborne/

        https://www.wired.com/story/turn-off-bluetooth-security/

        https://techcrunch.com/2017/09/12/new-bluetooth-vulnerability-can-hack-a-phone-in-ten-seconds/

      • September 2017 Member Spotlight: neal_tommy

        Siliconlabs | 09/248/2017 | 11:15 AM

        We are featuring one of the Silicon Labs Community members who is active or new in the community on a monthly basis to help members connect with each other.

         

         

        Meet our September member of the month: neal_tommy

         

        0,6,312,318.jpg

         

        Q: Congrats on becoming our featured member of the month! Can you introduce yourself to our community members?

         

        I am a Robotics Engineer living in Johannesburg, South Africa. I've always been interested in engineering, perhaps initially from young days dismantling old VCR players. I'd keep all the parts and try to build things from it. I don't do much engineering work as my day to day career, so my hobby keeps the robotics engineering alive.

         

        Q: How did you know about the Silicon Labs Community?

         

        I bought a Thunderboard Sense, and needed some help, and managed to find lots of answers online in the community. They've been a great help in the building of a project using the Thunderboard Sense Board. 

         

        Q: What features, products, services would you like to see in the future from Silicon Labs?

         

        More hobbyist type development boards that open up much of the software and hardware from a sensor, network and perhaps AI point of view. I know you are doing much of this already as the Thunderboard Sense (and software / resources) are already impressive.

         

        Q: What advice would you give to someone new to the community?

         

        Ask the questions you think are too stupid to ask. The community is vast, experienced and helpful. Yes, we were all newbies once upon a time. There are lots of people out there so more than likely there is someone at the same hurdle you are. 

         

        Q: Thanks for answering the questions. Any final comment?

         

        I'm looking forward to incorporating more Silicon Labs products into my upcoming projects and look forward to seeing the new products as they come out.