You need to test, we're here to help.

You need to test, we're here to help.

19 July 2021

How to Test Noisy Power Supply Outputs

Figure 1: 3.3 V output of a DC-DC converter.
The waveform shows the nominal DC level,
ripple and high frequency noise bursts.
Did you ever acquire the output of a power supply with your oscilloscope and find an unexpectedly high level of noise? Did you try adding filter capacitors only to find the noise level was not changed? 

In this post, we'll discuss how the choice of probe affects the noise present in power measurements, as well as how oscilloscope settings such as termination impedance, bandwidth and coupling can be adjusted to lessen noise and improve measurement results.

Figure 1 shows a typical DC-DC converter output measurement. The mean value of the waveform is 3.294 V.  Ripple appears at the switching frequency of 1.2 MHz, and noise in the form of high frequency bursts and baseline thickening is visible throughout.

Waveforms like this can be acquired with a 10:1 high impedance probe, a 1:1 coaxial cable connection, or a 1.2:1 rail probe using either DC or AC coupling, as available.  Figure 2 summarizes how each oscilloscope/probe configuration affects the measurement.

12 July 2021

MAUI Studio Pro: Generating Waveforms

Figure 1: MAUI Studio Pro lets you generate
multiple waveform types from equation.
MAUI® Studio includes a simple waveform generator that enables you to create any of six standard waveforms or a DC current simply by enter a few waveform properties, such as frequency and amplitude. The waveforms are continuously generated and act like a live, repetitive waveform acquisition for simulation exercises. 

MAUI Studio Pro adds to that a true, arbitrary function generator. Numerous different waveform types can be generated from equation, and custom jitter/noise characteristics can be added to any generated waveform. 

06 July 2021

MAUI Studio Pro: Analyzing Anyone's Waveform Data

Figure 1: A waveform file (.bin) saved on a Keysight 
oscilloscope undergoes multiple math and measure
 operations in MAUI Studio.
 Another key feature of MAUI® Studio and MAUI Studio Pro is the ability to recall waveform files saved on other vendors' oscilloscopes, as well as on Teledyne LeCroy oscilloscopes. The software supports files saved on Tektronix (.wfm), Keysight (.bin), Rohde & Schwarz (.bin) and Yokogawa (.wvf) instruments. It even lets you filter for these types when browsing for files. And with some simple editing, "time and data with header" format  Excel (.csv) files can also be recalled into MAUI Studio, extending its analysis capabilities to waveforms acquired from nearly any type of instrument or sensor.

28 June 2021

MAUI Studio Pro: "Impersonating" Remote Oscilloscopes

Figure 1: After recalling the LabNotebook, MAUI Studio Pro
 (now simulating an HDO4024A) will "impersonate" the
WaveRunner 9404 on which the file was saved.
Our recent release of MAUI Studio Pro adds several key new features to the MAUI Studio remote oscilloscope software for Windows 10 PCs. This short series will demonstrate how to make use of these features.

One of the most useful new features is the ability to inherit the entire "personality" of an oscilloscope. By that, we mean the MAUI Studio Pro software replicates the oscilloscope model type and user interface, along with its full complement of software options. It "impersonates" the oscilloscope. There are a couple ways this can be done.

21 June 2021

Automotive Ethernet MDI S-parameter Testing

Figure 1: MDI S-parameter tests treat the Base-T1
pair as a balance transmission line and check that
reflections don't cause either excessive power loss
or mode conversion that can disrupt the signal.
As said earlier, the automotive industry has very stringent EMC/EMI requirements, and all Automotive Ethernet standards are designed to ensure good operation even in the presence of high EMI. Not only is there the potential for interference from all the different electronic systems within the vehicle, nothing is stopping you from parking your vehicle below high-voltage transmission wires or in other high EMI fields. 

For this reason, all Automotive Ethernet standards have defined S-parameter tests to be performed at the Medium Dependent Interface (MDI). The assumption is that the single twisted pair that is the basis for all Base-T1 transmissions can be treated as a balanced, differential transmission line with some crosstalk. It is a very real-world application of S-parameters, which can seem so academic.

Two, mixed-mode S-parameters are measured at the MDI reference plane. The tests ensure that there is neither too much loss of power from reflections, nor too much mode conversion into differential signal, that it will disrupt the information of the PAM3 encoded signal.

14 June 2021

Real-World Workload Replays on SSDs

The Problem

