Date: Tuesday, December 11, 2018
Time: 10:00 AM Central European Time
Duration: 1 hour

Applications receiving Power over Ethernet (PoE) often face the dilemma of maintaining power budgets while meeting the demands to develop full-featured solutions.  With higher power classifications becoming more frequent at the end device, Silicon Labs delivers a set of PoE Powered Devices (PD) solutions to optimize BOM solution cost, efficiency, and performance while reducing development time.

In this technical webinar, we discuss how Silicon Labs’ PD controllers meet ever increasing power demands and demonstrate our evaluation kits’ drop-in ready designs.

The following blog explains a simple way of detecting task stack overflows while debugging your Micrium OS application.

Micrium OS Kernel Red Zone

The kernel's red zone is a feature that, when enabled through OS_CFG_TASK_STK_REDZONE_EN in os_cfg.h creates a monitored zone at the end of a task's stack. The length of the red zone is user-configurable via the #define OS_CFG_TASK_STK_REDZONE_DEPTH in os_cfg.h. By default, this is set to 8 stack elements (CPU_STK). 

When the red zone is enabled, every time a task is switched out, either at the task level or at the interrupt level, the kernel checks if the red zone has been hit. By default, a software exception is thrown with the use of the CPU_SW_EXCEPTION macro in the ARMv7m port. However, if you want more control over what your application should do in the event that the red zone is hit, you can turn on the application hooks by setting OS_CFG_APP_HOOKS_EN to DEF_ENABLED in os_cfg.h.

Using the Red Zone Application Hook

If you decided that you want your application to determine what to do in the event that a task hits the red zone instead of throwing a software exception, then you will have to define a hook function to do so.

A simple example:

static  void  RedzoneHitHook (OS_TCB  *p_tcb)
{
	BSP_LedSet(0);
	while(1);
}

With that, you can tell that if you see LED0 permanently on and with your code trapped at the while loop you have hit the red zone. You can then check p_tcp->NamePtr in your local variables panel and find what was the task that hit the limit.

Don't forget to assign the red zone hit hook pointer to your custom function. Using the example above:

OS_AppRedzoneHitHookPtr = RedzoneHitHook;

Make sure that this is added prior to calling OSStart() otherwise the pointer is never assigned to your application hook.

For more details about detecting stack overflows and the red zone, visit the following link: https://www.micrium.com/detecting-stack-overflows-part-2-of-2/

The next generation of designers and developers must be forward-thinking to build smart, connected, energy-friendly products. The University of Texas at Austin’s Solar Vehicles Team (UTSVT) is a group of passionate students, applying engineering concepts to bring us closer to practical solar-powered alternatives. We sat down with Corey Hulse, the electrical team leader, to discuss the team’s achievements, the importance of their mission, and their biggest development concerns.

Every year, the team participates in the American Solar Challenge, which includes two races: the Formula Sun Grand Prix and world championship race. The goal of the competition is to prove the viability of sustainable systems by showing sustainable energy sources used in unexpected, new ways. The first race at the Circuit of the Americas hosts teams from all over the country, as well as Canada and Puerto Rico. After three days of racing, eight hours a day, the vehicle with the most laps accumulated wins.

Above all else, Hulse said, “We just want to show the idea that there are new discoveries to be made in renewable energy and it is a viable power source for the future.”

Design Challenges:

Safety is a top concern for the UT team. The team works with extremely high voltage battery packs, so they require reliable protection systems to detect any shorts or temperature issues. If high temperatures were not reported and caused a battery to ignite, the entire battery pack could catch fire, engulfing the entire vehicle. The battery pack uses Silicon Labs’ temperature sensors to carefully monitor temperature levels, and there are also temperature sensors in the array itself. According to Hulse, the team receives “feedback on what areas of the array might not be performing at their best due to temperature problems,” and can then adjust for improvements. 

