In English, we often use the expression “comparing apples to apples” to mean we are making a fair comparison between similar things. On the other hand, if we are “comparing apples to oranges” then we mean the opposite.

Sometimes, despite our best efforts, our lab measurements may yield an instance of “apples to bruised apples”. In this month’s post, I will provide a relatively common example in The Case of the Discrepant Scope Measurements.  

The original case

Years ago, I was supporting an oscillator customer and we were having correlation issues, i.e. his measurements versus mine. His period jitter measurements were just not making any sense compared to the spec and to the part’s typical performance.

I knew enough to make sure that we had similar boards, cables, terminations, test equipment, and were at least attempting the same measurements. We even had very similar oscilloscopes. I was starting to wonder if there really could be something amiss with his device when I asked him to send me a scope shot of his waveform. Bingo! His waveform was a fraction of the size of mine and I knew that was most likely the source of the discrepancy.

Example Lab Measurements

To illustrate the issue I took a nominal 2.5V LVDS 100 MHz output clock and measured it with a good quality 1 GHz DSO or Digital Storage Oscilloscope that supports measurements statistics (the higher bandwidth scopes were all tied up and 1 GHz is sufficient here.) I took each measurement a little over 10K times, varying only the vertical scale, and tabulated the key results below. Note that I record the measurements below in decreasing vertical scale. The smaller the vertical scale, the larger the displayed waveform.

The most notable observation is that the standard deviation of all of the measurements decreased with vertical scale. The smaller the vertical scale, and the larger the displayed waveform, the more accurate the measurements.

One Man’s Noise is Another Man’s Signal …

I am particularly interested in the period jitter, which is the standard deviation of the period measurements. If we plot period jitter versus vertical scale from the table values we obtain the following linear plot.

The measured period jitter versus the scales sampled appears linear. Further, there was no deflection at the smaller values suggesting we were not approaching a measurement “floor”.

Before discussing why the measurements turned out the way they did, let us briefly review the screen caps for each scale selection and why we might use them.

The 250 mV/div selection

This is the smallest displayed waveform selection of the three instances. You run in to this type of scaling when attempting to measure several waveforms simultaneously, for example when comparing relative clock skew. The standard deviation of the period measurements, i.e. the period jitter, was 7.5 ps.

The 100 mV/div selection

This is the most common selection as it is the default or auto scale selection for this particular scope when measuring a single waveform. The period jitter dropped by more than half to 3.2 ps. Great for browsing but as it turns out, still not optimum.

The 55 mV/div selection

This final selection maximizes the displayed waveform on the scope without clipping. The period jitter dropped to about 2 ps.

An Explanation

I purposely did not make any sampling or time scale changes in these measurements in order to eliminate that aspect as a variable. The only change is in vertical scaling which impacts voltage noise. Voltage noise translates to timing noise via slew rate, i.e. the ratio of delta voltage over delta time, as illustrated in the exaggerated figure below. The blue Gaussian curves are intended to suggest normal noise distributions about the decision threshold.

 

The DSO is a digital scope with a sampling ADC in the front end of the signal chain. The voltage noise will therefore be due to the DUT and the DSO’s ADC quantization noise. This particular scope’s ADC is nominally 8 bits. (The actual ENOB or Effective Number Of Bits may be lower but the principle is the same.)

An 8-bit ADC has 256 unique codes or quantization levels. Therefore, we can compare the nominal quantization levels as follows. There is a significant reduction in quantization noise as we decrease vertical scaling.

The ADC’s 8 bits are employed across the entire vertical display of the oscilloscope so anything less will use fewer bits and result in more quantization noise. This in turn yields more timing uncertainty. It is for this reason that oscilloscope manufacturers often recommend that users maximize the waveform on the screen for most accurate measurements. Doing so without clipping the waveform is the most conservative approach but check with your particular scope vendor.

Conclusion

I hope you have enjoyed this Timing 101 article. Comparing digital scope measurements, which don’t have similar vertical resolution, can result in comparing “apples to bruised apples”.

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

 

