We recently had the chance to speak with Jean-Noel PAILLARD, advanced studies manager at Hager Group, a 62-year-old German-based company providing solutions and services for electrical installations in residential, commercial, and industrial buildings.

With an extensive history of making electronics work seamlessly within buildings, the family-owned Hager Group has a unique perspective to modern today connectivity issues. Hager Group solves multi-protocol and inoperability issues regularly for its global client base, and recently released a new smart home platform for building automation. Jean-Noel shared his insight on why the company developed the new platform, and explained some of the current challenges associated with connectivity standards.

 

Tell me about the importance of multiprotocol connectivity and why it’s important to your customer base.

New applications and devices are coming out so quickly, making interoperability a key challenge in today’s technology landscape. There are numerous wireless protocols on the market, and each has its own connectivity strengths and weaknesses, depending on the application. So instead of building new connectivity protocols for each application, we use existing standards and figure out the best ones for each application. We work hard to find the right connections and build the bridge to create the right technology for each of our services and solutions.

 

Sometimes it seems as if the market sees existing wireless standards as a “standards battle” vs. everyone trying to work together. Do you think eventually one standard will emerge as the winner?

In my opinion, no connectivity protocol has emerged as the winner yet, and it’ll be an extremely long time before that happens - if it does at all. In the meantime, you have to be agile and willing to work with numerous technologies and standards. Hager Group has the right tools and technology on board to do this effectively, and it is one of the core values we provide to our customers.

 

Can you tell me about your new smart home platform and smart RF module? What was the impetus for creating the technology?

The first driver for us to create the platform was the size and growth potential of the smart home market in the future. We built the platform to ensure we could serve our customers as successfully as possible as IoT adoption in buildings continues to grow. Depending on the country or region we are serving, the technologies and standards vary greatly, creating inoperability and wireless challenges. By building a new platform, we could overcome this challenge and address all kinds of services and solutions, regardless of region. But in order to do this, we needed a platform that could handle multiple frequencies and protocols.

We built the platform with our OEM customers in mind, as they have specific requirements and really need a platform addressing a variety of protocols. In addition to being multi-protocol, we knew the platform had to be as small as possible, require low-power, and be able to address numerous applications.

 

Is that how Silicon Labs’ Wireless Gecko became involved - size and energy consumption were important?

Yes, exactly. The Gecko is tiny and great in terms of RF transmitting and receiving, plus the security and encryption elements on the SoC are ready to implement and best in class.

 

What was the technology evaluation process like?

We began the project in 2015 and we were originally looking at three companies, with Silicon Labs being one of them. We ended up rejecting one company early on based on its proposal specs, and the other two competing technologies were directly benchmarked on technical design and technical experimentation. We conducted a good amount of measurement and tests, and finally, after a 4-6-month process, we selected Silicon Labs as the best and the most evolutionary solution.

 

Tell me a little bit about the 2-year development process for the platform. What were your obstacles and/or surprises?

From a timing standpoint, we wanted to be aggressive, so we worked together with Silicon Labs in a tight partnership to build the optimum design together. We provided the right specification needs to enable your team to adapt the design for our requirements. Technically speaking, the big challenge on our side was understanding the capabilities of your platform because it’s a comprehensive platform. That’s why a solid partnership was so important in this design process - both of the teams at our companies reacted fast to changes and development hurdles and always figured out the right answer at the right moment. The multiprotocol management was difficult because each time we modified one protocol, we had to verify that the other protocol wasn’t affected. Therefore, we were constantly checking to make sure the protocols were not compromising the performance of the other protocol and/or platform.

 

I know it was just released in January, but what has response been like so far?

Yes, we have implemented the platform for the first time on the hager solution that was introduced in January , making residential distribution boards connected, serviceable and safe  : “Hello”.