SSDs are expected to hit the market after undergoing rigorous sessions of testing and quality assurance. From a functional testing perspective, synthetic IO workloads have been the de facto method of testing. While synthetic workload testing is essential, it doesn’t exactly reflect the real-world environment, whether that is inside a data center or a client’s laptop. Real life workloads tend to be a lot more “bursty”, and it’s during these short bursts that SSDs run into long queues and high latency, ultimately degrading the quality of service.

In this blog post, we explore techniques to replay these real-world workloads and examine their results.


Overview of Real-World Workloads

First and foremost, what is a real world workload and how do I get it? Fig. 1 shows the typical process of how a real life workload is captured.


Fig. 1. Capturing a real-world storage workload.

Fig. 1. Capturing a real-world storage workload.

Applications typically run on top of a file system that in turn push IOs to an abstracted OS storage layer before making it to the SSD. For Linux, this storage layer is the block layer, and for Windows, it can be either the DiskIO layer or the StorPort layer. IO capture tools are readily available to snoop all IOs within the storage layer. The most popular one for Linux is blktrace, and for Windows, Windows Performance Recorder is widely used capture tool. Alternatively, Workload Intelligence DataAgent (coming soon) is a powerful trace capture tool with built in intelligence to trigger and filter on user determined criteria. The outputs of these capture tools are trace files that contain all the IOs along with their timestamps and typically other information, like process IDs, CPU etc. It is these trace files that are used to generate IO replays from for offline testing.

Where can you get these IO trace files? If you work with a customer that uses your SSDs or storage subsystems, they typically collect such trace files for their own analysis purposes and may be open to sharing them. This would be the best scenario as you can get a live view of a real-world environment. If you are the SSD user, you can use the aforementioned capture tools to trace the IOs in your application environment.

Alternatively, SNIA provides a number of open-source real-life storage workloads: Finally, you can always concoct your own setup- run a MySql or Cassandra database, simulate some application queries, and capture storage layer IOs. While strictly not “real-world”, this will at least give you a good sense on how application activities trickle down to storage IOs.


Replaying Workloads

With the workload traces on hand, it’s time to replay them in your test environment. The goal of doing so is to reproduce the issue that was caught during the production run, and also to tune or make fixes to SSD firmware to see if the issue gets resolved. If one is evaluating SSDs, this is a great way to see if the selected SSDs pass the workload criteria.

The recommended storage replay tool is the Workload Intelligence Replay. Replay files can be generated from Workload Intelligence Analytics, to run on an Oakgate SVF Pro appliance. The replay results can then be ported back to Workload Intelligence Analytics to compare with the original trace, or with other replay results. Fig. 2. shows the flow of how storage traces are captured, replayed, and compared.

Fig. 2. Process of replaying and analyzing a storage trace.

Fig. 2. Process of replaying and analyzing a storage trace.

When replaying a storage workload to target drive, a number of factors must be considered to make sure the replay emulates the production environment as much as possible:

  1. Target drive selection – Ideally, the DUT should have the same make and model as the drive that the production trace was captured on. If this is not possible and the target DUT has a different capacity, the replay software should be able to re-map LBAs so that they fit within the DUT. Oakgate SVF Pro Replay handles this situation by offering different LBA out of range policies, including skipping the IOs, wrapping the IOs, and linearly re-mapping IOs that exceed the LBA range. We’ve found re-mapping LBAs to be the most effective in duplicating production scenarios. 
  2. Target drive prefill – It is essential the DUT gets prefilled properly to emulate the state the production drive was in before the capture happened. While it’s impossible to condition the DUT to the exact state the production drive was in, we’ve found that a simple 1x write prefill was able to duplicate production drive scenarios. Alternatively, Fiosynth offers fairly sophisticated preconditioning techniques that are reflective of data center workloads.
  3. Accurate IO timing and parameters – The heart of an effective replay is software that can emulate when and what the production host sent to the device. To achieve that goal, Oakgate SVF Pro matches the replay trace file IO in terms of relative timestamp, IO size, and LBA. Fig. 3 and 4 show the LBA vs. Time and IO Size vs. Time, respectively, of a production blktrace versus that replayed by Oakgate SVF. As can be seen, the timings and values of the replayed IOs is exactly same as the production trace. The variable of interest is typically the latency of each IO and the IO queue depth and are expected to be different from the production trace.

 Fig. 3. LBA vs time of production blktrace (blue) and the replayed trace (orange)