Using Silicon Labs’ galvanic isolation products, the team isolates their grounds to protect against shorts that may carry over into different systems. Due to the many different voltage levels, if one were to escape into another it would destroy whole parts of the vehicle. The isolators also help to improve signal quality.  Multiple power levels introduce noise that affects every system since they run parallel to each other. The galvanic isolators clean up the signal lines and ensure that important information is being communicated.

The design team also considers the driver interface and diagnostic platform to gain a complete picture of the car’s performance during the race. The ergonomics team works with Silicon Labs’ Gecko 32-bit microcontrollers to build out the team’s dashboard and design the driver interface. Hulse explains this choice, stating “They have a lot of LCD screens that display various information about how well your battery pack is doing, how well your car is performing, and if there are any safety dangers that you need to be aware of.”

Sensors gather information, including: the speed of the car, GPS coordinates, power usage, and temperature of each battery. This information is not stored in the vehicle, it’s sent to the pit crew during the race. The UT Solar Vehicles Team relies on Silicon Labs’ Zigbee technology to attain necessary information to understand the car’s performance and diagnose safety issues. The team selected Zigbee because its range was able to cover the entire track and its bandwidth was large enough to collect all the information onto a remote server for viewing.

Overall, students from many different disciplines from manufacturing to meteorology to business come together to help make the most efficient solar car design possible. Though the process is very involved, the students tackle problems with enthusiasm, excited to gain hands-on engineering experience and to have a positive impact on the world.

Development Experience:

There are a lot of factors to consider when designing a solar car, especially for a student-driven team with a limited budget. The UT Solar Vehicle team prioritized excellent performance, power efficiency, and quick support from the company provider. Silicon Labs checked all their boxes. Our applications team responded quickly and answered all their questions, which was very helpful for undergraduates trying to overcome a large learning curve. Hulse described the support, saying “They really seemed like they wanted to answer any questions we had and make sure that our project got completed.”

Future Endeavors:

The UT students involved are extremely motivated and ready for any challenge, including designing and building a completely new vehicle from scratch. Teams typically build new cars every 2-4 years. The UT team’s previous car, TexSun, cost around $140,000 and the one they’re currently building is budgeted at $180,000. The current car, BeVolt, cleverly named after the university’s mascot, Bevo, should be ready to race this summer. The team is determined to take this opportunity to make significant improvements in speed, battery life, and maintainability.

We’re proud to support UTSVT and look forward to seeing all that they accomplish in the future. To learn more about the UT Solar Vehicles Team and how you can support their work, watch our interview with Corey Hulse, team lead and former stand-out summer intern:

Last week, Armis Security published the discovery of two new vulnerabilities named BLEEDINGBIT. The first (CVE-2018-16986) is a classical buffer-overflow attack that allows an adversary to run arbitrary code on the BLE device. Once this occurs, the BLE device can be used to attack other devices in the system.

The other vulnerability (CVE-2018-7080) is related to an over-the-air upgradability feature, which appears to be specific to the affected TI devices and end products using this feature.

Both vulnerabilities are present in the Bluetooth stack software from TI, and the company already issued BLEEDINGBIT patches for the software vulnerabilities earlier this year. Texas Instruments appears to be following security best practice protocols as effectively as possible to ensure effective remediation of the situation.

Silicon Labs uses the affected TI BLE devices (CC2540 and CC2541) in our BLE112, BLE113, BLE121LR modules, and the BLED112 USB dongle.

Yet the Silicon Labs modules and dongle using the affected TI chips do not utilize the TI software stacks, which is where the vulnerabilities reside. Silicon Labs uses are our own proprietary stack for these devices. Silicon Labs has verified that our proprietary software stacks using the affected TI BLE chips are not vulnerable to the BLEEDINGBIT vulnerabilities.

For completeness, Silicon Labs Blue Gecko Bluetooth devices and modules using our Bluetooth SDK are not vulnerable to these exploits.

In 2017, the Bluetooth SIG added mesh networking capability to Bluetooth. An established, trusted technology, Bluetooth mesh demonstrates global interoperability and is well-suited for consumer lighting and home automation applications—think large-scale systems in which tens to hundreds of devices need to reliably and securely communicate. In addition to industrial applications, mesh shows strong signs of growth in many markets, including smart building, and smart home.