Hager Group has been protecting homes and families for many years thanks to its reliable and safe electrical installations. As an innovative industrial company, we constantly extend beyond our technological foundations to face the growing demand for connected devices and smart solutions. An example of this is the breakthrough solution is  “hello” , A connected plug-in device for an existing electrical installation. It provides real-time alerts in case of electrical issues to guarantee peace of mind for end-users. Away for the weekend? Got some special wines in the fridge? Meat or specific dishes in the freezer?

hello ensures the power availability on important circuits/appliances and will let you know in case of any electrical issue. Your wine cellar can therefore stay at the right temperature. We are currently working on new implementations that will come on the market soon.

 

Where do you see IoT and connectivity heading over the next 5-10 years?

Two big current trends requiring a lot of IoT connectivity are robotics and artificial intelligence. These new technologies will change IoT from being an obedient system to a mindless system, where you don’t have to care about your system – it works on its own.  Today you still have to ask your system to do something, and I think tomorrow you won’t need to.

Moreover , I see IoT solutions, services, and applications being used more for mobility in the future, especially when we speak about transportation, such as electrical vehicles. The challenge will be to connect the electrical cars and the smart home together in a secured, efficient and eco-friendly way.

We want to be very clear: installed, previously paired Z-Wave devices are secure and not vulnerable to a downgrade attack. This represents practically all 100 million Z-Wave devices in homes today.

This type of attack would require physical proximity to the device during the pairing (inclusion) process. The pairing is done during initial installation or reinstallation. Pairing must be initiated by the homeowner (or installation professional), which means the homeowner is present at the time of the attempted attack. It would not be possible to execute an attack without the homeowner becoming aware that the link is running S0, as they would for any other S0 device added to the S2 controller.

We take what Pen Test Partners has reported very seriously and are taking steps to tighten the certification requirements regarding warnings presented to the user. We also believe any warning for a security step needs to be explicit. We are updating the specification to ensure that any user will not only get a warning during a downgrade to S0 but will have to acknowledge the warning and accept it to continue inclusion.

We believe it's important for all smart home devices to have the highest possible levels of security available, and our development team will continue to work with the security community to make improvements to the Z-Wave specification.

 

 

 

Introduction

In this post, The Case of the Cycle-to-Cycle Jitter Rule of Thumb, I will review a rule of thumb that can be used for estimating the RMS cycle-to-cycle jitter if all you have available is the RMS period jitter. The reason I’m doing so this month is that a couple of colleagues of mine recently asked me to reconcile a particular Timing Knowledge Base article versus one of our app notes . I first observed this rule of thumb in the lab and subsequently learned more about it.

 

What’s the Rule of Thumb?

It’s real simple. If the period jitter distribution is Gaussian or normal, then the cycle-to-cycle jitter can be estimated from the period jitter as follows:

Jcc (RMS) = sqrt(3) * Jper (RMS)

I first recorded this in a Timing Knowledge Base article Estimating RMS Cycle to Cycle Jitter from RMS Period Jitter. I wrote at the time the following statement:

The sqrt(3) factor arises from the definitions of period jitter and cycle-to-cycle jitter in terms of the timing jitter of each clock edge versus a reference clock.

I will spend a little bit more time on this thought today and attack the problem from several different angles.

 

What’s the Question?

In our application note, A Primer On Jitter, Jitter Measurement and Phase-Locked Loops, the figure below shows the following slopes for post-processing phase noise into timing jitter metrics. Period jitter and cycle-to-cycle jitter are shown as high pass filters with 20 dBc/dec and 40dB/dec slopes, respectively. This is correct and a useful illustration to keep in mind.

The question is how can RMS cycle-to-cycle jitter be larger than RMS period jitter, per the sqrt(3) rule, and the cycle-to-cycle jitter filter have a steeper slope? The answer is that it’s not just the slope that determines the end result. More on that later.

 

Some Terminology

Before proceeding, here are a couple of definitions adapted from AN279: Estimating Period Jitter from Phase Noise.

