At the end of the day, the goal is to expand the areas where Z-Wave can fit and make customers’ product development more beneficial and much easier. This is the idea that “Doctor Z-Wave” Eric Ryherd, Field Applications Engineer for Silicon Labs, expounded in this Tech Talk session. Click here to watch the complete Z-Wave Smart Home Solutions webinar and register now for future Tech Talks. Here are some valuable key points from Eric's session.
Focused on the smart home market, Z-Wave is a customer-centric, low-cost, easy-to-use, simple, secure, and very reliable SubGHz-operated, mesh-networking radio protocol. The key to Z-Wave’s leadership in the smart home industry is its interoperability, with more than 3,000 certified products on the market. Interoperability not only allows Z-Wave products to “talk” to each other – no matter where the product is purchased from– but also enables backward compatibility. Z-Wave Alliance certification further ensures interoperability; click here to learn more about the alliance's mission, vision, and product certification process.
Our Z-Wave 700 series features our Silicon Labs Wireless Gecko products, offering several advantages, including:
Improved radio range with -97 dBm sensitivity
Low power with up to 10 years on a coin cell battery operation
Over-the-air firmware update capability
Increased computation with an Arm Cortex M4 processor
Easy development with the Simplicity Studio IDE
We want to give you all the tools you need – including hardware and software for end devices and gateways – to get from concept to product in just six months. We also provide pre-certification support and certification tools. Visit our Z-Wave Wireless Solutions for the Smart Home page for more details on how to get started.
The Tech Talk ended with a Q&A session, and you can find the transcript here.
“Threats evolve. So should your device security.” As a developer, you should heed this sage advice when designing your next IoT products. In this Tech Talks session, Brent Wilson, Senior Applications Manager for IoT Product Security at Silicon Labs, explores the hidden costs, challenges and imperatives of adding advanced security features to connected devices. Click here to hear the entire IoT Security session and register now for future Tech Talks. Some key takeaways from Brent’s session are below.
Responding to the Need for IoT Device Security
Securing the IoT is critical to the successful adoption of IoT technology, and inadequate security is an impediment to the IoT’s continued growth. For this reason, legislation is evolving to mandate “reasonable” security features in IoT products. For example, California is one of the first states in the US to legislate IoT security and privacy for consumer products, and other states are following suit. Governments in Europe and Asia are also implementing IoT initiatives to protect consumers and their IoT devices. Many new IoT security features presented in this Tech Talks session map directly to these emerging regulatory requirements.
How Silicon Labs Is Addressing Device Security
Our IoT connectivity portfolio offers a complete set of security features, ranging from basic capabilities to “root of trust” to “Secure Element” and our new Secure Vault software and hardware security suite, available soon in new Series 2 wireless SoC and module devices.
Rounding out the IoT security session, Brent explains the key features that define Secure Vault including secure boot and secure updates, anti-rollback detection, secure key storage, differential power analysis (DPA) countermeasures, secure attestation, secure debug, anti-tamper and a true random number generator (TRNG).
Click here to check out the Q&A from Brent's Tech Talks session. To learn more about Silicon Labs’ new Secure Vault technology, visit silabs.com/security and check out Brent's IoT device security session.
Bluetooth wireless technology is continuously evolving, with each specification providing new and innovative ways for devices to connect and communicate. In this Tech Talks session, Silicon Labs field applications engineer, Claudio Filho, describes the evolution of Bluetooth specifications 5, 5.1 and 5.2, as well as advantages and best use cases for each version. Click here to watch the entire Bluetooth Evolution session and register now for future Tech Talks. Highlights from Claudio’s presentation are below.
Key Features of Bluetooth Specifications 5, 5.1 and 5.2
The release of Bluetooth 5 brought faster data rates and lower power consumption to the wireless market. An optional 2M PHY cut packet transmission time in half, and two long-range PHYs extended device range up to four times that of Bluetooth 4.x versions. An enhanced advertisement configuration means that Bluetooth 5 has eight times the capacity of its earlier generation.
Bluetooth 5.1 provided new direction finding capabilities with < 1 m accuracy, GATT caching, randomized advertising, and periodic advertising sync. These features combined to provide faster and lower power connections, reduced packet collision, improved packet error rates (PER), and better power management. While Bluetooth 4.x supports Bluetooth mesh and beacons (used for asset tracking), the scalability of the 5.1 version makes it ideal for these use cases.
Key advantages of Bluetooth 5.2, the latest version, include more efficient connections with lower power and communication of time bound data. Low Energy (LE) isochronous channels enable audio transmission over multiple devices and LE power control optimizes power for transmitters. These features result in better coexistence with other wireless devices in the 2.4 GHz frequency range and an improved experience for users.
Silicon Labs Bluetooth Solutions
Offering full software stacks, system-on-chip (SoC) devices and pre-certified modules, our Bluetooth solutions help you get to market faster, even with little RF development experience. Our EFR32BG21 (BG21) devices include a host of security features and are ideal solutions for connected lighting, gateways and smart plugs.
For battery-powered devices with direction finding requirements, we recommend EFR32BG22 (BG22). It is one of the lowest power Bluetooth devices on the market and can operate 5-10 years on a coin cell battery. We invite you to attend our Virtual Workshop in May, 2020, to get hands-on experience with your own BG22 Thunderboard.
Today we announced a major addition to our wireless portfolio with the completion of our Redpine Signals’ connectivity business acquisition. This expansion of our IoT roadmap allows us to bring you a comprehensive suite of low-power Wi-Fi and Bluetooth solutions for smart home, industrial and commercial IoT applications.
Redpine’s Wi-Fi assets and intellectual property enable the low power, performance, security and interoperability requirements needed in environments with hundreds or thousands of connected IoT devices. The acquisition also includes Bluetooth Classic IP for audio applications including wearables, hearables, voice assistants and smart speakers.
We’re excited to have the talented Redpine Signals’ employees join our world-class engineering team, and we look forward to working together to best serve you and get your products to market quickly.
The right balance of features, size, power, and cost, while supporting dual-protocol simultaneously on one device – these are the elements that developers think about when considering networking technologies. In this Tech Talks session, our Field Applications Engineer (FAE), Tim Sams, details what developers need to know to get started with 15.4 Mesh Networking (Zigbee and Thread protocols) along with our appropriate tools and platforms. Click here to hear the entire 15.4 Mesh Networking Technologies session and register now for future Tech Talks. Below are some key takeaways from Tim's session.
The Foundation of Zigbee Technology
Zigbee technology is built in a full stack on four layers as follows:
Layer 4 (Conformance |Certification & Logo) – the enforced conformance and interoperability components through a couple of certification levels: platform certification and product certification. The former is achieved by Silicon Labs to verify the operation of our hardware and stack software as a certified platform where developers’ devices can be built upon. The latter is achieved by customers and device makers by testing their implementation of a device type using Silicon Labs’ stack and hardware – this includes joining the Zigbee Alliance to use the Zigbee name and logo on their products.
The Power of Zigbee Software
There are many reasons why developers use Zigbee technology. First, Zigbee software has a complete solution with a fully integrated stack architecture and fully certified Zigbee 3.0 platform, including Zigbee 3.0 devices, Green Power device support, and smart energy application support. Second, it is highly flexible and easy to use with its seamless integration with AppBuilder, handling all the common use cases like commissioning, security features of Zigbee, OTA upgrades, and bootloaders. Third, the Zigbee software is field upgradable wherein developers can do over-the-air firmware updates and NCP firmware updates over a serial interface.
Tim also gave a quick overview of the Zigbee 3.0 (EmberZBet) SDK roadmap, which includes building a certification program for Zigbee devices that developers want to connect to their hubs. This initiative is called Works With All Hubs. Another similar program is Friends of Hue, which is specifically for Philips Hue devices and ecosystems. Sometime around Q2 of 2021, new networking improvements to the Zigbee PRO network will lead to an upgrade to Zigbee R23, adding new security features, commissioning features, and improvements to routing.
Thread and the OpenThread SDK
Thread is another 15.4 mesh-based technology supported by Silicon Labs. It has similar technology as Zigbee but Thread’s key differentiator is that it is IPv6-based. Thread also does not define an application layer, as it is a networking protocol only, providing the communication layer for any kind of application layer. Tim likened this structure to a Wi-Fi network being a Wi-Fi backbone, but all the TCP, UDP, and application layers that run on a Wi-Fi network are up to the user. Just like Zigbee, Thread is intended for control and automation and was built around the IoT premise, specifically for smart home and commercial building applications.
OpenThread is an open-source implementation of the Thread networking protocol and it is currently at specification version 1.1. We currently offer OpenThread with 1.1. certification on three devices: EFR32MG12, EFR32MG13, and EFR32MG21.
Managed Wi-Fi Co-Existence and a Common Platform
Wi-Fi co-existence is one of the many value add-ons when using 15.4 Mesh protocols through our platform, especially in gateway type devices. These gateway devices typically have an enterprise-grade, multiple-input, multiple-output Wi-Fi, operating in adjacent channels in the 2.4 gigahertz ISM bands – making them prone to mistransmissions and other errors. To solve this problem, we developed a 1-4 wire managed Wi-Fi coexistence interface that manages packet traffic based on the 802.15.2 standard. We also offer a tool called Network Analyzer that provides a holistic view of what is happening across the network, combined with our hardware packet trace interface, without negatively affecting radio performance.
All our protocol stacks – Bluetooth, OpenThread, Zigbee, and Flex SDK – are all built on a common platform. The same Radio Abstraction Interface Layer (RAIL) and bootloaders are used, no matter what hardware or protocol stack is used. This provides extreme maximum flexibility and makes developing with several different protocols significantly simpler, because of so many shared components, tools, and development environments.
Getting Started with Mesh Module Portfolio
To get started with your mesh networking development, visit our Thread Networking Solutions and Zigbee Wireless Networking Systems product pages which include comprehensive information about what kits to order, including wireless starter kits that include three boards for developers to run a small mesh network with their devices.
The Tech Talk ended with a question and answer session, and you can find the transcript here.
As I write this, many of us around the world are working under COVID-19 quarantine conditions. So before diving in, I want to wish all of you and yours the very best of health. Please take care of yourselves out there!
Now to recap so far:
In Part 1 of this series, I discussed the parasitic PLL in which an independent oscillator can couple energy into a Phase-Locked Loop’s (PLL’s) VCO which can impact the PLL’s output frequency and phase. I then reviewed some basic injection theory including the concept of injection lock range. In Part 2, I discussed how to minimize injection sensitivity. In this last and final Part 3, I will discuss the topic of measuring injection sensitivity, and what one can do with that information.
ILBW (Injection Lock Bandwidth)
The figure below was presented in Part 1 and follows Wolaver’s development culminating in this equation with the important takeaways noted.
Wolaver treated the injection constant or gain KINJ as the injection lock range. It is useful to think of this lock range as the Injection Lock Bandwidth or ILBW to contrast it with the PLL’s loop bandwidth BW. In order to minimize the risk of injection locking we want
ILBW < BW
In fact, we would prefer for ILBW << BW. A practical empirical rule of thumb we have applied is the following
ILBW <= 0.3 * BW
We will apply this rule of thumb in later example calculations.
ILBW Practical Issues
Let’s take another look at Wolaver’s equation for KINJ as the injection lock range aka the Injection Lock Bandwidth or ILBW. In the annotated figure below I call out some practical issues.
There are several difficulties that may arise when attempting to make direct calculations of this equation based on measurements of the individual factors:
Provided one can apply a calibrated high frequency interferer, it is often easier to measure the effective ILBW. The rest of this post will discuss a couple of ideas on how to do this.
ILBW Measurement Approaches
This post will discuss two different measurement approaches summarized in the table below. The first method applies an asynchronous aggressor source and uses the offset spur result measured on a spectrum analyzer to estimate the ILBW. The second method applies a synchronous aggressor source and measures the ILBW directly from a phase noise analyzer.
These methods will be demonstrated using older simpler architecture devices where injection may be conveniently observed. Modern clock devices are generally less susceptible to injection due to architecture, shielding, etc. The examples that follow will give an indication of what you might observe with classic narrow bandwidth single loop PLLs.
PLL Injection Sensitivity – Estimating ILBW via Asynchronous Injection
Using this first approach, we measure the spur that results on the output for a given asynchronous but near-synchronous injection applied to the device. The general idea is to configure the DUT as typical, using an input clock source that does not have significant harmonics at or near the PLL’s VCO frequency. Then apply an interferer or aggressor clock set near the VCO frequency to individual pins and determine the worst case.
The general test set-up used years ago for the Si53xx SONET devices was as follows:
A general comment about probes: One can measure the voltage at device pins using a divide-by-10 high impedance differential probe, even if not specified to operate at the intended frequency, if carefully calibrated. Back when this data was collected the probes available had a 20 dB calibrated loss at 2.5 GHz.
So for a -20 dBm interferer we would expect a signal at the device pins as follows assuming no additional losses.
-20 dBm applied interferer
-20 dB due to divide-by-10 probe
-20 dB due to probe roll off at 2.5 GHz
-60 dBm measured at device pins
How can we use this technique to estimate the ILBW or Injection Lock Bandwidth? Here are the steps.
PLL Injection Sensitivity – Example Estimated ILBW Calculations
The figure below shows the spectrum for an Si53xx SONET clock device configured for an output of 622.08 MHz together with the resulting injected spur. The DUT used a post VCO output divider N = 4 to yield output frequency f0 = 622.08 MHz. For this device, the DUT VCO frequency or ftank = 622.08 MHz x 4 = 2.48832 GHz.
Here are the example calculations in this instance:
The minimum operating BW for this part is 800 Hz. Applying the rule of thumb ILBW is much less than 0.3 * 800 Hz or 240 Hz. Therefore we do not expect injection lock to be an issue.
Another way of looking at the problem is to ask: For a given loop BW selection how large a spur, referred to the tank frequency, am I allowed to have using the rule of thumb?
Pspur_tank (max allowed) = 20*log10(fILBW/foffset) dBc
= 20*log10(0.3*fBW/foffset) dBc
Using the same example situation as before:
Pspur_tank (max allowed) = 20*log10(0.3*800/20000) dBc
= -38.4 dBc
Injection Lock Tolerance
We can apply the information described above, together with worst case pin data, to estimate how much interfering signal the device pins can tolerate before injection lock may cause jitter to be an issue. The worst case data suggested that the interferer amplitude at a pin may be as low as –50 dBm and yield a spur as high as –44 dBc.
Using this worst case pin assumption, then the worst case spur at the tank would be:
Pspur_tank_wc = -44 dBc + 20*log10(4) = -44 dBc + 12 dB = -32 dBc
Recall that the Pspur_tank (max allowed) for an 800 Hz BW is -38.4 dBc and so we must decrease the allowable interferer signal strength at the pins to –50 dBm – (38.4-32) = -56.4 dBm. As a practical matter, we should then decrease this by at least another 6 dB to add margin. This suggests the following criterion for the Si53xx clock chips:
The interferer strength at a device pin should not exceed –62 dBm.
This conservative criterion means that Si53xx clock devices should not injection lock unless an extraneous 2.5 GHz source can inject a signal > –62 dBm at an individual pin.
What if we had an especially noisy application where this limit was exceeded? If significant interfering energy is present, filtering, attenuation, and good layout can reduce the level of conducted interference on sensitive pins.
PLL Injection Sensitivity – Measuring ILBW via Synchronous Injection
In this second approach, we apply a synchronous interferer and observe the impact of injection lock directly on the phase noise plot.
The figure below illustrates the basic idea.
Engineers who are familiar with phase noise plots will recognize that the injection locked oscillator phase noise truly looks “locked” just as if it was in a designed PLL, and not in an incidental or parasitic counterpart.
Evaluation Board Experiments Setup
To demonstrate the phase noise analyzer approach, I used an RF Synthesizer evaluation board which has convenient VCO frequencies for my purposes. The figure below summarizes the test set-up.
In this case however, I did not want to use a purpose-built board or inject an interfering signal at all the pins. Instead, I decided to simply remove the bypass caps and inject the synchronous interferer directly in to the power supply. You can think of this as a high frequency extension to PSRR or Power Supply Rejection Ratio testing. In other words a sort of IPRR or Injection Pulling Rejection Ratio test.
Here are the main points:
Evaluation Board Experiments Phase Noise Plots
The phase noise plots below were based on data measured on an old Agilent (now Keysight) JS-500 rack system which is an E5500 superset. One of the features that’s nice about this older equipment is that the user has direct access to the measurement PLL’s loop BW. This allows one to measure very noisy and even open loop phase noise plots.
You can read the ILBW directly from the intersection of the locked phase noise plots versus the open loop phase noise plot. As suggested by the Wolaver equation, increasing the power of the injected signal results in a wider ILBW which would restrict the loop bandwidths at which the device would operate.
In these experiments, ILBW only approached 10 kHz even with a +10 dBm synchronous signal injected in to the power supply. Note that the Si4133 is not operated as a jitter attenuator but rather as a clock generator with a good quality TCXO as the reference source or input clock and a typical operating bandwidth ≈ 200 kHz.
Estimated versus Measured ILBW
In the 2009 ACISC paper in the references, I compared both methods applied to the RF Synthesizer and obtained good agreement. See the figure below comparing ILBW as estimated based on 1 MHz offsets versus direct measurement.
Injection Lock Troubleshooting
Injection lock may be an issue if the device’s clock output jitter is out of spec, cannot be accounted for given the input clock’s phase noise, and the device’s Jitter Transfer Function, and exhibits an unexpected jitter distribution. A suspicious example of the latter would be a bimodal jitter distribution.
A general troubleshooting procedure is listed below. Try each of these items in turn and check to see if the situation improves.
In the particular case of Si53xx clock ICs, application note AN59 describes generally good layout and filtering practices.
In this and the previous related blog posts, I have reviewed injection pulling and lock, injection mitigation, and practical measurements. Here are the main points to sum up:
The same references that applied to the previous posts apply here. They are repeated again below for convenience.
Some of the material covered here was presented at the Austin Conference on Integrated Systems and Circuits (ACISC) in 2009. If you are interested, you can email me to request a copy of the paper “Practical Issues Measuring and Minimizing Injection Pulling in Board-level Oscillator and PLL Applications” and accompanying slides.
As mentioned previously, the best practical overall book treatment I am familiar with is in Wolaver’s text:
This is a slim volume for a PLL book but it punches well above its weight in terms of information.
Here are several foundational papers worth reading on the topic of injection.
If you have favorite references you would like to share, please pass them along to me.
I hope you have enjoyed this Timing 201 series on injection lock.
As always, if you have topic suggestions, or there are questions you would like answered, appropriate for this blog, please send them to firstname.lastname@example.org with the words Timing 201 in the subject line. I will give them consideration and see if I can fit them in. Thanks for reading. Keep calm and clock on.
With the release of Bluetooth specification 5.1, Bluetooth direction finding capabilities have become a cost-effective, low-power solution for location services. In this Tech Talks session, Silicon Labs field applications engineer, Claudio Filho, explains the advantages of using Bluetooth AoX direction finding over other Wi-Fi or received signal strength indicator (RSSI)-based solutions. You can watch the entire Bluetooth AoX session here and register now for future Tech Talks. Some highlights from Claudio’s presentation are below.
Use Cases for AoX Location Services
Asset management and indoor navigation have increasingly become an enterprise requirement. The following are use cases where Bluetooth AoX (angle of arrival or angle of departure) solutions provide optimal proximity and location services:
Why Bluetooth Direction Finding?
Bluetooth direction finding offers the following key advantages:
Other technologies for direction finding are available, such as Ultra-Wide Band (UWB), but they are power-hungry and increase BOM cost for components such as an extra radio, passives and antennas.
How Does Angle of Arrival (AoA) and Angle of Departure (AoD) Enable Direction Finding?
Bluetooth direction finding relies on two methods for calculating location: Angle of Arrival (AoA) and Angle of Departure (AoD). With AoA, a mobile transmitter, which is a simple tag with a single antenna, transmits a signal to a receiver comprised of multiple antennas, called “locators”, positioned at fixed locations. As the signal passes to each antenna, a difference in phase shift occurs, which can be used to calculate the Azimuth and elevation of the transmitter. By collecting these angles, a position engine associated with the locators calculates the absolute position of the tag.
With AoD, the direction finding process is reversed. In this case, the antennas are the transmitters and wireless tags act as receivers. Each receiver computes its own positioning based on calculated data from the transmitter. Because the computing power required for an AoD receiver is much higher than in AoA, this technology is not widely used today.
Our Direction Finding Solutions
We offer several hardware and software direction finding solutions for asset tags, locators and beacons.
EFR32BG21 is a simple, RSSI solution for generic gateways and is optimized for best performance. EFR32BG22 SoC (BG22) is our most cost-competitive Bluetooth AoX device. It features ultra-low transmit and receive power and achieves 1.4 uA with full RAM retention in Sleep Mode. BG22 also comes with advanced security features such as secure boot with root of trust, a one-time programmable key, and secure debug lock and unlock. A forthcoming BG22 reference design will include schematics, PCB and BOM, and a 4x4 antenna array that provides AoA performance down to 1 degree of accuracy.
Software for tags and beacons includes our standard stack, along with an added CTE implementation and real-time location library used to collect IQ samples and make calculations.
Silicon Labs and Quuppa
According to Claudio, many customers are interested in AoA technology but lack the infrastructure and resources to deploy it. For this reason, we have partnered with Quuppa, a technology company with more than 15 years of location services experience offering a ready-to-install, AoA infrastructure including locators and position engines. Quuppa locators and position engines can track any EFR32BG22 device, helping customers get to market much faster than having to develop all the infrastructure on their own.
Watching the COVID-19 pandemic unfold in recent months is something none of us will forget in our lifetimes, and its devastation will be told for generations to come. The virus has impacted each of us in numerous ways and is a stark reminder of the fragility of life. Yet it also reminds us how interconnected humans are and how much we depend on one another every day.
During this crisis, we have seen the world come together to help people however possible. At Silicon Labs, we’ve carefully considered our options to give back and make a difference in ways that will be most impactful on our communities. We recently announced donations to All Together ATX and American Red Cross, in addition to allocating funds for each of our global sites to donate to non-profits providing COVID-19 relief in their communities. We recognize the need to support organizations working on the front lines to address immediate and long-term needs of those who are sick, don’t have access to food and critical supplies, or have lost their jobs due to the pandemic.
We’ve also seen the impact on local businesses. Many restaurants and food truck operators that our employees have relied on greatly throughout the years have had to dramatically reduce or cease operations due to COVID-19. My family and I are frequent supporters of Austin’s nearby restaurants and food trucks – we typically buy at least 4-5 meals a week from nearby places – and I know I’m not alone. Many restaurants here in Austin are struggling to stay open, and some have already gone out of business, such as Threadgills, which closed earlier this week. Sadly, this situation is no different for restaurants in other regions of the world.
To help, we’re excited to announce a new program April 24-May 1 – #ieatlocal, aimed at supporting local restaurants and food trucks during this difficult time. We’re adding $15 to the paychecks of our 1,500+ employees to purchase a take-out meal from their favorite local restaurants. We’re asking employees to share their experience on social media and to encourage others to join in on the movement to support local restaurants by ordering take-out in their communities. We’re also reaching out to other companies and encouraging them to duplicate our efforts to make an even larger global impact.
This week, we shared our plan with Cheryl Cunningham, owner of DFG Noodles, one of the long-time food truck vendors that has come to our downtown Austin headquarters on Fridays for the past five years. Cheryl sent us a heartfelt thank you email shortly after we spoke, cementing my belief that this program could really make a difference, writing: “We are ever so grateful for the incredible lifeline you are throwing us by starting something that will hopefully spur other corporations to do the same and actually change our current trajectory of complete business shutdown to at least sustainability.”
Giving back to our communities has been a cornerstone of Silicon Labs since we were founded 24 years ago. And right now, it is more important than ever. Please join us in our #ieatlocal movement to support your favorite local restaurant during this tumultuous time. Every meal we order can make a difference, especially if we all do it together.
CEO | Silicon Labs
As part of our mission to create a smarter, more connected world, Silicon Labs has had a long history of giving back to organizations helping our communities. Since 2013, I have had the honor of serving on the board of the Central Texas Chapter of the American Red Cross and am currently serving as board chair. During my time with the organization, the Red Cross has been on the front lines of countless emergencies around the globe. From house fires to Hurricane Harvey to floods in Tennessee to wildfires in Australia, the Red Cross has provided vital services to people in need, helping communities rebuild and thrive.
We’ve seen this stated many times over the past few months and it couldn’t be more true - the COVID-19 outbreak is unprecedented. Nearly two million people around the world have been infected, more than a hundred thousand have died, and the numbers continue to rise every day. Yet through the heartbreaking loss and sorrow, we have also seen incredible acts of humanity and innovation emerge.
One innovative way the Red Cross is helping address the pandemic is through a new program using plasma donations from fully recovered COVID-19 patients. The convalescent plasma is being evaluated as treatment for people with serious or immediately life-threatening COVID-19 infections, or those determined to be at high risk of progression to severe or life-threatening disease. In addition, the Red Cross, with responsibility for approximately 40% of the nation’s blood supply, is continuing their essential blood and platelet collection program used to help people of all ages suffering from many different types of illnesses. We are pleased to support the American Red Cross with a $50K donation for their COVID-19 relief efforts, including blood and serum collection and related work.
It will take everyone -individuals, businesses, governments, nonprofit organizations - coming together to stop the spread of COVID-19, and to lessen its impact on our communities. We are proud to be able to support the lifesaving work of the Red Cross and are grateful for all of their efforts today and every day.
For more information about the Red Cross, visit redcross.org, and click here to donate. To find out more about how we fulfill our corporate value to "do the right thing" by giving back, visit our community commitment page.