Bluetooth Mesh by the Numbers:

Meeting the Bluetooth SIG's Mesh Specifications 

The Bluetooth SIG released their mesh networking specifications in 2017 in order to set the fundamental requirements of an interoperable many to many (m:m) mesh networking solution for Bluetooth Low Energy (LE) wireless technology. Any mesh networking solution, model, or device must meet these specifications in order to be fully compliant with the SIG’s standards. 

Not only are Silicon Labs’ Bluetooth mesh solutions fully certified by the Bluetooth SIG, we are the only company that has performed Bluetooth mesh performance testing and published the results. When we compared the performance of mesh networking standards between Thread, Zigbee, and Bluetooth mesh, we found that Bluetooth mesh works best when short messages (<=11B) are used, especially for multicast messages. 

Silicon Labs Bluetooth Mesh Solutions: Setting the Example, Right out of the Gate 

Though any Bluetooth low-energy hardware can be used for a Bluetooth mesh implementation, Silicon Labs’ EFR32BG13 Blue Gecko SoCs, as well as BG13MP and BGM13S Blue Gecko Bluetooth® Module feature several advantages: 

• High transmit power, which means good RF performance
• A temperature range of over 125 Celcius, a key consideration for LED bulb design
• At 64 k ram and 512 flash, an ideal memory profile for Bluetooth mesh applications

Silicon Labs is also the leading producer of Bluetooth mesh hardware and software with low power nodes (LPN). Low power is a critical feature for battery-powered energy harvesting devices such as sensors and switches. 

Because Silicon Labs was the first to market with Bluetooth mesh, we have most mature software with the most features for developers. Those dev tools include: 

1. The Simplicity Studio™ Network Analyzer. No other company makes a network debugger tool like this one. Customers tell us it provides the easiest way that they’ve found to see and squash bugs. Learn more in this quick this video tutorial. 
2. With the Blue Gecko Bluetooth Low Energy Wireless SoC Starter Kit, you can quickly build test networks and visualize energy usage and optimization.  
3. Support for Android and iOS in the form of an app dev kit (ADK), with an example app and source code included. 

One of our Bluetooth experts, Mikko Savolainen, explains the benefits and features of Bluetooth mesh in this video:

For more information, visit the Bluetooth Mesh Learning Center. 

Media coverage of high-profile attacks regularly make sensational headlines when security experts are quoted painting pictures of how creepy an insecure future is [1,2,3]. This is partly because negative and scary news sells [4], but there have also been hacks and security vulnerabilities that show just how critical adequate security is and how seemingly harmless devices can be compromised [5,6]. The security experts might even exaggerate their claims as a call to action.

Obviously, not connecting devices is not a solution to this problem. It is important to keep in mind that the reason why all of these devices are getting smart and connected is because of the enormous value and benefits connected devices offer society [7]. Using the scarce resources of the planet in a smart way is crucial for our future, and just one way the IoT’s promise dramatically outweighs the risks.

At Silicon Labs, a secure IoT is one of our most important goals.

Today, there are many initiatives to regulate the security of IoT-devices, and we are starting to see regulations [8]. We welcome these regulations because they are necessary for a secure IoT. And when regulations arrive, our technology will be complaint and we will be ready to help our customers secure their products using our technology.

And until IoT Security is regulated, we’ll focus on being a good global citizen and bear our share of the responsibility:

• We set the standard in integrated security functionality for the devices in our markets, and will continue to do so:
  • In the last generation of products, we introduced fast and secure cryptography engines in hardware for asymmetric cryptography.
  • Our Gecko Secure Bootloader, using asymmetric cryptography, is already widely deployed, securing a large number of products against attacks that utilize a weakly secured bootloader [6].
• We help our customers secure end products through training and documentation:
  • See for instance this recent webinar on why the IoT requires upgradability [9].
  • Or this whitepaper on security tradeoffs for wireless IoT protocols [10].