• Cycle-to-cycle jitter - The short-term variation in clock period between adjacent clock cycles. This jitter measure, abbreviated here as JCC, may be specified as either an RMS or peak-to-peak quantity.
• Period jitter - The short-term variation in clock period over all measured clock cycles, compared to the average clock period. This jitter measure, abbreviated here as JPER, may be specified as either an RMS or peak-to-peak quantity.

The distinction between these time domain jitter measurements is important, hence the italicized terms above. (By the way, you can find old examples in the academic and trade literature where these terms may mean different things, so always double-check the context). The terms here are as used presently and in standards such as JEDEC Standard No. 65B, “Definition of Skew Specifications for Standard Logic Devices”.

 

Example Lab Measurement

First, the following example lab measurement comes straight from the KB article. The annotated image has been made more compact for convenience.

There are three items called out on the screen capture.

1. The period distribution after 1 million cycles appears Gaussian and comes very close to meeting the 68-95-99.7 % rule for ±1, ±2, and ± 3 standard deviations respectively.
2. The measured RMS period jitter is the standard deviation of the period jitter distribution or about 1.17 ps.  We can therefore estimate the RMS cycle to cycle jitter as sqrt(3) * 1.17 ps or 2.03 ps.
3. The actual measured cycle to cycle jitter is 2.05 ps which is reasonably close to the estimate.

 

Example Excel Demonstration

You can also demonstrate this rule in Excel simulations. Exploring the effect, I generated a spreadsheet where I took an ideal clock edge and then jittered the edges by taking random samples from a Gaussian distribution. I then took the period measurements, and the cycle to cycle measurements, over five trials each for 30 edges, and 100 edges with the clock edges representing a jittery 100 MHz clock. Note that since the cycle-to-cycle jitter results are signed, i.e. positive or negative, we should expect the standard deviation of these quantities to be larger, all else being equal. The 100 edges trials were usually much closer to the sqrt(3) rule than the 30 edges trials but you could still see the general effect even over just 30 edges.

If you are interested in playing with it, the spreadsheet is attached as CCJ_ROT_Demonstrator.xlsx. 

 

An Explanation

So how does this rule of thumb arise? As mentioned previously, I first observed this in the lab years ago and learned I could count on it. Yet, I have seen little written about this. Eventually I ran across Statek Technical Note 35, An overview of oscillator jitter. The explanation below is a somewhat simplified and modified version of that derivation where the quantities are expected values for a “large” time series (recall my comments about 100 edges converging to the rule better than 30 edges.)

Let the variable below represent the variance of a single edge’s timing jitter, i.e. the difference in time of a jittery edge versus an ideal edge.

 

Every period measured then is the difference between 2 successive edge values, where each edge jitter has variance s2j. Period jitter is sometimes referred to as the first difference of the timing jitter. Since cycle-to-cycle jitter is the difference between adjacent periods it can be referred to as the second difference of the timing jitter.

If each edge’s jitter is independent then the variance of the period jitter can be written as

 

 

 

 

This is just what we would expect per the Variance Sum Law. You can see an example here, which states that for independent (uncorrelated) variables:

 

 

However, we can’t calculate cycle-cycle jitter quite as easily since in every cycle-to-cycle measurement we use one “interior” clock edge twice and therefore we must account for this. Instead we write:

 

 

 

Since each edge’s jitter is assumed to be independent and have the same statistical properties we can drop the cross correlation terms and write:

           

            

 

The ratio of the variances is therefore

 

 

 

This is an interesting and unexpected result, at least to me :)  

 

Post-Processing Phase Noise

AN279: Estimating Period Jitter from Phase Noise describes how one can estimate period jitter from phase noise based on applying a 4[sin(pi*f*tau)]^2 weighting factor to the phase noise integration. The weighting factor is predominately a +20 dB/dec high pass filter until reaching a peak at the half-carrier frequency.