Fig. 3. LBA vs time of production blktrace (blue) and the replayed trace (orange) #2

Fig. 3. LBA vs time of production blktrace (blue) and the replayed trace (orange)

Fig. 4. IO Size vs time of production blktrace (blue) and the replayed trace (orange)

Fig. 4. IO Size vs time of production blktrace (blue) and the replayed trace (orange) #2

 Fig. 4. IO Size vs time of production blktrace (blue) and the replayed trace (orange)

Replay Experiments

Now that we’ve been primed about the intricacies of workload replay, let’s take a look at some experiments.

In all experiments run, we’ve preconditioned the drive 1x. The chosen drives were standardized to 0.5 TB. All production runs were captured when the drive was formatted to 512 bytes, so for the replay, we’ve also formatted the drive to 512 bytes.


Replay Repeatability

In the first set of experiments, we tackle the question of how repeatable a workload replay is. This question is important because we need to know whether the replay software can duplicate the same profile on the same drive during a production run. Even if we can duplicate the profile, it is also crucial to know whether this same profile can be regenerated after 10s or 100s of replays. If the drive shows a statistically different profile on every replay run, it can indicate that the drive does not have very stable performance.

For this experiment, the production workload we are running consists of a combination of applications, primarily: Postgresql with light traffic, and Spark + HDFS data store with large datasets that get cached and persisted onto disk. We captured a blktrace on the production machine.


Fig. 5 shows the latency vs time of the production blktrace over a 10 minute snapshot.

 Fig. 5. Latency vs time for a production blktrace with a big data workload

Fig. 5. Latency vs time for a production blktrace with a big data workload

Since we control the “production” environment, we’ve taken this same drive over to an Oakgate replay appliance and ran a replay file generated from Fig. 4’s workload. We iterated multiple rounds of replay (preconditioning between each iteration) and took those results and fed it back into WI Analytics for comparison. Fig. 6 shows 3 iterations of the replay.

Fig. 6. Latency vs time for three rounds of replay

Fig. 6. Latency vs time for three rounds of replay #2

Fig. 6. Latency vs time for three rounds of replay #3

Fig. 6. Latency vs time for three rounds of replay

In a quick glance, we can see that the latency spikes and their timings for the replayed results are extremely similar to the original production trace. There are some statistical differences, if we closely, which is expected. Overall, the replays have faithfully regenerated the latency profile in an offline environment, and this particular drive has shown stable results after multiple rounds of replay.


Replay Comparison for Different SSDs

Next, let’s run experiments on how different SSDs react to the same workload. Such a use case can very well be used to qualify different drives for a data center’s set of workloads. From a different angle, the same experiment can be run on the same SSD with different firmware to see if firmware changes are effective against a particular set of workloads.

In these experiments, we had chosen an actual data center workload that showed a particularly stressful profile. Fig. 7 shows the read latency vs. time of the production workload. We can see very big latency spikes happen, and we would like to know whether other SSDs can handle this same workload without these latency spikes. Fig. 8 shows the main obstacle the workload entails – a burst of large discard (trim) IOs that is likely causing the disk to become blocked while servicing those discards, contributing the high read latency spikes.


Fig. 7. Data center production blktrace.

Fig. 7. Data center production blktrace.


Fig. 8. Discard (trim) IO sizes vs time for production blktrace.

Fig. 8. Discard (trim) IO sizes vs time for production blktrace.


Fig. 9 shows drives from various vendors that did not encounter the read latency spikes despite undergoing the same production workload. Latency scales are normalized to that of the production workload the contrast the latency differences.

Fig. 9. Workload replayed against drives that did not show latency spikes.
Fig. 9. Workload replayed against drives that did not show latency spikes. #2

Fig. 9. Workload replayed against drives that did not show latency spikes. #3

Fig. 9. Workload replayed against drives that did not show latency spikes. #4

Fig. 9. Workload replayed against drives that did not show latency spikes.

By contrast, Fig. 10 shows the set of drives that show an adverse reaction to the burst of discard IOs. Vendor F in particular never recovered to its baseline latencies after getting swamped with the discard bursts.


Fig. 10. Drives that reacted adversely to the replayed production workload.

Fig. 10. Drives that reacted adversely to the replayed production workload. #2

Fig. 10. Drives that reacted adversely to the replayed production workload.