Randy Ferguson joined the Silicon Labs IT team in November 2015 as a desktop support analyst. In his current role as IT service delivery manager, Randy is able to engage with members in all departments, because he and his team are often the first point of contact for company-wide IT support. His responsibilities range from maintaining equipment and infrastructure for day-to-day internal operations, to providing web platform updates affecting external customers. Because of this, Randy said his team has a “unique point of view on the operations of the whole company.” He continued, “we all know that every department is integral to the overall success of Silicon Labs, but working in IT, you really experience it first-hand."

 

 

Working in IT also gives Randy the opportunity to see the value of a strong team culture. “Every member of the team is treated like an equal contributor to what we do,” he said. “I’ve always felt that I have the freedom to tackle any task I'm confronted with in the way that suites me best. Being able to trust and rely on your peers’ and leaders’ strengths and cover each other’s weaknesses is something that's hard to come by in my experience.”

 

“If you haven't met us in person, you might be surprised to find out just how sociable and likeable we can be! That said, we do fly our nerd flags high and proud.” He continued, “We do have a pretty rockin' team in IT, if I say so myself.”

 

We’re glad to have a rockin’ guy like you on the team, Randy Ferguson. Fly your nerd flag high and keep up the great work!

 

This week, we’ve introduced a Wireless Gecko software solution created to simplify industrial and commercial IoT applications using sub-GHz wireless connections by adding Bluetooth connectivity. The new hardware and software solution enables simultaneous sub-GHz and 2.4 GHz Bluetooth low energy connectivity for commercial and industrial IoT applications, such as smart metering, home and building automation, and commercial lighting.

This is important for the industrial and commercial sectors for several reasons – for one, it’ll make it much easier for people working in these environments to set-up, control, and monitor sub-GHz IoT devices using Bluetooth low energy mobile apps.

Sub-GHz wireless protocols are used extensively in industrial and commercial settings because many of them require a combination of energy efficiency, long battery life, and extended range for remote sensor nodes. Proprietary sub-GHz protocols allow developers to optimize their wireless solution to their specific needs instead of conforming to a standard that might put additional constraints on network implementation. With our new software solution, sub-GHz protocols can still be utilized for their benefits, but users can also easily manage the system using Bluetooth mobile apps on a variety of devices, such as tablets or smart phones.

Sub-GHz environments are typically low-data-rate systems, such as simple point-to-point connections to large mesh networks and low-power wide area networks (LPWAN). By adding Bluetooth with low energy connectivity to wireless networks in the sub-GHz band, developers can deliver new capabilities such as faster over-the-air (OTA) updates and deploy scalable, location-based service infrastructure with Bluetooth beacons.

 

Single Chip Reduces Cost by 40 Percent

IoT developers stand to gain tremendous development benefits by avoiding the complexity of two-chip wireless architectures. By using a single chip with both sub-GHz and BLE connectivity, developers can simplify hardware and software development, which can speed time-to-market and reduce bill-of-materials (BOM) cost and size by up to 40 percent.

Accenture estimates industrial IoT could add $14.2 trillion to the global economy by 2030, making the deployment potential of this solution especially massive. Any new technology developments such as this one that helps developers control and monitor industrial and commercial devices and data more easily leads to efficiency and economic gains for both businesses and the users.

Mobile control applications are often a crucial piece of industrial and commercial automation, giving system operators a quick and easy way to control equipment. For instance, commercial lighting depends heavily on mobile devices, which control lighting on/off schedules, energy efficient modes and rules, and dimming based on occupancy using ambient light sensors. Often times, the mobile app may be the only control interface installers, designers and site managers have for project commissioning and configuration.

Bluetooth connectivity allows the device apps and interface to be simple, which can make a difference in user adoption, as many lighting and commercial controls can be complex and difficult to manage.