It turns out that you can use a similar approach to calculating cycle-to-cycle jitter. This requires applying a {4[sin(pi*f*tau)]^2}^2 or 16[sin(pi*f*tau)]^4 weighting factor which is predominately a +40 dB/dec high pass filter until reaching a peak at the half-carrier frequency.  This is exactly what AN687 refers to.

So how can a sharper HPF skirt integrate such that cycle-to-cycle jitter is larger than the period jitter and the sqrt(3) rule applies?

I had to dig up my old Matlab program which I used when writing that app note. Fortunately, I still had the file and the original data. I then ran a modified version of the program and compared the results for max fOFFSET where the phase noise dataset is extended and truncated at both fc/2 and fc. The answer is that while the cycle-to-cycle HPF skirt is steeper the maximum is also higher. See the plots below. The blue wide trace is the period jitter weighted (filtered) phase noise and the red wide trace is the cycle-to-cycle jitter weighted phase noise.  It’s the larger far offset phase noise contributions that make the difference.

 

The original data was for a 160 MHz CMOS oscillator which had a scope measured period jitter at the time of about 2 ps. To be conservative, it was for that reason that I often ran the integration further out than fc/2. Scopes are lower noise now and it would be interesting to go find the original device under test and measure it on a better instrument. My main interest here is to see if the sqrt(3) relationship holds true. As you can see, the rule of thumb holds up in both cases.

Well I hope you have enjoyed this Timing 101 article. The sqrt (3) rule of thumb for cycle-to-cycle jitter holds up well in the lab, in Excel spreadsheet simulations, and when post-processing phase noise.

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

 

Below are the other Timing 101 articles:

Timing 101: The Case of the (Apparently) Jittery Jitter Attenuated Clock

Timing 101: The Case of the Ouroboros Clock

Timing 101: The Case of the Jitterier Divided-Down Clock

Timing 101: The Case of the Split Termination

Timing 101: The Case of the PLL’s VCO High Pass Transfer Function

Timing 101: The Case of the Spurious Phase Noise Part I

Timing 101: The Case of the Spurious Phase Noise Part II

Timing 101: The Case of the Discrepant Scope Measurements

Timing 101: The Case of the Half-terminated Differential Output Clock

 

 

 

 

Did you know you can sign up for our monthly newsletter tailored specifically for Silicon Labs community members? Here are top five reasons why you should subscribe:

Stay Informed on Hot Topics

First, you will get informed of the most popular forum discussions among peer engineers. We feature the most interesting topics within IoT, Internet Infrastructure, and Industrial Automation on a monthly basis.

Get the Latest Resources

Second, you can access the latest training resources about Silicon Labs products. You will receive information about the latest video tutorial, webinar, or knowledge base article once a month in your inbox.

Be Inspired

Third, you will be surprised to see how many inspiring projects and real-life applications were built by our members and customers. We introduce those cool examples featuring Silicon Labs’ part to you through our community newsletter.

Learn about the Newest Products

Fourth, you will stay on top of our latest hardware and software releases as well as new product launches.

Stay Connected

Fifth, the community is the place to share your knowledge and connect with each other. Through our featured member section in the newsletter, you will get to know our distinguished community members better.

 

 

The Silicon Labs Dynamic Multiprotocol allows you to support multiple wireless protocols on a single chip.

This technology time-slices the radio and rapidly changes configurations to enable different wireless protocols to operate reliably at the same time. 

The technology leverages Micrium OS Kernel to run each wireless stack as a separate RTOS task.

You are probably aware of the multiple benefits of SystemView; a tool to record and analyze the Micrium OS Kernel events in real-time.

To enable SystemView, Simplicity Studio offers this utility that inserts the required C files and configures the project include paths all by the press of a button. It sounds great, except that it is usually broken by constant changes in the different SDKs from Silicon Labs.

In this blog, I'm gonna describe how to add SystemView to your DMP project manually, for those situations in which fancy tools just won't work.

 

Inserting the SystemView Recorder Files to your DMP Project

