Last month, we had the chance to speak with David Simpson, Chief Product Officer, and IoT Product Manager Logan Stover, at Enseo. If you’ve ever stayed in a hotel room and watched an on-demand movie or streaming service on the TV, you’ve probably used the Texas-based company’s technology.

Enseo reaches more than 84 million people annually through their platform. A few years ago, the company expanded its hospitality offering into safety and created an IoT employee safety device using Silicon Labs’ wireless technology. The new product contributed to an industry-wide conversation in hospitality around steps employers can take to help prevent housekeeping staff assault incidences.

Today, four years after launching the system, the MadeSafe® product is used by many housekeeping employees across many of the largest hotel brands, including Marriott. David and Logan share some details below about the company and how the safety product came about.

Can you tell me a little bit about Enseo?

Today we have four core products in one platform, including in-room entertainment, high-speed Internet, IoT energy management and room control, and the MadeSafe employee safety system. The demand for this platform grew quickly, and we have ventured into other adjacent markets, including education, hospitals and government. Enseo got its start almost 20 years ago after creating one of the first TV channel scroll guides for cable TV. Soon after that, Enseo entered the hospitality market.

How did MadeSafe come about?

One reason why MadeSafe is so useful is because hotel employees are often alone during the work day while servicing hundreds of rooms. Several years ago, the press was focused on a sexual assault case involving a New York City housekeeper and a prominent international politician. The case garnered a great deal of media attention about sexual assault in the hospitality sector. Shortly after the case, several New York City hotels approached us about designing an employee safety product. Enseo deployed the first generation of MadeSafe at the J.W. Marriott Essex House in 2015.

According to the Center for American Progress, 25 percent of all sexual assault charges filed are in industries with a large number of service sector workers who are often women.

By late 2017, the #metoo movement brought these issues to the attention of everyone. Hoteliers and cities began creating ordinances, while unions brought the issue to a higher level of attention, inspiring several communities and the American Hotel and Lodging Association to be more aggressive in industry requirements around safety. Today most hotels are committed to installing this technology by the end of 2020. The hospitality industry is leading other industries in proactively addressing these safety concerns.

How does the product work?

Each employee wears a small wireless device that looks similar to a car key fob. If the employee feels threatened, they simply press the button, and a geolocation signal is immediately sent to designated safety personnel, showing exactly where the employee is located on a 3D property map. Employees can only be tracked when the button is pressed, which was an important privacy element we built into the product.

Why did you use Silicon Labs to help design the product?

Silicon Labs’ multiprotocol functionality and performance, along with cost, were the key differentiators for us while considering the design of our latest generation of MadeSafe product. Also, of key importance to us was the multiple protocol capability to keep options open for later generations of the MadeSafe system and other IoT future products. The Silicon Labs multiprotocol Wireless Gecko platform was easy for Enseo developers to use, allowing us to incorporate both Zigbee and Bluetooth protocols into the product. The platform’s capabilities to enable over the air updates and the Simplicity Studio development kit were also critical to our development team, as it helped simplify and speed the design process. Our design team, who was already familiar with Silicon Labs systems, also liked the scalability and flexibility of the software ecosystem.

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

IoT security needs more attention from both silicon and software providers. Hardware, in particular, has a key role to play in security, but up until now, hardware hasn’t had a pivotal role. We see this changing in the future. The future of IoT will bring an enormous number of new devices into the market, many of which we have not even begun to imagine. While cost pressures will be substantial moving forward, we will need flexible and innovative software to meet pricing and development cost demands.

Introduction

Hello and welcome to the latest article for the blog series, Timing 201. This is a sequel to the article Timing 201 #1: The Case of the Phase Noise That Wasn’t – Part 1. In this post, I follow-up on Part 1 and suggest that both a limiting amplifier and balun are useful accessories to minimize AM and make good phase noise measurements. I include some example data and close with a few rules of thumb.

A Quick Review from Part 1

You will recall the basic idea we last explored was that AM (Amplitude Modulation) noise can impact phase noise measurements. (AM noise is the apparent “phase noise that isn’t”.) A spectrum analyzer cannot distinguish between AM and PM (Phase Modulation) or phase noise. Purpose-built phase noise measurement instrumentation can suppress but not eliminate AM to PM conversion. The use of a limiting amplifier can further reduce the impact of AM noise on phase noise measurement. This can be a valuable troubleshooting tool when investigating system-level clock noise and spurs.

Example Limiting Amplifier AM Rejection

First, a few words about the particular limiting amplifier used for data collection in this article. The ideal limiting amplifier or LA would be high gain, low noise, wideband, and modestly priced. That combination is hard to find.

The sample LA used here is the Hittite (now Analog Devices) HMC750 which has a 3 dB bandwidth of 11 GHz. An evaluation board is available from distributors though it’s relatively expensive. There are other LAs available from other vendors, and if you buy units in quantity and/or roll your own PCB, you can certainly lower your costs. 