• We track and monitor potential vulnerabilities in our products, and promptly work with our customers to mitigate risk:
  • See for instance the recent note on the Bluetooth pairing vulnerability [11].
  • If you find a suspected vulnerability in one of our products, please report it here [12].

Securing the IoT will not be free. There is a cost to adding security technology, and there are development costs. We’re working hard every day to minimize that cost in our products. Still we run into customers that don’t want security technology because it costs more than zero. We believe that those products will not be successful in the long run.

To this end, we are committed to a secure IoT, with successful secure products.

[1] https://www.wired.com/story/have-a-high-tech-halloween-with-your-own-haunted-smart-home/

[2] https://www.theregister.co.uk/2016/03/02/sleepwalking_towards_digital_disaster/

[3] https://www.nytimes.com/2018/10/10/technology/future-internet-of-things.html

[4] https://www.theguardian.com/commentisfree/2018/feb/17/steven-pinker-media-negative-news

[5] https://www.theregister.co.uk/2016/10/21/dyn_dns_ddos_explained/

[6] http://iotworm.eyalro.net/

[7] https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/the-internet-of-things-the-value-of-digitizing-the-physical-world

[8] https://www.cnet.com/news/california-governor-signs-countrys-first-iot-security-law/

[9] https://www.silabs.com/webinars/why-the-iot-needs-upgradable-security

[10] https://www.silabs.com/whitepapers/security-tradeoffs-and-commissioning-methods-for-wireless-iot-protocols

[11] https://www.silabs.com/community/blog.entry.html/2018/07/31/regarding_the_fixed-UMT5

[12] https://www.silabs.com/security/product-security

Hi all,

I'm pleased to announce new software that includes improvements and bug fixes for our Bluetooth, Thread, Zigbee, and MCU product families. This release provides the following: 

• EmberZNet 6.4.0 (Full release here)
  • Green Power Combo
  • Sub-GHz PHY running on RAIL
  • NVM3 support for single protocol Zigbee
  • Upgrade feature from SimEEv2 to NVM3
• Silicon Labs - Thread 2.8.0 (Full release here)
  • SL-Thread support for LZ4 decompression in Gecko Bootloader
  • Border Router support for Basil Hayden Thread features
  • Beta release for Dotdot 
• Flex 2.4.0 (Full release here)
  • Support for existing EFR32MG1x sub-GHz parts
  • Support for new EFR32MG1x sub-GHz parts
  • Multi-PHY support
  • Connect support for 500kbps data throughput
  • 2.4GHz and sub-GHz FHSS
  • Dynamic Multiprotocol RAIL + BLE Range test and  Mobile App support
• Bluetooth 2.10.0 (Full release here)
  • Optional Adaptive Frequency Hopping (AFH) and +20 dBm TX
  • Modules treated as individual products in Studio
  • RF channel now reported in scan events
  • Bluetooth + RAIL DMP range test application
• MCU (Full release here)
  • Production Bootloader for EFM32GG12x
  • CMSIS package for EFM32GG12x alpha 
  • Support for LTE-M expansion kit for EFM32GG11x STK
  • EFM32GG11x EBI support in EMLIB

Note that API documentation and release notes for most stacks are now available at docs.silabs.com.

Need help? Please contact Silicon Labs Technical Support.

Earlier this month, UK-based RS Components announced the UrsaLeo Pi development kit, aimed at making IoT projects more accessible by combining our Thunderboard Sense 2 and a Raspberry Pi development board. Eric Brown over at Technologic Systems had this to say about the new development kit:

UrsaLeo’s kit, which was recently introduced by Mouser under its original “UrsaLeo UL-RPI1S2R2” name, is designed to send sensor input to Google Cloud for storage and analytics. The kit is designed for Industry 4.0, automotive diagnostics, healthcare, and general data monitoring.