The ability to replay production storage workloads is an essential tool to improving or qualifying SSD real-world performance. Unlike synthetic workloads, production workloads are much more unpredictable, dynamic, and reflective of real application environments. In this blog, we discuss the various aspects of accurately replaying workloads in an offline environment and showed examples on how to properly reproduce production environments. We also showed how different SSDs can react very differently to the same production workload. Hopefully, we’ve conveyed the point that it is essential to use real-world replays to design better SSDs and better match sets of SSDs relevant to one’s real-world environment.

By Fred Tzeng, Ph.D. Software Architect
OakGate Product Family, Teledyne LeCroy

Learn more about Teledyne LeCroy OakGate Products

Automotive Ethernet in the Vehicle

Figure 1 Block diagram of a typical ADAS system
showing the in-vehicle networks used.
As all Automotive Ethernet technologies utilize a single twisted-pair cable (T1) and a point-to-point network topology, they differ primarily in their data rates and encoding methods. For the most part, the data rate determines the applications for which a particular Automotive Ethernet standard can be used. If we take the case of an automatic driver assistance system (ADAS), we can see where each Automotive Ethernet variant might best be used to replace existing automotive protocols. 

(Click on any figure to enlarge the image.)

08 June 2021

Fundamentals of Automotive Ethernet

Figure 1: Automotive Ethernet is designed to support
increasingly complex vehicle electronic systems.
When we speak of “Automotive Ethernet”, we’re referring to a group of Ethernet interfaces intended for in-vehicle use, customized to meet the needs of the automotive industry. The first Automotive Ethernet standard was defined by Broadcom in 2011 with BroadR-Reach. Since then, IEEE has released standards for 100Base-T1, 1000Base-T1, 10Base-T1S and most recently MultiGBase-T1. Together, these standards define the general technology known as Automotive Ethernet.

Probably the first question you ask is, “Why not just use standard Ethernet?” A summary of the fundamental features of Automotive Ethernet will show how much better Automotive Ethernet is than standard Ethernet at meeting the industry’s demand for a higher speed, robust, lightweight and lower cost data interface, one that can ultimately replace the many other protocols currently used throughout the vehicle.

01 June 2021

Five Tips to Improve Dynamic Range

Dynamic range is the ratio of the maximum signal level to the smallest signal level achievable in a measurement.  Tools with good dynamic range are especially helpful for analyzing wide dynamic range signals in which a full-scale signal must be acquired, while at the same time, very small amplitude signal details must be visible. Here are five tips for improving the dynamic range of your measurement instrument.

24 May 2021

Mode Conversion

Figure 1: The lower-left and upper-right quadrants of this
matrix show the S-parameters that represent mode conversion
from differential to common signal, and vice versa.
As said earlier, mixed-mode S-parameters describe the general case of combinations of differential and common signals. When we speak of mode conversion in mixed-mode S-parameters, we are referring to the change of a differential signal into a common signal, or a common signal into a differential signal, as it travels the transmission line. If we look at the matrix of mixed-mode S-parameters in Figure 1, we see that those mixed mode S-parameters affected by such a mode conversion—with a different type of signal going out than what went in—are in the lower-left and upper-right quadrants.  

Let’s take the S-parameters SCD11 and SCD21 to see how the combination of single-ended S-parameters they represent reveal the source of mode conversion. If we look at SCD11, the reflected mode conversion, as a function of its single-ended S-parameters, we see:

17 May 2021

Converting Single to Mixed-Mode S-Parameters

Figure 1: Model of two transmission lines with crosstalk
showing the transmission and crosstalk related S-parameters.

We have introduced mixed mode S-parameters and developed a formal structure for handling them. It is now time to discuss converting single-ended S-parameters into mixed-mode S-parameters. This is important because every instrument manufacturer obtains mixed mode S-parameters by first measuring single-ended S-parameters, then converting them mathematically to mixed-mode. This assumes that the interconnects being measured are passive, linear and time invariant.  Let’s begin with our model of two transmission lines with crosstalk shown in Figure 1.

12 May 2021

Introduction to Mixed-Mode S-parameters

Figure 1: Single-ended vs. differential signal
"world views" of S-parameters
We’ve treated single-ended S-parameters quite extensively in this blog. Links to several entries are listed at the bottom of this post. Now, we’re going to look at how we go from single-ended to mixed-mode S-parameters and what new information we can find in them. This will come in handy when we start looking at some of the MDI S-parameter tests that are performed for Automotive Ethernet compliance a bit down the road.