Our new solution will clearly yield impressive benefits for both developers and the users of the industrial applications. Fortunately, the new multiprotocol software is now available using Silicon Labs’ EFR32MG and EFR32BG Wireless Gecko SoCs. Check out more details here if you’re working on a product that could benefit from the solution.

 

This blog should serve as a guide to adding Micrium OS on a Flex Gecko and get at least one task running on the device.

I will now share with you my experience while going through this exercise.

Getting Started

I decided to perform a clean installation of Simplicity Studio in order to avoid conflicts inflicted by software updates over time. After installing the tool, before even attempting to add anything, I first had to make sure that I had the necessary SDKs. Here's what I installed:

• 32-bit MCU SDK - 5.5.0.0
• Micrium OS - 5.4.0
• Flex SDK - 2.3.0.0

I then mounted a Flex Gecko, EFR32FG12 in my case, onto a Wireless Started Kit Mainboard (BRD4001A). After that, I connected it to the PC using the provided USB cable.

Simplicity Studio recognized a Flex Gecko connected to a WSTK and displayed the link to examples from the Flex SDK (see Figure 1).

 

Loading a Basic Flex SDK Example

As a starting point, I decided to go with the "RAIL: Simple RAIL without HAL" example from the Flex SDK.

You can find this by expanding the list of projects under the "Silicon Labs Flex SDK Examples" link:

 

Then find and click the example shown in Figure 3 to add it to your workspace:

 

After the example loads on your workspace, you might get a notice as shown in Figure 4. Just click "OK".

 

You will then be presented with simple_rail_without_hal.isc opened where you can configure RAIL. In my case, I left everything in its default values and simply clicked on "Generate" as shown in Figure 5.

 

At this point, you should now be set with a basic Flex Gecko example that builds and runs. However, I did find that the default project settings have compiler optimization set to "Optimize for size (-Os)" which will eventually make debugging the project rather difficult. Therefore, I switched optimizations to "None (-O0)".

 

Adding Micrium OS to the Workspace

Now that you have a basic Flex Gecko example that builds and runs, let's go ahead and start adding the Micrium OS source files into the workspace.

First, locate the Micrium OS directory, it should be in:

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.3\platform\micrium_os

 

Now drag and drop the "micrium_os" folder into your project (simple_rail_without_hal) in Simplicity Studio. When doing this, make sure that you have "Copy files and folders" selected before clicking "OK" as shown in Figure 7.

 

You will then have to remove all the unnecessary files that get added with Micrium OS (this was tedious).

Here's how your "micrium_os" folder should end up looking:

 

Finally, the compiler needs to know where to look for the header files so we have to add two compiler include paths to the project settings:

"${workspace_loc:/${ProjName}/micrium_os}"
"${workspace_loc:/${ProjName}/micrium_os/cfg}"

 

Configuring Micrium OS

Now that you have Micrium OS as part of your project, let's go ahead and make some minor adjustments to the default Micrium OS configuration.

1. Open rtos_description.h located in your project under "micrium_os/cfg/"
2. Replace the contents of the file with one below:

/*
*********************************************************************************************************
*                                             EXAMPLE CODE
*********************************************************************************************************
* Licensing:
*   The licensor of this EXAMPLE CODE is Silicon Laboratories Inc.
*
*   Silicon Laboratories Inc. grants you a personal, worldwide, royalty-free, fully paid-up license to
*   use, copy, modify and distribute the EXAMPLE CODE software, or portions thereof, in any of your
*   products.
*
*   Your use of this EXAMPLE CODE is at your own risk. This EXAMPLE CODE does not come with any
*   warranties, and the licensor disclaims all implied warranties concerning performance, accuracy,
*   non-infringement, merchantability and fitness for your application.
*
*   The EXAMPLE CODE is provided "AS IS" and does not come with any support.
*
*   You can find user manuals, API references, release notes and more at: https://doc.micrium.com
*
*   You can contact us at: https://www.micrium.com
*********************************************************************************************************
*/

