Official Blog of Silicon Labs

      • 20th Anniversary: Spotlight on Silicon Labs in Singapore

        Lance Looper | 04/120/2016 | 10:02 AM

        This gleaming modern city by the ocean is represented by a mythical creature with the head of a lion and the body of a fish – the Merlion. The body symbolizes Singapore’s beginnings as a simple fishing village, while the head represents the city’s original name, Singapura, which means ‘lion city’ in Malay.

        One of Singapore’s most famous landmarks is Merlion Park where the famous Merlion statue, 8.6 meters tall and weighing 70 tons, looks out over the bay.


        Fun Facts

        • Locals joke that there are four seasons in Singapore: HOT, HOTTER, WET, and WETTER
        • It’s a melting pot of cultures: 74.2% Chinese, 13.3% Malay, 9.2% Indian, and 3.3% other
        • Four main languages are spoken English, Mandarin, Malay and Tamil

        The city-state is located just 1.5° north of the equator and consists of a diamond-shaped main island as well as more than 60 small islets – a total land area of just 445 square miles or 716 kilometers. Yet in that small area, Singapura still roars! Approximately 5.4 million people live in Singapore.


        It has long been recognized globally as a center of business and technology, Silicon Labs expanded its operations to Singapore in 2004, and it is now our international headquarters with more than 150 employees. Our employees there perform a range of functions including, design engineering, product testing, manufacturing support and process planning, and corporate support.


        Singapore Office.png


        A Fast-Paced Environment, Great People


        Our staff tells us what it’s like to work for Silicon Labs International. Kenneth Kong, Supplier Manager since 2008 says, “I find the work challenging and dynamic. Every day when I come into the office, there will be different problems to solve – both technical and non-technical. The challenge of meaningful work offers constant opportunities to develop world-class skills and an opportunity to raise myself to the next level.”  Suby John Pellissery, a Design Engineering Manager loves the work she does, “Integrated Circuit (IC) design is my passion. Every day I get to work on new design areas, interact with experts and learn new things. And it’s a nice experience to see your hard work back in the form of this tiny IC!”


        Sheila Marie Galang Letun, Staff Packaging Engineer, tells us, “There is never a dull moment in my job. I love it because it gives me both the chance to apply and share my experience and at the same time, learn new things every day.  There is always a general sense of openness where you can speak to your colleagues or to the management team about your thoughts regardless of your level or position. You’ll get a sincere and honest response. This shows me that respect and trust in each other is always here at Silicon Labs.  Sheila goes on to say, “since the company is small, the people mostly know each other so task on hand can be accomplished fast, you get answers quickly, move things easily. In my opinion, Silicon Labs is very efficient and cultivates responsibility in each employee because they are empowered and trained to do their job right.”


        In addition to a stimulating work environment, our staff tells us that when they aren’t at work, Singapore offers countless things to do and see. Here are a few highlights:

        • Singapore Botanic Gardens. Not to be missed, you can stroll through old growth rain forest or marvel at the National Orchid Garden, with over 3,000 different types of orchids.
        • Amazing Wildlife Reserves. Go on a Night Safari and see the world’s first safari parks for nocturnal animals. Jurong Bird Park boasts some of the largest free-flying aviaries in the world. See the giant pandas, Kai Kai and Jia Jia at the River Safari or visit the renowned Singapore Zoo.
        • Street Food. A street food paradise, look for spicy multi-ethnic dishes like the delectable unofficial national dish, Chicken Rice, or a Silicon Labs employee favorite, Chili Crab. If you don’t know where to start, Food Prowlers can take you on a guided tour of the best in Singapore’s local food spots.


        For more information on Singapore, go to the official tourist & travel guide, YourSingapore – and next time you visit, say hello to our coworkers!


        And don’t forget to read the previous post in this series here.


      • Praise for Silicon Labs Customer Support

        Siliconlabs | 04/118/2016 | 07:57 AM



        Like anyone else, we love hearing about the things that set us apart, and our customer support has been one of our most valuable resources. Regardless of your challenge, our customer support team can probably help. They're there when you need a question answered, or a problem solved. They're there to help you out, give you suggestions, and improve your experience with our products. But don't take our word for it, the customer support team at Silicon Labs has received acclaim across the community!


        Check out some of the comments left by our community users:


        "product support trendsetters...

        You folks are setting the trend on product support. I've been designing products for over 20 years, and this is by FAR the best product support that I've ever seen.

        Congratulations on a job exquisitely done. Makes me want to use your products whenever the opportunity arrises. I'll pass the word on to the other engineers also. Keep up the good work.

        You guys get 5 stars ***** "  **


        "With the kind help of Silicon Labs support, I've got a working project." **


        "I was also writing my problem to the SiLabs Support (They answered quite quick, excellent service)"


         "Excellent! Thank you for your detailed response. Good technical support is so rare to find these days."


        "That was very in-depth answer. Thank you for that." **


         "Thank you for the excellent support!" 


        Have a question for the support team? Create a support request here and we'll help you as best as we can! 


        And don’t forget our active community of more than 20,000 engineers and developers are ready to help you as well!




        ** Posts were migrated to the new Silicon Labs forum from older forums and therefore show Silicon_Labs /BluegigaAdmin as authors 

      • Chapter 11.2: Control RGB LEDs with an LED Controller Part 2

        lynchtron | 04/117/2016 | 05:59 AM



        In the last section, we covered some LED driver basics and how to limit the current of an LED without the need for inline current limiting resistors.  In this section we will connect the TLC5940 LED driver breakout board to the Starter Kit and then begin to develop a serial interface software driver.  We will also define some data structures to help deal with the serial interface data stream.


        Hardware Connections

        In order to communicate with the TLC5940, we need eight wires: Vcc, Ground, a data pin, a clock pin, a pin to latch the serial data called XLAT in the specification, a pin to select the mode called VPRG, a global enable pin called BLANK, and a pin to serve as a grayscale clock, GSCLK.  We can choose to use any of the UART, LEUART, or USART peripherals on the MCU.  I will choose USART1, Location #1, since it is available on the header pins of the Wonder Gecko Starter Kit.  We have used these pins in earlier lessons for SPI and serial data.  Connect the board as follows:



        Note that we are only using two pins of the four available on USART1.  We will not be using US1_RX or US1_CS.  There is no rule that we have to use all four pins of a peripheral.


        If you wanted to connect a second TLC5940 breakout board in series with the first, you would simply solder the pins on the right side of the first board to the pins on the left side of the second board.  You could repeat this over and over to add more and more individually-addressable channel capacity to the design.  We will talk about how that can be accomplished in software later in the chapter.


        When I first found this part and reviewed the spec, I thought that it only required three wires because of this line: “Only 3 pins are needed to input data into the device.”  But only after I began to experiment with the chip (and could not get it working) did I figure out that in addition to the three pins necessary to load data into the device, namely SIN, SCLK, and XLAT, you need three more pins to actually perform the grayscale function: VPRG, BLANK and GSCLK.  I was really surprised.  This is exactly why you should build breadboard prototypes with any new parts before you spend money on a PCB!


        Another surprise that I found upon working with this board is that it was getting hot after being connected to the Starter Kit.  The problem was that Sparkfun decided to run VPRG through a “solder jumper trace,” which is way to connect the VPRG pin to ground but allow you to later cut the trace if you decide to control that line from the MCU.  I had assumed that the trace would be open by default, and they would leave it up to me to populate a resistor to close the connection to ground.  So when I drove PD3 high, it was being connected to ground on the TLC5940 breakout board.  Once I cut the trace, the problem was solved, and VPRG is now able to be controlled by the MCU.


        You must cut this trace on the back of your TLC5940 breakout board to use the code for this chapter.  If you don’t, your board will get slightly warm, and you won’t be able to control the dot compensation (channel current control).




        Peripheral Software Configuration

        We are going to configure all pins with code rather than using the Configurator tool to generate the code for us, just as a succinct reminder of what is needed to activate the GPIO pins.  Remember, whenever we want to activate a peripheral, we need to do the steps listed below.  The order is important.  If we don’t enable the peripheral clocks before we configure the peripheral, the peripheral will not receive any of the configuration register writes. If we route the peripheral through to the GPIO before configuring the peripheral, then we will could get some glitches on the GPIO pins as the peripheral is activated.  In summary:


        • Enable the GPIO clock
        • Enable the peripheral clock (in this case, USART1)
        • Configure and enable the peripheral
        • Route the pins used by the peripheral through to the GPIO
        • Configure the pins used by the peripheral in the GPIO (push-pull, input, etc.)

        Here is the resulting code to enable the USART and GPIO peripherals:



        #define CONTROL_PORT                            gpioPortD
        #define XLAT_PIN                                1
        #define VPRG_PIN                                3
        #define BLANK_PIN                               4
        #define SIN_PIN                                 0
        #define SCLK_PIN                                2
        #define GSCLK_PIN                               7
              // Turn on the peripheral clocks       CMU_ClockSelectSet(cmuClock_HF, cmuSelect_HFXO);       CMU_ClockEnable(cmuClock_GPIO, true);       CMU_ClockEnable(cmuClock_USART1, true);         // Configure the USART peripheral       USART_InitSync_TypeDef init = USART_INITSYNC_DEFAULT;       init.baudrate = 50000;       init.msbf = true;       // MSB first, per the TLC5940 spec       USART_InitSync(USART1, &init);         // Route the peripheral to the GPIO block       USART1->ROUTE = USART_ROUTE_TXPEN |             // US1_TX                           USART_ROUTE_CLKPEN |        // US1_CLK                           USART_ROUTE_LOCATION_LOC1;  // Location #1         // Configure both the USART and control pins in GPIO       GPIO_DriveModeSet(gpioPortD, gpioDriveModeLowest);       GPIO_PinModeSet(CONTROL_PORT, SIN_PIN, gpioModePushPullDrive, 0);       GPIO_PinModeSet(CONTROL_PORT, SCLK_PIN, gpioModePushPullDrive, 0);       GPIO_PinModeSet(CONTROL_PORT, XLAT_PIN, gpioModePushPullDrive, 0);       GPIO_PinModeSet(CONTROL_PORT, VPRG_PIN, gpioModePushPullDrive, 0);       GPIO_PinModeSet(CONTROL_PORT, BLANK_PIN, gpioModePushPullDrive, 0);       GPIO_PinModeSet(CONTROL_PORT, GSCLK_PIN, gpioModePushPullDrive, 0);


        LED Packet Data Structure

        The TLC5940 implements a shift register that expects an exact 96- or 192-bit serial data stream in order to program the current limits (dot correction) and PWM values (grayscale) for all channels.  The type of serial stream at the input to the TLC5940 (dot correction versus grayscale) is selected with the VPRG pin.  The dot correction fields are 6 bits multiplied by 16 channels, which gives us the 96 bits.  The grayscale fields are 12 bits multiplied by 16 channels, which gives us the 192 bits.


        The bit sizes for grayscale and dot correction are a little problematic for us.  They are not nice byte-sized values that we have come to know with the uint8_t and uint16_t data types that we have used on the USARTs thus far.  If we were to store the 6-bit values as uint8_t and the 12-bit values as uint16_t, then transfer these values into the USART peripheral, the result would be padded with extra zeroes, which would not work for this chip.  Things need to be packed into a serial stream exactly as the TLC5940 specification dictates.


        Instead, we will define a structure that has bitfields.  These bitfields don’t guarantee that the values will be stored in memory in the nicely packed structure that we want, but they will take care of truncating any values stored in the structure for us.  They also remind us of the size of each field that the TLC5940 expects.


        #define MAX_CHANNELS          16
        #define DC_BIT_LEN            6
        #define GS_BIT_LEN            12         
        // Structs for LED driver
        typedef struct LED_bit_fields
        {                             // Number after colon is field width
              uint8_t dot_correction : DC_BIT_LEN;
              uint16_t grayscale      : GS_BIT_LEN;
        } LED_data_struct;
        typedef struct LED_stream
              LED_data_struct channel[MAX_CHANNELS];
              bool mode;
        } LED_stream_struct;
        LED_stream_struct stream;



        Warning:  There is a compiler directive called “packed” that will help save memory space but does not guarantee that the structure will be stored in the correct order in memory, because the way that the C compiler packs the structure is not always predictable.  Don’t rely on any specific ordering; instead, use shifts and masks to build the final serial data stream.  We will cover how to do that in the next section.


        With the above code, I have created my own type called LED_data_struct, which is then used inside of another new type definition that is called LED_stream_struct.  This enables me to create a single variable that will hold all of the programming data for the TLC5940 in a single top-level global variable called stream.  I can now set the stream with this kind of syntax:


                stream.mode = mode;

      [channel_number].grayscale = grayscale_value;

      [channel_number].dot_correction = dot_correction_value;


        In the next section, we will complete the LED software driver and use it to bring some light to our test LEDs on the breakout board.



      • Austin's First Hackaday Meet-Up

        Lance Looper | 04/116/2016 | 01:28 PM

        Good ideas are contagious the saying goes, and The Hackaday Prize is a competition where you can test and spread your great ideas. On April 23rd the global Hackaday brainstorming and kick-off session launched, and in Austin several hacker and maker spaces came together at Silicon Labs to socialize, collaborate, and test ideas that could turn into impactful projects.


        Over the years this friendly competition has become synonymous with “creating for social change”, and by using hardware, coding, scientific, design and mechanical abilities, designers create prototypes that affect people's life.



        Austin's first Hackaday meeting ready to kick off.


        Over the course of several months, you can participate in several technology challenges, and every 5 weeks you could be expanding the frontiers of knowledge and engineering. On October 10th, the top 100 projects will reviewed by the Hackaday judges who will choose the top 5, who compete for the grand prize of $300.000 USD



        Attendees brainstorm how to use Silicon Labs' demo designs with temperature, accelerometer, and other sensor inputs pair with Bluetooth and cloud services to create sustainable products


        To help you turn your ideas into working projects, Silicon Labs offers several building blocks that you can use throughout your prototyping phase . These components range from sensors for heart rate, UV light, proximity sensing, humidity and temperature sensors, to energy efficient 8-bit and 32-bit embedded microcontrollers with loads of functionality, to wireless connectivity devices for Bluetooth or mesh networks. 


        Speaking of cool projects, check out James Langbridge's guided tour of the Blue Gecko Wireless Starter Kit.

      • Bluetooth BLE Beacon Standards from iBeacon, Eddystone, and AltBeacon

        Lance Looper | 04/116/2016 | 10:00 AM

        Bluetooth beacons are taking off. They enable “proximity-aware applications” for customers, businesses, and industrial environments.


        • End customers benefit through instant coupons and tailored offerings based on where they are.
        • Businesses benefit through improved visibility to customer buying habits and increased loyalty.
        • Industrial companies benefit through improved asset monitoring and utilization.

        The possibilities are endless, and beacons are set to transform our world. But before they do…How are they standardized and how do their advertising packets work? Bluetooth beacons are not actually a Bluetooth SIG standard. Instead they are what could be called “Pseudo-Standards,” or formalized formats for beacon applications headed up by a large provider or group of companies.


        Today three “pseudo-standards” have critical market momentum:

        All three pseudo-standards use the BLE broadcast methodology of putting advertising packets on BLE’s channels 37, 38 and 39 to avoid conflicting Wi-Fi traffic in the 2.4 GHz Industrial, Scientific and Medical (ISM) unlicensed band.


        Bluetooth Beacon Callout1.png


        Further, each pseudo-standard then uses the structure of the BLE advertising to embed their own formats and data. The same packet is generally sent on all three of the advertising channels every time the beaconing device advertises, making it more likely that a BLE receiver / scanner will pick it up. Once received, the scanner determines if the packet content is decodable and relevant, and then takes corresponding actions.


        Within the advertising packet, the data payload is structured as one or more [length, type, data] triplets.

        • The length field defines the combined size of the subsequent type and data fields;
        • The type field designates whether the data is a name, a service UUID, a Universal Resource Identifier (URI), or one of many other defined data types; and
        • The packet data is where beacons take the structure a step further, defining a sub-structure inside the data field to determine the various pseudo-standards.


        Bluetooth Beaconing callout2.png


        Both advertising packets and data packets use the same format. Beacons follow the standard advertising packet format, but include an embedded data payload for one or more of the pseudo-standards.


        Apple’s iBeacon

        Apple was an early beaconing adopter with its iBeacon. The iBeacon term is trademarked by Apple, and vendors who want to sell iBeacon products or use the iBeacon logo must obtain a free license from Apple. The iBeacon specification and other developer resources can be downloaded from the Apple Developer website.




        iBeacon specifies a 30 byte packet which must be broadcast on 100 ms intervals (although iBeacon OEMs don’t always seem to adhere strictly to the 100 ms requirement). iOS Apps which use the Core Location framework can ask the iOS to continuously monitor for beacon-region-crossing events, i.e., entering or exiting the proximity of an iBeacon defined by the UUID, Major and Minor fields. The iOS monitoring takes place whether the app is running or not, and can even trigger a closed app to launch. Monitoring only works when the user has enabled Location Services for the corresponding app.


        Google’s Eddystone

        Eddystone is an open-source, cross-platform beacon format from Google. It supports both Android and iOS devices. Unlike other beacon standards, it defines several different frame types which can be used individually or in combination:

        • Eddystone-UID which broadcasts a unique beacon ID;
        • Eddystone-URL which broadcasts Uniform Resource Locators (URLs);
        • Eddystone-TLM which can be used to broadcast telemetry (health and status) data about the beacon itself; and
        • Eddystone-EID which uses ephemeral (short lived) identifiers for beacon applications requiring more security. The specification for this frame format has not yet been released.

        Eddystone logo.png

        The Eddystone-URL frame enables mobile platforms to offer web content based on proximity without requiring an app to be installed, enabling what Google has dubbed The Physical Web, or the “ability to walk up and use anything.” Eddystone is already supported in Chrome for iOS, and will be supported in Chrome for Android beginning with version 49. With the Chrome Today widget, users can access web content relevant to their surroundings, and receive notifications when encountering beacons.


        Beaconing Callout 2.png


        The Google Eddystone GitHub page provides the Eddystone Protocol Specification along with tools and open source code examples, and the Google Developers forum provides more information about the Google beacon platform.



        Radius Networks defined the AltBeacon specification in an attempt to create an OS-agnostic, open-source standard which wouldn’t favor any particular vendor. The specification is available on the AltBeacon website and is free to use without royalties or licensing fees. Like other beacons, it uses non-connectable, undirected advertising packets.

        Altbeacon logo.png

        Whitepaper on Developing with Bluetooth BLE Beacons

        Our experts have put some very relevant information in a whitepaper on developing with Bluetooth beacons. The goal is to help you get to market quickly with the right, stable solution.

        It covers a lot of territory:


        • We examine beacon applications to help you brainstorm some of your own.
        • We provide a short history of Bluetooth and its derivatives, including Bluetooth low energy and beacons.
        • We cover the leading beacon pseudo-standards in detail.
        • We provide references to field-hardened example code and tools to develop and deploy it.
        • And we provide information on end-to-end solutions to get you started.

        Beaconing CTA.png

      • The Answer to 100G/400G Coherent Optics Timing Requirements

        Lance Looper | 04/116/2016 | 08:05 AM

        Today we announced our Si534xH clock family, a high-frequency, flexible clocking solution designed to cut cost and complexity for system-level development. The Si5344H and Si5342H clocks will replace current timing tools that rely on large, expensive voltage-controlled VCSOs that only support single, fixed frequencies. This frequency flexibility is coupled with jitter performance of 50 fs RMS.




        The ability for service providers to send more data over existing fiber while minimizing the need for network upgrades is made possible by coherent optics, and this new offering simplifies things by integrating more functions into a smaller footprint.


        Other features include:

        • Ultra-high-performance jitter-attenuating PLL designed for transmitter and receiver clocking
        • High-speed driver for data converter clocking of up to 2.7 GHz with ultra-low phase noise
        • Typical jitter performance of 50 fs RMS (1 MHz to 40 MHz)
        • MultiSynth fractional frequency synthesis for generating any frequency up to 712.5 MHz
        • Integrated loop filter with user-programmable PLL bandwidth for flexible jitter attenuation
        • High-speed, digitally tunable DCO mode: 0.001 ppb resolution with 1 MHz SPI update rate
        • Module-friendly size and power consumption
        • Simple, easy-to-use ClockBuilder Pro software


        The Si5344H-EVB and Si5342H-EVB evaluation boards, priced at $199 each (USD MSRP), are available to simplify device evaluation and system-level timing design. To order clock samples and evaluation boards, visit


        Si534xH Details.png

      • 3 Methods for Programming the BGM111 Bluetooth Smart Module

        Lance Looper | 04/113/2016 | 01:06 PM

        In the first part of his Bluetooth series, embedded designer James Langbridge gave us a guided tour of the BGM111 Bluetooth Smart Module. This is our smallest, lowest power Bluetooth Smart Module and because it integrates an antenna, software, and RF certifications it can help reduce time to market.


        In this, the second part of his series, James walks us through the three methods for programming the BGM111. If you don’t already have the kit, get it here. Then check the video below:



         And don't forget to check out the first post in this series here.

      • IoT Security Part 5: Secure Hash Algorithm

        kberringer | 04/112/2016 | 04:57 PM

        Secure Hash Algorithm


        What is a Cryptographic Hash and why should I use one, instead of a CRC, or Message Authentication Code?


        A hash function maps data of an arbitrarily large size to a fixed size. This is essentially a unique fingerprint of the data. A cryptographic Hash Code uses a cryptographic function to generate a hash code. For example, Git repositories use an SHA-256 Hash as a fingerprint to ensure a remote repository is in sync with a master repository.


        A cryptographic hash function also has the property that it is not possible to deduce a message from its hash. This is important for security because we might transmit the hash code of data, but don’t want to compromise the actual data.


        A Message Authentication Code, or MAC is like a keyed hash. The MAC depends on both parties using the same key. One has to know the key to authenticate the message. A cryptographic hash like SHA-256 has no key. A unique set of data will always produce the same SHA-256 hash code for everyone.


        The purpose of a Cyclic Redundancy Check (CRC) is different. CRCs are design to detect errors, not to provide a fingerprint. CRCs are not guaranteed to be unique or protect the security of the content. CRCs are just for error detection.


        The most commonly used Cryptographic Hash is the Secure Hash Algorithm (SHA). There are variants called SHA-1 and SHA2. SHA-1 always uses a 160-bit digest. The digest is the output value from the hash algorithm. SHA-2 supports different digest sizes ranging from 224 to 512 bits. Rather confusingly, SHA-2 with a 256-bit digests is commonly abbreviated SHA-256 (perhaps it should have been called SHA2-256.)


        So which SHA function to use? Before the NSA introduced SHA, Ronald Rivest designed the MD5 Message Digest Algorithm. Version 5 is still supported by TLS1.2. 


        There is some controversy regarding the security of MD5 and SHA-1. For both MD5 and SHA-1 there have been collisions found that limit the security to less than half the digest size. OK. What does this mean?


        A collision just means that two sets of data can produce the same digest, or fingerprint. So hypothetically, the odds of having two data sets with the same digest for SHA-1 are slightly less than the ideal value of 1/(2^80). This only means that SHA-1 is not as secure as we thought it was.


        There are no known successful preimage attacks on MD5 or SHA-1. A preimage attack tries to find a message with a specific hash. So in that respect, MD5 and SHA-1 are relatively secure.


        MD5 is deprecated in TLS-1.2 and SHA-1 is deprecated in TLS-1.3. If you have a choice, I would recommend using SHA-256 (SHA-2 with a 256-bit digest.)


        Because TLS connections depend on the capabilities of both parties, it is good to have support for legacy security modes to ensure that you can connect to host that does not support the latest security standards.


        The Crypto module on the EFR32 devices and the Pearl and Jade Geckos supports SHA-1 and SHA-2 with a 224-bit or 256-bit digest. If you have a choice, I would recommend SHA-256, because it is just as fast as SHA-224. These devices also support the legacy MD5 Hash using the mbed-TLS software library.


        So when should you use SHA? A good use for an embedded device is to use a secure hash for firmware validation. Suppose you have a secure bootloader and you want to make sure that your firmware image is valid. The bootloader might have the capability to calculate a SHA digest for the entire firmware image upon request. The host can compare the SHA digest to the expected value. Because it is a secure hash, we can freely give the digest to anyone that asks for it.


        The previous blog discussed the CBC-MAC block cipher mode for authenticated encryption. There are other block cipher methods besides CBC-MAC. The Galois Counter mode is one that is increasing in popularity. This is the subject of the next blog post.


      • University of Antwerp Professor Uses IoT as Inspiration for Coursework

        deirdrewalsh | 04/112/2016 | 08:49 AM



        I recently had the opportunity to interview Professor Maarten Weyn at the University of Antwerp. If I ever choose to go back to school, I hope my professors are just like him. Here’s why:


        Please tell us a bit about yourself and your method of teaching as a professor.

        While starting as a researcher, and later as a professor, I was always inspired by the real-world challenges embedded device companies face. In academia and research, you aren’t as obliged to follow the design requirements and user expectations of the industrial world. This is why I want to combine academic with industrial innovation. I don’t want to be a professor that is disconnected from the industry.


        I use industrial challenges as inspiration in my curriculum at the Applied Engineering Department of the University of Antwerp and my research within iMinds/MOSAIC group. I ask students to build IoT prototypes combining different sensors, actuators, and communication technologies while taking into account things like low power consumption, form factor limitations, and communications regulations.


        How did you get into IoT?

        The funny thing is while I was studying as a graduate student, I was doing sensor fusion and programming, yet I tried to avoid all things electronics. But once I became a professor, I realized that once you combine hardware, software, and communication, you can do very interesting work. Designing IoT devices combines all of those disciplines and this appealed to me.


        Tell me more about what students can expect in your classes.

        unspecified-4.jpegIn most of my courses, instead of starting my lectures with theory, I start by asking students to find embedded design applications online: they must come back to class with videos, blogs, and forum posts that capture examples of real-world challenges. And they, themselves, must find examples of real-world solutions. In this way, they help design my curriculum. They decide what problems to address and they find the solutions. Together, as a class, we spend time discussing the concepts and theory behind them.


        Here’s what I want my students to learn: when designing for embedded IoT, it’s not just a matter of acquiring data and sending it somewhere. They need to think about other design requirements such as energy consumption. How should this device be powered? Will it be a continuous load or pulsed load?


        To make things even more challenging, I have them take into consideration environmental challenges, like perhaps designing a water sampling system. Can it fit into a small form factor? Can it survive extreme conditions under water? Ultimately, I imagine students appreciate this learning style.


        Sounds like students can get really creative with their design solutions. How do you outfit your lab with the right tools?

        We need tools that can be used for a variety of applications and designs, especially when designing for the IoT. We took this into consideration a few years ago when our legacy tools approached end of life; we needed something new.


        Through cooperation with another tech company, we had worked on a project using Silicon Labs’ Gecko products around that time. In our case, our learning curve with the Gecko was much shorter than others we had worked with. On top of that, it wasn’t difficult to port our existing APIs from other hardware platforms to the Gecko. It met our requirements for low power and wireless communication, so we adopted it.


        Today, our lab is built around the Gecko architecture. We give students their own development tools which include a Gecko development kit with integrated power measurement, sensors and actuators, and an USB scope and logic analyzer. In this way, they have their own individual lab and all for a limited amount of money.




        How do you think your students are prepared for the real-world when they graduate from your curriculum?

        Most of them already have signed contracts before they graduate. Companies come to us to recruit our students because of their versatility. So yes, I’d say my students are very prepared.




        Can you share some of the cool solutions you are working on/have worked on?

        An example of some researcher and student prototypes is the DASH7 (a sub-1 Ghz Active RFID/WSN communication technology) extension for tablets to enable accurate localization in a museum. This allows the museum to offer a smart, location-based tour guide for their visitors.unspecified-5.jpeg


        In another interesting project, we built a prototype for bird tracker that weighs less than one gram.


        In another application, students built an underwater device for water quality management.

        Students are currently working on a version of this device based on the EFM32 Happy Gecko Starter Kit.


        Another prototype we have built is a smart badge for events and conferences.
        This smart badge eases registration, enables user interaction, gathers continuous feedback from the participants, and provides participant notifications, like when their next session is about to start. On top of that, it’s powered by one coin cell battery



        What do you think is the biggest barrier to wide-spread IoT development?

        Time! IoT is happening today, but there is a huge battle around what will become THE IoT platform standard. More and more, people are understanding that there cannot and will not be one defacto standard. We must create solutions which are agnostic to multiple technologies.


        I also believe that most applications need a winning combination of technologies. There currently is a big gap between IoT prototypes which you see every day on the internet and real products. This is mainly because to make this transition, for example, power consumption, network architecture, and price becomes very important. A good prototype will never become a product if there is not a matching business model.


        And lets not even start the discussion of privacy and security at this moment; that might require another interview session of its own. But for now, as long as developers think about privacy in the initial phases of design, hopefully we can solve this issue as well.


        What does the future of IoT look like?

        The future of IoT is one without IoT. Connected objects will become so ubiquitous and such a commodity that we will not think about the fact that they are objects and that they are connected. It will be obvious that information from sensor, actuators, devices, people, and services are used together to control, monitor, and maintain daily applications.

      • Introducing the World’s Smallest, Low Power LVCMOS Clock Generators

        Lance Looper | 04/111/2016 | 04:05 PM

        Today, we released the Si5121x Tiny Clock family with ClockBuilder Pro, the industry’s smallest programmable LVCMOS clock generators. Ideally suited for designers requiring multiple crystals and oscillators up to 170MHz on a single board, the Si5121x family replaces up to three of these components to simplify design and save board space.


        Tiny Clock.jpg


        Additionally, the new family is supported by ClockBuilder Pro (CBPro), which has been specifically designed to simplify clock tree and device configuration. With CBPro, you can create a frequency plan, get a custom part number, or program a device into an evaluation board. 





        Other Benefits include:

        • Comes in ultra-small 1.2mm x 1.4mm or 1.4mm x 1.6mm TDFN packages
        • Up to 40 percent cost savings over a solution of three crystals and/or oscillators. 
        • Spread spectrum capability to reduce EMI at no extra cost. 
        • No need to contact the factory for programming files, part numbers, or datasheets.


        Check out our Si5121x evaluation kits here.