Two suggestions if you do use the Hittite evaluation board:

1. Replace the 0 Ω resistors used in the I/O paths with 1 mF 0402 capacitors. This will allow routine AC-coupled operation without having to attach external DC-blocking caps.
2. Scrape the EVB solder mask in the vicinity of the SMA connector mounts and fillet solder them to the PCB. This will make the connectors more mechanically secure. I know from personal experience that these can “torque off” if you are not careful. <Thanks to Scott McMullen here for repairing and updating the last board.>

As a reminder, the time domain operation of the LA is illustrated as follows. Below left is a scope capture for a 100 MHz single-ended sinusoidal clock. The AM depth was 5% and the scope is set to infinite persistence. Below right is the same single-ended clock through the example limiting amplifier.

While the time domain operation is suggestive, AM rejection is better measured in the frequency domain. In the following measurements, a Keysight E5052B was used both as the measurement instrument and as a stand-in clock receiver. I employed a Keysight 33600A Waveform Generator, operating single-endedly, to apply AM at several frequencies and measured both the AM and phase noise spur amplitude. The carrier was 100 MHz and the AM depth was set to 1%. Getting a consistent AM spur above the noise floor was what I was looking for.

I then inserted the cited LA and repeated the same measurements. 

Note the new noise columns that had to be added. The LA effectively eliminated the AM spur completely, reducing it to the noise floor. There is still a corresponding phase noise spur, reduced also. (Subsequent testing indicated this was incidental phase modulation from the source.)

Here is a sample plot for the 100 kHz case with no intervening limiting amplifier. The phase noise window is displayed at the top and the AM noise window is displayed at the bottom. Marker 1 in each window is set at 100 kHz.

And here is a corresponding sample plot for the 100 kHz case when using the limiting amplifier. As I mentioned previously, the AM spur is eliminated which I was looking for. The corresponding phase noise spur dropped another 12 dB. For some reason, at least for this sample, the AM noise floor above 10 kHz is not flat as would be ideal.

In general, we should use a limiting amplifier if AM noise or spurs are significant with respect to phase noise. In a measurement system that can measure both, we typically want AM noise or spurs to be at least 10 dB below phase noise or spurs at the same offset frequencies. (We weren’t quite getting that in the first table above.)

Ideally, the same would be true for the clock receiver accounting for its AM rejection. For example, if both the input clock’s AM noise floor and phase noise floor were the same at a particular offset frequency, then we would want the clock receiver to reject or attenuate AM noise further by 10 dB. This performance is not always specified and may need to be measured. It is also often a function of the input clock slew rate or rise/fall time. 

Differential Signaling

A limiting amplifier is useful for removing AM from both single-ended and differential clocks. However, differential clocks are themselves an important approach to combating AM noise.

One of the most important reasons for differential signaling on balanced lines is common mode (CM) noise rejection. Since most AM noise on differential signals is CM (e.g. due to power supplies) then differential receivers will tend to reject AM. This can be illustrated pictorially in the figures below.

First, consider amplitude noise impressed upon a single-ended clock.

Now, consider the same amplitude noise impressed upon a differential clock.

There are several aspects to the diagram worth noting:

1. Differential signaling needs equal CLKP and CLKN path lengths to minimize skew and DM to CM conversion. The PC board should be laid out to enforce this.
2. A split termination as shown will further minimize CM noise due to any unintended skew. (Please see
   Timing 101: The Case of the Split Termination.)
3. The differential clock receiver needs good Common Mode Rejection or CMR. Typical differential receivers should have CMR ³ 60 dB. However, this should be verified for the offset frequencies of interest.

All of these will help to prevent CM AM noise from impacting the measurement.

Unfortunately, most spectrum and phase noise analysis instruments have single-ended inputs and don’t directly support differential measurements. If we replace the receiver in the diagram with an instrument, what is the best approach?

A ready measurement would be to route one differential clock polarity, e.g. CLKP, to the instrument and terminate the unmeasured polarity output, e.g. CLKN, in to 50 Ω. Generally you will want to AC-couple these so as to present roughly the same impedance. The necessity for balanced termination is discussed in Timing 101 #10: The Case of the Half-terminated Differential Output Clock. 

This is a valid measurement but is overly conservative as it neglects the advantage that would actually be experienced in a differential clock system. What we need is a device that will convert the differential signal to a single-ended signal. Such a device is known as a balun (taken from balanced to unbalanced).

This could be in the form of an amplifier (sometimes called an active balun) or more typically a passive component. As an example of the latter, a classic transformer balun or voltage balun has a center-tapped winding on one side for converting 100 Ω differential to single-ended 50 Ω.