With single-ended S-parameters, we look at every combination of ‘going in signals’ and ‘coming out signals’. For example, two single-ended transmission lines and their return paths would yield a four-port S-parameter file. We take the complex ratios of each port combination to obtain the S-parameter value in the form of:


The bold typeface indicates complex quantities. 

But what happens if we drive two transmission lines with a differential source? Figure 1 compares the single-ended and differential signal world views.

04 May 2021

How to Use Memory Properly

In a recent post, we addressed setting sample rate for serial data acquisition, but let’s look again at how time per division (time/div), memory length and sample rate all interact, and what you can do to optimize your use of oscilloscope capture memory when setting up your timebase.
Figure 1: Sample rate as a function of time/div for three different memory lengths.
Longer memory extends the range of time/div settings that support the highest sample rate.

28 April 2021

Debugging Automotive Ethernet Transmitter Output Droop

Everyone manufacturing devices used for Automotive Ethernet knows what compliance limits they must meet, based on the electrical test specification, but it is not always obvious where to look for the source of the problem when a compliance test fails. We'll provide more Automotive Ethernet debugging tips in future posts, but here is one that arose from a reader's question: namely, why the 45% limit on output droop for 100Base-T1, and what might cause the problem?
Figure 1: Automotive Ethernet electrical testing is performed at the transmitter connector and is largely governed by channel/connector recommendations.  Between the transmitter and the connector is a Low-Pass Filter and a Common Mode Choke both affecting signal droop.

12 April 2021

How to Use Measurement Statistics to Set Up Triggers

Figure 1.  Histogram of the different pulse widths occurring
in a pulse-width modulated rectangular pulse train.
Triggering is an essential element in all modern digital oscilloscopes.  The trigger synchronizes the oscilloscope’s data acquisition with a user-specified event on the signal, be that an edge, threshold crossing or a specific signal characteristic. Teledyne LeCroy Smart Triggers can trigger oscilloscope acquisitions based on properties such as a period, width, low signal amplitude, slew rate or signal loss. These trigger types are ideal for capturing transient events like glitches, but they require knowing at least a range of possible values for the trigger to detect.

Intermittent transient events and glitches are among the most frustrating problems to detect and solve. This is especially true if you have no idea about the nature of the transient. However, you can use the oscilloscope’s measurement tools to help locate these bothersome transients, then use that information to set up your trigger to capture them when they occur. Here’s how.

05 April 2021

How to Test the CMRR of Differential Probes

Figure 1: CMRR plots for two attenuation
settings of an HVD3106A differential probe.
While recently we told you not to connect two probes to the same place at the same time, there is a case where connecting two tips of a differential probe to the same place at the same time is useful, and that is when testing the probe’s common mode rejection ratio (CMRR). CMRR is frequency dependent, so part of developing “situational awareness” of your test environment is to know how your probe behaves with different signals at different frequencies. 

Although CMRR as a function of frequency is a principal specification for differential probes, manufacturer's CMRR plots are the result of testing with a narrowband source under strictly controlled laboratory conditions. In real-world applications of probes to broadband sources, you can expect a different result. This quick test will inform you how different.

29 March 2021

How to "Layer" Measurement Tools

Figure 1: Multi-grid display "layers" multiple
measurement tools to find hidden glitch.
Teledyne LeCroy oscilloscopes have four, distinct sets of measurement tools, including measurement graticules, cursors, parameters and graphs. These tools developed historically and are designed to be “layered” on multi-grid MAUI® oscilloscopes so that each addition brings a new level of understanding and insight. Even on oscilloscopes that do not have multi-grid displays, as shown here, several measurement tools can be applied at once for added insight. Read on to see how, properly combined, they can help you find waveform anomalies and assess their frequency of occurrence in a few, simple steps.

22 March 2021

TDME Primer: Automated Timing Measurements

Figure 1: Interleaved decoding of USB-PD and DP-AUX signals.
Increasingly, serial data analysis is analysis of the interoperability of the many protocols that must perform together within interconnects and embedded systems. Nowhere is this more true than for USB-C® devices, which we’ll focus on in this post, although these examples of cross-protocol timing measurements could apply to any two protocols supported by our TDME and DME options.