The UrsaLeo Pi offers the same Silicon Labs Thunderboard Sense 2 sensor board found on UrsaLeo’s earlier UrsaLeo UrsaCloud UltraLite, also called the UrsaLeo UltraLite or UL-NXP1S2R2. While the UltraLite kit combines the Thunderboard 2 with NXP’s official development board for its Cortex-A7 based iMX6 UltraLite (UL) SoC, the UrsaLeo Pi uses a more powerful Raspberry Pi 3 SBC.

The UltraLite version offers more better debugging functionality than the Pi, as well as reduced “restrictions on hardware re-use,” says RS Components. However, the Pi version is faster and much cheaper. It costs 154 Pounds ($197) without VAT at RS Components compared to 455 Pounds ($582) for the UltraLite. Mouser’s prices are $195 and $550, respectively.

The Thunderboard Sensor 2 (or Thunderboard 2) board provides temperature, humidity, UV, ambient light, barometric pressure, indoor air quality, and gas sensors. You also get a 6-axis inertial sensor, a digital microphone, and a Hall sensor. The board is equipped with Silicon Labs’ EFR32 Mighty Gecko multi-protocol radio, which supports 2.4GHz wireless technologies such as Bluetooth Low Energy (BLE), Thread, ZigBee, or proprietary short-range protocols.

The kit is pre-loaded with an OTA-updatable Linux stack based on Yocto Project code. It automatically links up to a pre-registered Google Cloud account. Up to 50MB of data per month can be sent to the cloud platform free of charge. 

A customizable dashboard “allows users to view sensor data and launch IoT applications such as storage and analytics,” says RS Components. The dashboard, which can be shared with third parties, is said to streamline the addition of new sensors and support user-definable events to trigger alerts. 

Sample applications and APIs are provided to manage sensors, run diagnostics, and share information with enterprise or business intelligence applications. 

Introduction

In this post, The Case of the Noisy Source Clock Tree Part 1, we will go a step beyond the prototypical or “canonical” clock tree. I will discuss the motivation for adding a jitter attenuator and its impact on clock tree jitter estimation. So let’s get started.

The Canonical Clock Tree

The board level clock tree or clock distribution network, for say a data center application, is typically depicted with a crystal or low jitter XO (crystal oscillator) connected to a clock generator followed by one or more buffers, something like the following. This is what I refer to as the canonical clock tree:

The root or source of the clock tree in this example is a low jitter XO which determines the frequency stability of the clock tree overall. The clock generator then scales the input frequency from the XO to several different (usually higher) output frequencies. Finally, the clock buffer takes one of these output frequencies and yields multiple output clocks with the same frequency. The colored arrows in the figure are meant to suggest different clock frequencies.

We can estimate the total or end clock phase jitter of the canonical clock tree by applying the RSS or Root Sum of the Squares of the individual contributions. (This is the same summation in quadrature math used in cascaded statistical analysis of mechanical tolerances and other errors or uncertainties.) 

For the example above, we can estimate the total RMS phase jitter as

Note that several prerequisites must hold true for this calculation to be valid:

1. The phase jitter contributions should be uncorrelated.
2. Each phase jitter contribution must be integrated over the same jitter bandwidth, e.g. 12 kHz to 20 MHz.
3. Finally, every device in the clock tree is wideband with respect to the clocks involved.

Jitter Transfer versus Jitter Generation versus Additive Jitter

The last statement above means that the bandwidth of the clock generator is wide enough compared to the input clock phase noise that we need not consider the clock generator’s jitter transfer. You may recall that jitter transfer or jitter attenuation measures output clock jitter versus input clock jitter. This is often written as the Jitter Transfer Function or JTF.  A PLL’s JTF acts as a low pass filter to input jitter and is a function of PLL bandwidth.

Jitter generation refers to the intrinsic jitter of a device. In the case of a clock generator, it is a measure of the output jitter when an ideal (no jitter) input clock is applied.  A PLL-based clock device, even with a perfect input clock applied, still has PFD (Phase Frequency Detector) path noise and an intrinsic phase noise source, the VCO. Thus the need for a jitter generation term. 