Right-click over the project name to open the context menu and select the options New -> Folder

Click the button Advanced >>  select the option Link to alternate location (Linked Folder) and enter the following path:

STUDIO_SDK_LOC\util\third_party\segger\systemview

 

As shown in the image below:

 

 

Inserting the Include Paths in your Compiler Configuration

Right-click over the project name to open the context menu and select the option Properties.

Select the option C/C++ General > Paths and Symbols and add the following include paths to all Languages and Configurations: 

${StudioSdkPath}/util/third_party/segger/systemview/Config
${StudioSdkPath}/util/third_party/segger/systemview/SEGGER
${StudioSdkPath}/util/third_party/segger/systemview/Sample/MicriumOSKernel
${StudioSdkPath}/util/third_party/segger/systemview/Sample/MicriumOSKernel/Config

 

 

Resolving a couple of conflicts by excluding some C Files from compilation

Locate the file SEGGER_SYSVIEW_Config_MicriumOSKernel.c in the Project Explorer at dev-cfg > source

Right click over the file SEGGER_SYSVIEW_Config_MicriumOSKernel.c to open the context menu and select the option Properties.

Select the option C/C++ Build and exclude this file from compilation by selecting the checkbox Exclude resource from build.

Similarly, locate the file SEGGER_RTT.c in the Project Explorer at debug-basic-library > EFR32

Right click over the file SEGGER_RTT.c to open the context menu and select the option Properties.

Select the option C/C++ Build and exclude this file from compilation by selecting the checkbox Exclude resource from build.

 

 

Enabling the Trace Recorder

Open the file os_cfg.h located at the following path:

STUDIO_SDK_LOC\protocol\zigbee\app\framework\plugin-soc\micrium-rtos\config\os_cfg.h

 

Locate and set the macro OS_CFG_TRACE_EN to DEF_ENABLED

 

 

Finding the memory address of the RTT block

Re-compile your project and launch a Debug Session.

Click the button Probe located on the top toolbar of Simplicity Studio.

Once Probe is opened, type in the keyword _RTT in the Symbol Browser panel in Probe (at the bottom of the application) and make a note of the memory address as illustrated in the image below:

 

 

Starting a Recording

The SystemView host application is available from SEGGER.

Once you have the application installed on your computer, start SystemView.

Press F5 to start a recording.

Select the option Address for the RTT Control Block Detection and enter the address you found with Probe as shown below:

 

It may be that as the DMP SDK and/or Simplicity Studio evolve, the tool to insert SystemView automatically finally works. I will keep checking if that's the case and I will delete this blog if it's no longer relevant. In the meantime, I hope it will help someone.

 

Disclaimer: The views, thoughts, and opinions expressed in this blog belong solely to the author, and not necessarily to Silicon Labs.

 

We have yet to see the full-fledged economic value of billions of new IoT devices entering multiple industries, though we can prepare ourselves with what we know will come along with it. As with any new innovation and/or market, malicious adversaries and attackers will lurk and invade for their own piece of the pie.

Despite the looming security threats, companies and developers designing new IoT products often like to focus their attention on the application itself versus proper security. Security slows the time-to-market and is often viewed as inconvenient because it increases cost.

But no one wants to design an application that’s prone to hacking or data theft. Undesirable events like high-profile hacks can lead to serious brand damage and loss of customer trust, and worst-case is a slow down or permanent reduction in the adoption of IoT.

When it comes to security, IoT is no different than previous technology innovations such as PCs, smartphones, and the Internet itself. If security is not addressed sufficiently by the creators of the technology – in this case, IoT product designers - the oversight could have devastating effects on the entire market, and it will no doubt have negative consequences for the individual companies opting to design irresponsibly.

Varying Degrees of Security

To avoid these scenarios, designers need to change how they view IoT security. Unfortunately, it’s not as simple as a “to have or not to have” decision. Security is not binary. The reality is there are many different levels of security. A device can only be considered secure in the context of an attacker, when the level of security is higher than the capabilities of the attacker.