/*
*********************************************************************************************************
*
*                                           RTOS DESCRIPTION
*
*                                      CONFIGURATION TEMPLATE FILE
*
* File : rtos_description.h
*********************************************************************************************************
*/

/*
*********************************************************************************************************
*********************************************************************************************************
*                                               MODULE
*********************************************************************************************************
*********************************************************************************************************
*/

#ifndef  _RTOS_DESCRIPTION_H_
#define  _RTOS_DESCRIPTION_H_


/*
*********************************************************************************************************
*********************************************************************************************************
*                                             INCLUDE FILES
*********************************************************************************************************
*********************************************************************************************************
*/

#include  <common/include/rtos_opt_def.h>


/*
*********************************************************************************************************
*********************************************************************************************************
*                                       ENVIRONMENT DESCRIPTION
*********************************************************************************************************
*********************************************************************************************************
*/

#define  RTOS_CPU_SEL                                       RTOS_CPU_SEL_ARM_V7_M

#define  RTOS_TOOLCHAIN_SEL                                 RTOS_TOOLCHAIN_GNU

#define  RTOS_INT_CONTROLLER_SEL                            RTOS_INT_CONTROLLER_ARMV7_M


/*
*********************************************************************************************************
*********************************************************************************************************
*                                       RTOS MODULES DESCRIPTION
*********************************************************************************************************
*********************************************************************************************************
*/

                                                                /* ---------------------- KERNEL ---------------------- */
#define  RTOS_MODULE_KERNEL_AVAIL


/*
*********************************************************************************************************
*********************************************************************************************************
*                                             MODULE END
*********************************************************************************************************
*********************************************************************************************************
*/

#endif                                                          /* End of rtos_description.h module include.            */

 

Modifying main.c

We'll be making modifications to the default main.c generated by the "RAIL: Simple RAIL without HAL" example.

Micrium OS requires the following include paths in main.c so go ahead and add them as shown below:

#include  <cpu/include/cpu.h>
#include  <kernel/include/os.h>
#include  <common/include/common.h>
#include  <common/include/rtos_utils.h>
#include  <common/source/kal/kal_priv.h>  /* Private file, use should be limited */

 

We'll be modifying main.c to initialize Micrium OS and create a start task. For that, you'll need to specify a task stack size and a priority. We typically do this by defining them as constants and passing those in the call to OSTaskCreate().

The start task also requires its own Stack and Task Control Block (OS_TCB) as well as its function prototype. Therefore, add the following to main.c:

#define  START_TASK_PRIO              21u
#define  START_TASK_STK_SIZE         512u
                                                                
static  CPU_STK  StartTaskStk[START_TASK_STK_SIZE];  /* Start Task Stack. */
static  OS_TCB   StartTaskTCB;                       /* Start Task TCB.   */

static  void  StartTask (void  *p_arg);

 

Here's the body of the StartTask function where the kernel tick gets initialize and as well as the Common module. Note that the function includes an infinite loop at the end with a time delay of 1 second. This is done to yield CPU time to other tasks that are or will eventually run on your system. You can copy and paste the following in your main.c:

static  void  StartTask (void  *p_arg)
{
  RTOS_ERR    err;
  CPU_INT32U  cpu_freq;
  CPU_INT32U  cnts;

  /* Prevent compiler warning. */
  PP_UNUSED_PARAM(p_arg);                                     

  /* Determine SysTick reference freq. */
  cpu_freq =  SystemCoreClockGet();
  /* Cal. SysTick counts between two OS tick interrupts. */
  cnts     = (cpu_freq / (CPU_INT32U)KAL_TickRateGet());

  /* Init uC/OS periodic time src (SysTick). */
  OS_CPU_SysTickInit(cnts);

#if (OS_CFG_STAT_TASK_EN == DEF_ENABLED)
  /* Initialize CPU Usage. */
  OSStatTaskCPUUsageInit(&err);
  /* Check error code. */
  APP_RTOS_ASSERT_DBG((RTOS_ERR_CODE_GET(err) == RTOS_ERR_NONE), ;);
#endif

#ifdef CPU_CFG_INT_DIS_MEAS_EN
  /* Initialize interrupts disabled measurement. */
  CPU_IntDisMeasMaxCurReset();
#endif

  /* Call common module initialization example. */
  Common_Init(&err);
  APP_RTOS_ASSERT_CRITICAL(err.Code == RTOS_ERR_NONE, ;);

  while (DEF_ON) {
	  /* Delay Start Task execution for 1000 OS Ticks from now. */
      OSTimeDly(1000, OS_OPT_TIME_DLY, &err);
      /* Check error code. */
      APP_RTOS_ASSERT_DBG((RTOS_ERR_CODE_GET(err) == RTOS_ERR_NONE), ;);
  }
}

 