By contrast, clock buffers consisting only of amplifiers and perhaps dividers will always contribute additional noise to any input clock. Hence the use of the term additive jitter.

The Noisy Source Case

The example canonical clock tree above assumes a low noise clock as in a typical application. However not all clock trees have a low noise clock source.

What categorizes a source clock as relatively low or high noise?  Let’s ignore the follow-on clock buffer for now and just compare the XO’s jitter generation versus the clock generator’s jitter generation. If they were exactly the same, the total jitter would increase by a factor of SQRT(2) or 41% which is substantial. If we choose the usual engineering convention of a 10% increase denoting significance, then we can back out that the XO’s phase jitter should be < 46% of the clock generator’s phase jitter. In other words, the source jitter must approach approximately half the clock generator’s jitter to significantly increase the output clock jitter.

A noisy (jittery) clock could be a recovered clock from serial data or derived from an FPGA. Perhaps the board itself is introducing power supply noise in to the XO. Such a clock tree then behaves as indicated in the figure below. The waveforms are shown thicker here than in the previous figure to suggest higher jitter.

We can still apply the RSS estimate even for a noisy source clock. However, often the resulting jitter will be too high for a typical clock distribution application. So what is our recourse?

Jitter Attenuator to the Rescue

In such applications, we need to add a jitter attenuator to clean up the source clock noise and improve the clock tree jitter performance. The figure below illustrates the basic idea where we have inserted a jitter attenuator between the noisy FPGA-derived source clock and the clock generator. Post jitter attenuator, the rest of the clock tree now looks like the canonical case.  Note that in practical applications, a single device often performs both the jitter attenuator and clock generator scaling functions.

Like the clock generator, the jitter attenuator is a PLL-based device whose JTF acts as a low pass filter to input jitter. However, unlike the clock generator, the jitter attenuator is a relatively narrow bandwidth device versus the input clock phase noise. This violates one of the prerequisites for using the RSS estimate method. So, what is the best approach to calculate the expected phase jitter of the jitter attenuator output clock, and by extension the total or end clock jitter?   

Clock Tree as a Phase Noise Processing System

In engineering, we usually analyze and measure the performance of systems in the frequency domain. Clock distribution networks aka clock trees are no different. The primary attribute of a clock is its frequency and the RMS phase jitter quantities are integrated from phase noise data. It should come as no surprise then that the better and more rigorous way to analyze clock trees generally is in the frequency domain.

In fact, following the clock signal from the source through jitter attenuators, clock generators or multipliers, and buffers, to the sink or destination is best viewed as a system that processes phase noise (this is an example of “one man’s noise is another man’s signal”).

The application of jitter attenuators in particular can really only be well understood by working in the frequency domain. The JTF can be modeled simply by the PLL bandwidth and expected attenuation in the jitter bandwidth of interest. At each phase noise offset frequency f we calculate the output clock phase noise in terms of the input clock phase noise, shaped by the JTF, and added in quadrature to the jitter generation phase noise contribution. We can then check to see if the resulting integrated phase jitter meets the required jitter performance.

I will discuss in more detail exactly how to do this and provide a measurement and spreadsheet example in the next post, The Case of the Noisy Source Clock Tree Part 2.

Conclusion

I hope you have enjoyed this Timing 101 article and will look forward to the follow-up.

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

Cheers,

Kevin

Some circuits may be damaged if they try to talk to each other, and digital isolators are devices that make it possible for them to communicate without blowing each other up. In this Q&A, Silicon Labs’ Rudye McGlothlin answers a few questions about these devices and techniques for balancing safety and performance.

What is driving the Industrial market to use isolation components in the first place?
There are many needs that drive the use of isolation components. System requirements for component protection, user safety, signal level shifting, and adherence to safety regulations are primary drivers. In all cases the isolation components add value to the system by enabling additional functionality and ensuring safe operation of the system.