Moreover, the capabilities of the attacker are typically non-static, and therefore, the security level will change over time. The improved capabilities of the attacker can come about in several different ways, from the discovery and/or publication of issues and vulnerabilities to broader availability of equipment and tools.

History has taught us some valuable lessons about how fast security threats can change for an object. A typical lifetime of an IoT-device depends on the application, but in industrial applications, 20 years is a common timeframe. A device launched in 1998, for example, was once only vulnerable to nation-state attacks; today it must be able to withstand DPA attacks by hobbyists with $300 for tools, some spare time and lots of coffee. Predicting the future capabilities of a class of adversaries is very difficult if not impossible, especially over a 20-year timespan. How does the adversary look in 2040? One might speculate if it is even human?

Bootloader Benefits

The only reasonable way to counter future attack scenarios is for the security of the device to evolve with the increased capabilities of the adversary. This requires IoT security with upgradable software.

Of course, there is functionality requiring hardware primitives, which cannot be retrofitted via software updates. However, it is incredible what can be solved in software when the alternative is a truck-roll. Though, it impossible to predict and account for all future attacks.

Secure updates involve authenticating, integrity checking, and potentially encrypting the software for the device. The software handling such security updates is the bootloader, typically referred to as a secure bootloader. The secure bootloader itself, along with its corresponding cryptographic keys, constitutes the root-of-trust in the system and needs to have the highest level of security. A secure bootloader is functionality IoT vendors should expect to get from the IC manufacturers.

The authentication and integrity check should be implemented using asymmetric cryptography, with only public keys in the device. This way, it is not necessary to protect the signature-checking key in the devices. Since protecting keys in deployed devices is (or at least should be) harder than protecting keys in control of the device owner, it is also acceptable to use the same bootloader keys for many devices.

Encrypting the Software

Encrypting the software running on the IoT device has two benefits. First, it protects what vendors consider to be intellectual property (IP) from both competitors and counterfeiting. Secondly, encryption makes it more difficult for adversaries to analyze the software for vulnerabilities. Encrypting the new software for secure boot does; however, involve secret keys in the device, and protecting secret keys inside a device in the field is becoming increasingly harder. At the same time, newer devices have increased resistance to DPA attacks. Furthermore, a common countermeasure against DPA attacks is limiting the number of cryptographic operations that can take place to make it infeasible to get sufficient data to leak the key. Even though protecting the key is difficult and motivated adversaries will likely extract it, key protection makes attacking more difficult for the attacker.

Another consequence of secure updates is the likely future need for more memory in the IoT device. This is a complicated trade-off for several reasons. First, software tends to expand to the memory available in the device. So, a larger memory device requires discipline from the software team to leave room for future updates. The other complication is the value of free memory in the future versus the device’s initial cost. More memory tends to increase the cost of the device. This cost must be justified both from the device maker and the consumer point of view.

Finally, it is important to have a plan for distributing the security updates. For most devices, these updates use the device’s existing Internet connection. But in some cases, this requires adding or using physical interfaces such as USB drives (i.e., sneakernet). It is also important to consider that the devices might be behind firewalls or in some cases disconnected from the Internet.

IoT device software is often fully owned and managed by the device maker, meaning the device maker should have proven processes in place to internally protect the signing keys and particularly those who can issue updates.

Securing the Future

There is no such as thing as a 100 percent secure-proof device, especially during the entire duration of a product’s lifecycle.

Yet it is possible to understand and prepare for the most likely threats and safeguard for future threats by designing in the ability for upgradable software updates. IoT developers must adopt themselves to this critical mindset of responsible security design. Otherwise, they are placing their innovations, and IoT’s market potential, into the hands of adversaries.

For more on upgradeable security, Silicon Labs’ senior director of product security Lars Lydersen hosted a webinar in which he provided the insight and background to help in evaluating what security functionality is necessary in an IoT design.