Finally, let's modify main() to initialize the CPU, re-assign interrupt handlers as kernel-aware, initialize the kernel, create the Start Task, and start the OS. Here's how main() should end up looking:

int main(void)
{
  uint32_t vtorAddress = SCB->VTOR;
  CPU_FNCT_VOID * vtor = (CPU_FNCT_VOID *)vtorAddress;
  RTOS_ERR  err;

  CPU_Init();

  /* Re-assign previous interrupt handlers as kernel-aware */
  for (uint32_t i = CPU_INT_EXT0; i < CPU_INT_EXT0 + EXT_IRQ_COUNT; i++) {
    CPU_IntSrcHandlerSetKA(i, vtor[i]);
  }

  /* Initialize the Kernel. */
  OSInit(&err);
  /* Check error code. */
  APP_RTOS_ASSERT_DBG((RTOS_ERR_CODE_GET(err) == RTOS_ERR_NONE), 1);

  /* Create the Start Task. */
  OSTaskCreate(&StartTaskTCB,
               "Start Task",
                StartTask,
                DEF_NULL,
                START_TASK_PRIO,
               &StartTaskStk[0],
               (START_TASK_STK_SIZE / 10u),
                START_TASK_STK_SIZE,
                0u,
                0u,
                DEF_NULL,
               (OS_OPT_TASK_STK_CLR),
               &err);
  /* Check error code. */
  APP_RTOS_ASSERT_DBG((RTOS_ERR_CODE_GET(err) == RTOS_ERR_NONE), 1);

  /* Start the kernel. */
  OSStart(&err);
  /* Check error code. */
  APP_RTOS_ASSERT_DBG((RTOS_ERR_CODE_GET(err) == RTOS_ERR_NONE), 1);

  return (1);
}

 

You are now set to build and run the project. You can put a breakpoint on the Start Task inside the while loop and notice that you'll be hitting that every second (or as specified by the delay you configure in OSTimeDly()).

Please do understand that this is a very basic guide that resembles more a hack rather than an official solution from Silicon Labs. Hopefully, Micrium OS can be part of the Flex SDK in the future, but in the meantime, this is a start.

I hope this was useful to you. Feel free to post any comments or questions regarding this blog post.

Title: Develop Secure, Interoperable Smart Home Devices with Z-Wave

Date: July 11 & 12, 2018

Duration: 1 hour

Speaker: Johan Pedersen, Product Marketing Manager of Z-Wave

Topic:  Z-Wave is a popular wireless technology for smart home applications with a large ecosystem of interoperable devices, such as smart lighting, energy monitoring, and home security systems. Consumers benefit from Z-Wave’s ease of use and secure interoperability thanks to mandatory product certification and features including SmartStart plug-and-play installation, Security 2 (S2), and backwards compatibility. Adding Z-Wave connectivity to your product is straightforward due to clearly defined software stacks, published device profiles, pre-certified modules, a finished product certification program and development tools that ensure high-quality products get to market fast.

In this webinar, we explore how Z-Wave wireless technology enables easy-to-use, secure, and interoperable products for the smart home market.

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

 

 

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.