When I add isolation devices, what affects does that have on my circuitry?
Improved performance in many cases and, in all cases, additional component safety is achieved. Isolation devices allow for multiple power domains to coexist and communicate, which means that sensitive circuits are protected from switching circuits. Modern, digital isolation allows for massive integration, which means that circuit component count can decrease. Performance, efficiency, size, and cost are all things that can be affected when adding isolation devices.

What are my options when considering isolation components for my application?
Up until the last ten years, designers used optocouplers for their isolation needs, but digital isolation has come a long way since that time. Now, digital, CMOS-based isolation is the technology of choice for isolation tasks in the system.

What is the difference between an optocoupler and a digital isolation device?
Simply put, an optocoupler is a hybrid device that uses LED light to transmit data across an isolation barrier to a light detector. The LED turns on for logic High and off for logic Low. Optocouplers consume high levels of power, are prone to aging and temperature effects, and provide limited data rates, often below 1Mbps.

Digital isolation devices, on the other hand, were created to meet safety regulations while maximizing the benefits of modern CMOS technology. To do this, digital isolation devices use semiconductor process technology to create either transformers, or capacitors to transfer data instead of light. With this technology, performance and feature integration are both improved.

What is the best advice to give someone who is hesitant to make the switch from optocouplers to digital isolators?
Optocouplers, although incorporated in many designs, are based on outdated LED-technology that provides significant output variation over input current, temperature, and age. This reduces performance over the device’s lifetime. Digital isolation components easily provide multichannel isolation solutions with a much smaller footprint, increases system reliability due to a lower failure rate, offer twice the electrical noise immunity, operate over a wider temperature range (-40oC to 125oC), and do not age or degrade over time. In general, the use of a high-frequency carrier instead of light enables low operating power and high-speed operation, which allows for precise timing specifications.
 

I’m convinced, now what factors go into selecting a particular digital isolator for my application?
Feature set and isolation performance are both factors to consider with selecting a digital isolator. On the feature set side, consider the number of isolation channels and the channel configurations. Timing specifications, such as propagation delay, should be appropriate for your system. On the isolation performance side, it is important to gain an understanding of the isolation rating your system needs. Transient noise immunity, and electromagnetic emission profile are other considerations related to the isolation structure. With the isolation rating, there maybe be package options to consider given the system environment.

What is the biggest challenge a designer has after they’ve decided to make the switch?
The first challenge is to select the correct digital isolator for each application. As mentioned before, each component has its own specifications just as each application has particular needs. Once an appropriate device is identified and designed in, the system designer can proceed with their system evaluation in their typical fashion.

What safety requirements do I have to consider for my application?
Once you’ve nailed down your application’s needs, you’ll want to be sure that the devices meet appropriate Safety Standards as required by end safety agencies such as UL, CSA, VDE, and CQC. These safety agencies use their component safety standards to qualify and either specify a safety component’s one-minute voltage withstand rating, which is typically 2.5 kVrms, 3.75kVrms, or 5 kVrms, or its life-time working voltage, which is typically between 125 Vrms to 1000 Vrms. All of Silicon Labs’ component safety certificates can be requested online at silabs.com.

What is the typical life expectancy of a digital isolator’s isolation barrier?
This depends on the material used as well as its thickness. Standard materials used include polymer-based, polyimide-based, or SiO2-based insulators. In general, though, the life span of the barrier can easily be over 25 years.

What are some of the standard rated voltages I can expect to find?
Depending on the device manufacturer, common one-minute rated voltages are 1 kVrms, 2.5 kVrms, 3.75 kVrms, or 5 kVrms. For surge protection, some devices can reach 10 kVpk.

What creepage and clearance do your products support?
The two most common creepage and clearance requirements that are required by end systems for basic and reinforced insulation needing up to 250Vrms working insulation are 3.2mm and 6.4 mm respectively. In general, Silicon Labs’ narrow body SOIC packages support ~4mm of creepage/clearance and the wide body SOIC packages support ~8mm.

For more information about our digital isolation products, visit https://www.silabs.com/products/isolation/digital-isolators.