The example balun used in these tests is the Tektronix (formerly Picosecond Pulse Labs) PSPL5310R. This is a phase matched balun which can operate from 4 MHz to 6.5 GHz. Unfortunately, for some reason, these are no longer available from Tektronix.

Other vendors which sell baluns include MACOM, Marki Microwave, and Mini-Circuits. (This is not meant to be an inclusive and exhaustive list. These are just companies I am familiar with.)

Look for a balun wideband enough to pass the necessary waveform with sufficient risetime and with good phase and amplitude balance. The old PSPL balun had anywhere from ± 0.5 to ± 2 degrees differential phase balance and ± 0.1 to +0.3/0.2 dB differential amplitude balance depending on the frequency range. 

Example DUT with AM Noise

I have selected for a practical example one of my favorite “desert island” parts, the venerable Si570 which is an older generation programmable oscillator. It was the first 5 mm x 7 mm I2C programmable oscillator that could cover 10 MHz to 1.4 GHz. Radio amateurs may recognize this device as used in some “Softrock” SDR (Software Defined Radio) applications.

Not only can it support such a wide frequency range but it can also be ordered with “real” LVPECL drivers. By this I mean it can drive DC-coupled LVPECL loads defined as 50 Ω terminated in to VDD – 2V.  (By contrast, clock devices typically provide LVPECL compatible modes where they can supply the right swing when AC-coupled.)  There is some CM (Common Mode) AM noise using this mode. However, this is mitigated when used differentially as intended. 

Below we will tabulate several measurement scenarios with and without a balun and LA. The DUT is an evaluation board with P/N 570AAA000121DG installed operating AC-coupled.  This is a differential programmable XO with a 100 MHz starting frequency, output format 3.3V LVPECL. 

Here are the phase jitter results for various configurations.

The biggest bang for the buck so to speak was using a balun. That got us to the 300fs range or less which is what we expect this device to yield. (The closest Si570 datasheet spec is 360 fs typical for Fout from 125 to 500 MHz.)

Here are a few plots to go with this table.

First, the single-ended configuration with the highest phase jitter, over 600 fs. Note the several spurs above 1 MHz in both the AM and phase noise measurement windows. 

Next is the balun only configuration which eliminates some spurs and drops the phase jitter roughly in half, i.e. below 300 fs.

Finally, here is the phase noise plot combining the DUT driving the LA differentially which in turn drives the balun connected to the E5052B. This plot eliminates all the spurs above 1 MHz and still keeps the phase noise floor mostly below -150 dBc/Hz beyond this offset frequency.

Virtual Limiting Amplifier

Ignoring spurs, it is possible in principle to estimate the DUT’s post-LA phase noise performance by mathematically applying a “virtual limiting amplifier”, if you know what the LA AM noise floor will be and what the AM to PM conversion is for your instrument. However, that is a topic for another time.

In practice, as one peels the onion to achieve lower and lower phase noise measurements, spurs play an increasingly larger role. This can be problematic for estimation purposes since even if the location of spurs can be predicted, often their amplitudes cannot.

A Few Rules of Thumb

Based on this and the previous Timing 201 post, here are a few suggested rules of thumb when making phase noise measurements on sources that may have AM noise:

Having a good limiting amplifier and a good balun on your bench can help you make more accurate phase noise and jitter measurements, and help distinguish the type of noise contributors you are dealing with. If you are working with differential clocks, you really should use a balun even if AM noise is not that significant.

Conclusion

I hope you have enjoyed this Timing 201 article. If you have a favorite balun or limiting amplifier you would like to share with others, please let me know.

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 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.

Cheers,

Kevin

Introduction

The Silicon Labs Examples in Simplicity Studio are very easy to access: You connect your Starter Kit and Simplicity Studio will display the list of examples as shown below:

 

We hope that you can find the most appropriate example to test your starter kit and hopefully base your design from one of the examples featured in Simplicity Studio.

But, in case you can’t find the example you were looking for, we have a wide variety of unpublished examples in a public repository. Like when you go to a store and ask one of the store's employees to see if the item you want is in the "back room" because you couldn’t find it on the shelves; The Silicon Labs back room for those examples you couldn’t find as part of Simplicity Studio is our repository in GitHub:

https://github.com/SiliconLabs

There you will find examples for pretty much all the Silicon Labs devices.

In this blog, I will show you how to access the EFM32/EFR32 Peripheral Examples.

 

 

EFM32/EFR32 Peripheral Examples

This repository contains low-level examples for each peripheral on the EFM32 and EFR32 devices:

https://github.com/SiliconLabs/peripheral_examples

The examples are organized by Series and then by Peripheral name as illustrated in Figure 2:

 

 

Device Series

If you want to find out what Series is your device, you can look at the package marking and the number highlighted in the table below is the series number:

EFM32/EFR32 Devices Series
Series 0	Series 1	Series 2
EFM32ZG	EFM32PG1	EFR32BG21
EFM32HG	EFR32MG1	EFR32MG21
EFM32TG	EFR32BG1
EFM32G	EFR32FG1
EFM32LG	EFM32PG12
EFM32GG	EFR32MG12
EFM32WG	EFR32BG12
	EFR32FG12
	EFR32MG13
	EFR32BG13
	EFR32FG13
	EFR32MG14
	EFR32BG14
	EFR32FG14
	EFM32GG11
	EFM32TG11

Table 1 Devices by Series

 

Peripheral Name

The table below lists all the device peripherals along with their description:

EFM32/EFR32 Peripherals
Name	Description
ACMP	Analog comparator (ACMP) Peripheral.
ADC	Analog to Digital Converter (ADC) Peripheral.
AES	Advanced Encryption Standard Accelerator (AES) Peripheral.
ASSERT	Error checking module.
BURTC	Backup Real Time Counter (BURTC) Peripheral.
BUS	BUS register and RAM bit/field read/write.
CHIP	Chip errata workarounds initialization.
CMU	Clock management unit (CMU) Peripheral.
COMMON	General purpose utilities and cross-compiler support.
CORE	Core interrupt handling.
DAC	Digital to Analog Converter (DAC) Peripheral.
DBG	Debug (DBG) Peripheral.
DMA	Direct Memory Access (DMA) Peripheral.
EBI	EBI External Bus Interface (EBI) Peripheral.
EMU	Energy Management Unit (EMU) Peripheral.
GPIO	General Purpose Input/Output (GPIO).
I2C	Inter-integrated Circuit (I2C) Peripheral.
INT	Safe nesting of interrupt disable/enable.
LCD	Liquid Crystal Display (LCD) Peripheral.
LESENSE	Low Energy Sensor (LESENSE) Peripheral.
LETIMER	Low Energy Timer (LETIMER) Peripheral.
LEUART	Low Energy Universal Asynchronous Receiver/Transmitter (LEUART) Peripheral.
MPU	Memory Protection Unit (MPU) Peripheral.
MSC	Memory System Controller.
OPAMP	Operational Amplifier (OPAMP) peripheral.
PCNT	Pulse Counter (PCNT) Peripheral.
PRS	Peripheral Reflex System (PRS) Peripheral.
RAMFUNC	RAM code support.
RMU	Reset Management Unit (RMU) Peripheral.
RTC	Real Time Counter (RTC) Peripheral.
SYSTEM	System.
TIMER	Timer/Counter (TIMER) Peripheral.
USART	Universal Synchronous/Asynchronous Receiver/Transmitter Peripheral.
USBD	USB Device Peripheral.
VCMP	Voltage Comparator (VCMP) Peripheral.
VERSION	Version.
WDOG	Watchdog (WDOG) Peripheral.

Table 2 Device Peripherals

 

 

Accessing the Peripheral Examples

To access the peripheral examples take the following steps:

Clone or Download the repository to the following path in your Simplicity Studio installation:

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v#.#\app\

where #.# is the Gecko SDK suite version number

 

Import the example you want from Simplicity Studio by making one of the following series of clicks:

File -> Import, or

Project -> Import -> MCU Project

 

To access the examples from IAR, simply navigate to the desired .eww file and double click on it.

 

 

 

Further Reading

• EFM32/EFR32 Peripheral API Reference: 

https://siliconlabs.github.io/Gecko_SDK_Doc/index.html

• Simplicity Studio Manual:

https://www.silabs.com/documents/public/application-notes/AN0822-simplicity-studio-user-guide.pdf

Last week, the Bluetooth SIG announced to its members an update about security vulnerability related to the encryption key negotiation protocols. According to the SIG, researchers of SUTD, CISPA and Oxford University identified a vulnerability with the encryption key negotiation protocol of Bluetooth BR/EDR. The attack makes it possible for a third party to make the victims to agree on an encryption key with only 1 byte (8 bits) of entropy, which then enables the attacker to brute force the negotiated encryption keys, decrypt the eavesdropped ciphertext, and inject valid encrypted messages in real-time. The attack is standard-compliant because all Bluetooth BR/EDR versions require to support encryption keys with entropy between 1 and 16 bytes and do not secure the key negotiation protocol. (More information about the details of the attack for example here www.knobattack.com)

Our Wireless Gecko Bluetooth products (Blue Gecko) and BLE112, BLE113, BLE113, BLE121LR and BLED112 module products are not affected by this issue because they are based on Bluetooth LE core specification which does not have this vulnerability.

Our Bluetooth BR/EDR (BT Classic) products, which include the WT12, WT11u, WT41u, WT32, WT32i, BT111 and BT121 modules, are vulnerable to this issue. We plan to release a patches which protect against this vulnerability during October 2019