The USB-C connector packs many protocols onto one, small pin set, and maintaining signal and power integrity is a compliance challenge. Besides high-speed data delivery, USB-PD (power delivery) provides flexible power distribution, while auxiliary sideband signals, like DisplayPort™, transport video. Troubleshooting these capabilities requires the ability to measure timing between serial data packets, as well as between data packets and analog signals. 

For example, DisplayPort over USB-C (DPoC) in alternate mode (alt-mode) can manifest as an interoperability failure if there is a timing issue between alt-mode initiation and the start of DP-AUX.

15 March 2021

The Important Difference Between ProtoSync™ and CrossSync™ PHY

Figure 1: CrossSync PHY captures everything from
physical through protocol layers at once.
With the recent release of our new CrossSync™ PHY for PCI Express® product, some of you may be wondering how it’s any different than ProtoSync™ for PCIe®, which has been around for quite a few years.

ProtoSync is an option for Teledyne LeCroy oscilloscopes with bandwidths that support high-speed serial data analysis. We’ve released ProtoSync options for PCIe, USB, SAS/SATA and Fibre Channel. ProtoSync links the same Protocol Analysis Suite software that is used with our protocol analyzers to the oscilloscope application, so that you can see physical layer decodings in the familiar PETracer and BITracer views right next to the decoded analog waveform. 

CrossSync PHY differs from ProtoSync in the three, significant ways:

08 March 2021

TDME Primer: Serial Trigger and Sequence Mode Sampling

Figure 1: Sequence mode sampling packs multiple acquisitions
into memory with very little “dead time” between them.
Sequence mode sampling, also referred to as segmented acquisition, is a sampling mode that divides the oscilloscope’s acquisition memory into a user-defined number of equal length segments. Each segment stores a single acquisition of the triggering event, with as much buffer zone as will fit into that segment, given the total number of segments requested. Only after all segments have been acquired is the data processed and displayed. 

The real power of sequence mode becomes evident when you combine it with intelligent triggers, such as the serial data triggers delivered with TDME options

01 March 2021

TDME Primer: Selecting Sample Rate for Serial Bus Analysis

Figure 1. Sample rate of only four sample points per bit
decodes correctly and lengthens serial bus acquisition.
Teledyne LeCroy supports trigger, decode, measure/graph, and eye diagram (TDME) software options for over 20 serial data standards, and the list is growing. This series will address practical tips for using TDME software successfully, and showcase some examples of applying TDME capabilities to real-world problems.

Given the wide range of protocols supported, you might be curious about how to best choose the oscilloscope sampling rate for a given standard when acquiring serial data signals. The optimal sample rate is determined by three principal factors: 

1) the bandwidth of the signal being digitized by the oscilloscope’s analog-to-digital converter (ADC);

2) the desired duration of the acquisition;

3) what you are going to do with the acquisition.

22 February 2021

Don't Attach Multiple Probes to the Same Place at the Same Time!

Figure 1. Response of two different probes to an
upper-side gate drive measurement.
Along with using single-ended passive probes for high-voltage measurements, another probing "no no" to avoid is attaching multiple probes to the same place at the same time.

You are probably aware that all measuring instruments, including oscilloscopes, are subject to conditions of observability.  As we discussed in a recent post on The Impact of the Interconnect, the very act of connecting the oscilloscope to the circuit with a particular probe affects the measurement in a particular way. Probes affect the circuit by applying additional resistance and capacitance loads in parallel with the circuit at the test point. Moreover, the probes themselves limit the fidelity of the measurement due to limits of bandwidth, slew rate and common mode response. So, it is always a good idea when making a measurement to compare how different probes/interconnects will affect the measurement…but don’t try to do it all at once.  

15 February 2021

Don't Probe HV with Single-ended Passive Probes!

Figure 1. A simple 120 Vrms switch-mode power supply
has a +/- 170 V peak and a 340 V pk-pk, difficult for
most single-ended passive probes to ground safely.

The high-impedance passive probes distributed with oscilloscopes of every major brand are sturdy, reliable and accurate within their specification limits, but they’re not intended for all applications.  This is especially true when measuring switch-mode power devices or other (relatively) high-voltage systems. These applications require probes that are both rated for their high voltage levels and isolated from ground as a reference voltage.  

High-impedance passive probes generally have maximum voltage limits of about 500 V and are ground referenced—meaning, one side of the probe is connected physically to earth ground through the oscilloscope.  If you’re measuring a single-phase 120 V line input to a power supply or inverter, you should be careful when connecting the probe ground to power neutral, which may not always be at ground level.  Using a differential probe, which is not ground referenced, eliminates this concern.

08 February 2021

Using Spectrograms to Visualize Spectral Changes

Figure 1. The spectrogram shows a history of
change in a spectrum and highlights variations
in frequency or amplitude.

In our last post, we discussed spectral analysis of RF in the lab as part of developing situational awareness. Another tool for spectral analysis is the spectrogram.

The spectrogram is a display composed of the most recently acquired 256 spectra all stacked in a persistence display. It is a feature of the SPECTRUM-1 and SPECTRUM-PRO-2R options that highlights variations in acquired spectra, making dynamic changes immediately visible. 

The spectrogram in Figure 1 shows the timing dynamics of a power rail load variation in a three-dimensional (3D) plot with color persistence. The same data could also be rendered in a flat, two-dimensional (2D) spectrogram display, or using monochrome instead of color persistence.  

01 February 2021

Situational Awareness: RF Noise in the Lab

Fig. 1. Time domain (top) and spectral (bottom) views of
ignal shown in SPECTRUM-1 on a WaveSurfer 4000HD. 
Laboratories have multiple sources of RF that can affect measurements, like computers, cell phones, routers, local radio and TV stations, even a nearby airport. Knowing the RF background of your lab is another part of Situational Awareness. Only by knowing the background can you know what is actually due to the device under test.

One way to read RF is through spectral analysis of Fourier transforms (DFT and FFT). FFTs take a time domain view of a signal (e.g, amplitude versus time trace) and change it into a spectrum of amplitude plotted as a function of frequency. Frequency spectrums are great for observing signals than are asynchronous with the process being measured. They have a lower noise floor and offer better dynamic range than do time domain plots.  Consider the views of the same signal shown in the time domain and frequency domain in Fig. 1.

25 January 2021

Situational Awareness: The Impact of the Interconnect

Fig 1. Coaxial cable has little effect on signal rise time,
but that's not true for every connection method.
How you connect a signal to your oscilloscope affects your measurements, and knowing the impact of different connection methods is an important part of your situational awareness.  

Using the same 40 ps fast edge signal we used for the risetime measurements in the last post, we’ll compare connections made using coaxial cable and a 10x passive probe, with and without different accessories.

18 January 2021

Situational Awareness: Testing Oscilloscope Outer Limits

Fig 1. 40 ps signal measured full bandwidth on a
1 GHz oscilloscope shows visible over/undershoot.
Nothing is perfect. Every test instrument has its limits, and knowing the limits to your oscilloscope’s bandwidth in response to real-world signals helps to develop situational awareness when making measurements. This is especially true when testing signals that are at or very near the specified bandwidth limit of the instrument.

The measurements we’ll demonstrate were made on a WaveSurfer 4104HD, a 12-bit, 4-channel, 1 GHz bandwidth oscilloscope that samples at up to 5 GS/s.

11 January 2021

Four Measurement Best Practices

To start the New Year right, we’re going to talk about four measurement "best practices", which will help you get the most out of any oscilloscope you have. These are important when doing any type of measurement—and you can get a good start on them simply by asking yourself the four questions in the sidebar.

1. Anticipate the results

Those who are familiar with Dr. Eric Bogatin’s Rule #9 will know this one. Before you do any measurement, anticipate what you expect the result to be, because that is the most important way of identifying if there is a potential problem. 

04 January 2021

Decision Feedback Equalization in DDR

Figure 1. A transmitted rectangular pulse suffers
distortion by the time it reaches the receiver. 
Broadening and reflections from previous
transmitted bits add to the pulse response, 
creating inter-symbol interference.

High-speed serial links such as those used in DDR4 and DDR5 are subject to a variety of signal degradation challenges.  Insertion losses, frequency dependent attenuation and inter-symbol interference (ISI), as well as others, are among the most commonly encountered sources of signal degradation. 

Figure 1 shows how reflections can cause ISI on a rectangular pulse. When a rectangular pulse is transmitted, it suffers distortion which is apparent when it reaches the receiver.  It may be broadened due to group delay dispersion because different frequency components of the signal propagate along the signal path at differing velocities. In addition, there may be echo pulses, due to impedance mismatches in the channel.  These mismatches cause reflections that propagate back and forth over the channel and appear as these echoes where subsequent bits should be.