EMC Precompliance Testing: Immunity/Susceptibility
Solution: Products that contain electronics can be sensitive to radio frequency (RF) interference. Devices that experience RF interference can be prone to improper or failed operations. Products that suffer problems when exposed to RF interference are said to be susceptible to interference while products that do not exhibit issues when exposed to RF interference are said to be immune to interference.
RF interference can cause:

• Scrambled display information
• Slow, Frozen, or locked operations (no response from keys, knobs)
• False or noisy data
• System reset or reboot

Design analysis, including part selection, shielding, and cable selection is the first step in creating a product that is capable of operating “as expected” under a certain degree of RF interference, but testing early under real world conditions is one sure way to determine if your design is susceptible to any issues with RF.
In this application note, we are going to show you how an RF generator and some simple tools can help you identify weaknesses in your product design.
A Word about Precompliance
Most governments have regulations in place that specify the amount of electromagnetic interference (EMI) a product can emit into the environment (radiated emissions) and conduct down the power cord (conducted emissions).There is also an increasing number of regulations that cover how much EMI a product can endure from outside sources (susceptibility).
Products being sold within the areas covered by these regulations must comply with the defined test limits. Compliance tests use these regulations to define the proper instrumentation, physical setup, and experimental techniques and experience to correctly record and report properly. This testing is very important and required for legal sale of the product within the covered area. Unfortunately, compliance testing can be expensive and difficult to execute due to the specialised equipment and knowledge required to properly conduct the tests.
Precompliance testing simulates the major details of a compliant test setup at a lower investment in time and money. Before you go to a compliance lab for testing, you can use precompliance tests to gather information about the performance of a design, make changes (if needed), and retest.. all in an effort to minimise the return trips to the compliance lab.
A word of caution, however. Precompliance data can be useful in hunting down many, if not all, of the non-compliant areas of a design but it is not a substitute for testing at a fully accredited compliance lab. Ultimately, the company (you) is responsible for proof of compliance to the full regulations for your product.
Radiated Susceptibility
Radiated susceptibility tests involve observing the operation of a device-under-test (DUT) while it is being subjected to a known RF source. The signal is delivered to the DUT using antennas for far-field testing or near field probes for board level tests.
Most radiated susceptibility regulations are based on IEC 61000-4-3 which defines the test signals range from 80-1,000MHz. This signal can be modulated by a 1kHz AM sine wave with 80% modulation depth. The modulated signal helps to quickly identify any rectification issues within sensitive circuit elements.

In far-field tests, an RF signal source, like the Rigol DSG3000 or DSG800 series is connected to an antenna that is set up a meter or two from the DUT. The RF source is then configured to source an output with 80% AM modulation at 1kHz. The amplitude should be set as high as possible, and the carrier frequency can be set at 9kHz.
NOTE: The DUT should be configured in its most commonly used state. All cabling (power, I/O, etc..) should be connected and in place. Cables can act like antennas and can directly influence performance.
Observe the DUT for any functional changes or issues such as a glitching or noisy display. Now, increase the carrier frequency and check the DUT. Step the center frequency of the generator and continue to observe the DUT, making note of the carrier frequencies that cause issues and the type of problems observed. After you have completed stepping up to 1GHz, you can rotate the DUT with respect to the antenna and re-test if you desire a more thorough test.
NOTE: Antennas and should only be used in shielded anechoic or semi- anechoic chambers to prevent interference with communications and emergency broadcast bands. It is illegal to broadcast over many frequency bands without proper licensing.
The use of an RF source like the Rigol DSG3000 (DSG3000B) or DSG800 series allows you to the flexibility to adjust the wavelength, power, and modulation of the output to help identify problem areas quickly.

Near Field testing is helpful because it does not require specialised chambers for testing. The E and H field probes only produce strong fields at distances less than 1” from the tip of the probe and do no radiate efficiently enough to cause problems with broadcast and emergency systems. Their small size also allows you to pinpoint the RF at specific circuit elements.

The RF source is configured exactly as in the far-field test, but this time, the probe tip is placed very close to the circuit or elements of the board at each carrier frequency. As you scan across the circuit, observe the DUT and be sure to check for any issues. Especially near sensitive analogue circuitry.
In the figure below, we removed the shielding from an oscilloscope board and used a probe and DSG3000 to deliver RF signals into the sensitive analogue front end. As you can see, with the shielding removed, the RF causes data corruption and changes the waveform significantly.

Figure 3: Using a near field probe on an unshielded Oscilloscope analogue input circuit.

Additional testing
Another useful test technique is to use a current probe and RF source to deliver RF signals to cables connected to the DUT. Cables can act like antennas and couple undesired signals to the DUT. You can use this setup to step through different frequencies and check the susceptibility of your design. Commercial current probes can be used.. but an acceptable current probe can be built using a snap-on ferrite choke, a few winds of insulated wire, some epoxy, and a BNC connector as shown below:

Simply setup your DUT and connect all of the cables that are common to its usage. Configure the source to output maximum power with the same 80% 1kHz AM modulation that was suggested for far and near field tests earlier and observe the DUT for problems. Step the carrier frequency and observe. Perform this test to the maximum desired frequency and repeat the process on each cable used with the DUT.
NOTE: Clamp probes should only be used in shielded anechoic or semi- anechoic chambers to prevent interference with communications and emergency broadcast bands. It is illegal to broadcast over many frequency bands without proper licensing.
To demonstrate the use of a current probe, we performed an experiment on a USB powered demonstration board. We used a DSG3000 and a homemade probe clamped to a non-filtered USB cable connected to the board and we monitored the output signal.

With no RF applied, the data was smooth.

But, when an RF signal was applied, the output began to show signs of interference. The worst interference occurred at a carrier of 110MHz, as shown below.

In conclusion, an RF source like the Rigol DSG3000 or DSG800 and some simple tools can enable you to test your designs for immunity issues early in the development process. Saving your company time and money.

Products Mentioned In This Article:

• DSG800 Series please see HERE
• DSG3000 Series has been discontinued, please see DSG3000B Series HERE
• NFP-3 Please see HERE

Introduction
Debugging embedded communications is one of the most common tasks for electronic design engineers. Efficient Analysis of serial communications requires more than simple triggering and decoding but historically there has been a significant cost difference between the oscilloscopes with mixed signal, serial triggering, and serial decode capabilities and the high performance instruments with advanced analysis. Engineers need the ability to test long term signal quality characteristics including jitter and eye patterns without investing in high performance, high cost solutions.
The MSO8000 (Figure 1) provides the most complete analysis capabilities, deepest memory, and highest sample rate in its class. Built for embedded design and debug, the MSO8000 is designed to enable engineers to speed verification and debug of serial communications on a budget. Let’s look at how class leading sampling, memory, and analysis can be used debug complex signal quickly and easily with the help of Jitter and Eye Analysis.

Figure 1: The MSO8000 High Performance Oscilloscope

Characterizing Jitter
Clock precision is critical to high performance digital data transmission. Subtle changes in clock frequency affect error rates and data throughput, but these timing errors can’t be visualized easily in a traditional oscilloscope view. Jitter analysis can be done on these types of signals. Utilizing the high sample rate and the deep memory, the oscilloscope compares the changes in time between thousands of clock transitions. This makes it possible to visualize timing fluctuations below 100 picoseconds while also tracking changes in clock timing over long time periods.

One of the keys to visualizing jitter is the TIE or Time Interval Error. The Time Interval Error is the difference in time between the occurrences of the expected and the actual clock edge. There are two main visualization tools we use with TIE for debugging. First, is the TIE trend graph. This shows the accumulated error in time of the TIE values. This trend is a valuable debug tool since it highlights periodic types of jitter. Figure 2 shows the high speed clock signal on channel 1 (yellow) and the TIE Jitter trend in purple. The vertical axis units for the TIE trend shown here is 10 nanoseconds per division. The trend shows that the jitter TIE accumulates periodically. That implies a periodic signal or event is affecting the clock frequency. Next, investigate the TIE trend with measurements or cursors as shown in Figure 3. The cursors make it easy to view the period of the signal and calculate the frequency as well (1/DX). Direct measurements of the TIE Trend can also be made. The period of these changes are an important clue as to the root cause of any jitter issues.
In addition to the TIE trend you can also calculate the distribution of the TIE values. The shape and standard deviation of the TIE values is an important component of determining root cause. For the signal above the histogram is shown in Figure 4.
When using the TIE trend and distribution to debug and solve jitter related issues it is important to understand the nature of the TIE values and trend. Remember, that TIE is calculated as the accumulated changes in the period of the underlying signal. This means that the TIE graph looks like the integral of changes in the period. Therefore, the triangle wave shown in the figures so far represent a square wave change in the period. This is critical to understanding how to debug signal jitter. The TIE trend shows the period changes lengthening linearly (triangle rising) and then the period changes shortening linearly (triangle falling). When TIE is increasing linearly, the period must be longer than the expected period, but at a fixed value since the sum is linear. When TIE is decreasing linearly, the period is at a fixed value shorter than expected. Therefore, the period is changing between 2 fixed values at this frequency. One is just above and one is just below the expected period. We are therefore looking for a 10 kHz square wave that is somehow affecting our clock timing. We can learn from the histogram that this fluctuation appears to be constant as the TIE distribution is evenly and symmetrically spread across those values.

Figure 2: TIE trend graph showing periodic jitter

Figure 3: TIE trend graph cursor measurements

Figure 4: TIE trend and TIE Histogram

After testing different nearby signals on our device under test, we find a time correlated square wave (Figure 5) shown in blue at that frequency that is affecting our serial clock timing.
Jitter can often be caused by issues with PLLs, power fluctuations, or emissions, among others. Let’s look at some use cases where the histogram data is important to correct jitter analysis.
Figure 6 shows a bimodal distribution of the TIE values in the histogram with a sinusoidal TIE trend. Here we can see the standard deviation (sigma in the histogram statistics) is about 3.2 ns. Since these trends have a mean value of close to zero, the standard deviation can also be approximated as the RMS value of the signal (shown in the RMS measurement in the bottom left). Since both sinusoidal waves and triangle waves have an integral that appear visually sinusoidal it can be difficult to discern whether the underlying changes to the clock period are more triangular or sinusoidal. The standard deviation and the histogram are additional tools that can help to determine what signals might be interfering. Often, signal timing shows a sharper correction or snapback to the nominal timing as the clock is realigned. Visually this can look like more of a ramp or saw wave. The histogram can help to visualize the asymmetry if the signal drifts slowly and then is corrected quickly. Figure 7 is a good example of an asymmetrical jitter distribution that still appears nearly sinusoidal in the jitter TIE trend. A distribution like this makes it easier to pinpoint the process that might be causing the fluctuations.
One important key to jitter measurements is to remember that this is about data integrity and ultimately about errors that cost the system time or bandwidth. In other words, it isn’t just about how much the timing might fluctuate but how your receiver views the data. For this reason it is important to test the signal for jitter in the way that the receiver is also determining the clock settings. In serial communications the clock can be explicit, meaning that there is a clock line transmitted for this purpose. There may also be a constant clock speed defined by the communication standard. It is also common for the receiver to ‘recover’ the clock from the signal itself using a PLL circuit.

Figure 5: Finding root cause with Jitter analysis

Figure 6: Standard Deviation of the histogram

Figure 7: Asymmetry in the histogram results

The design of the receiver has an outsized effect on jitter and timing. If the receiver uses a constant clock rate at a 70 Mb/sec rate the jitter appears as shown in the figures above. If the receiver uses a 1st order PLL with 200 kHz of bandwidth it can eliminate much of the low frequency jitter we saw at 10 kHz. This is shown in Figure 8. The MSO8000 can emulate explicit, constant, 1st order PLL, and 2nd order PLL clock recovery systems to precisely measure the jitter or eye diagram as it will be seen by the receiver. These are important capabilities to accurately debug critical timing issues and ignoring insignificant issues. Once we are correctly emulating the clock recovery and have removed key causes of jitter, we can zoom in on the TIE Trend to 500 picoseconds per division (Figure 9). We still see some periodic fluctuations but they have been reduced significantly and may no longer have any impact on the bit error rate. Once, all the jitter has been adequately addressed in the system you can view noise sources below 500 picoseconds per division as shown in Figure 10. The MSO8000 Oscilloscope also enables a direct statistical table view of the TIE values as well as Cycle to Cycle values and values calculated from both the positive and negative widths. Together, these jitter tools make it possible to carefully visualize and analyse timing issues in vital serial communication links.

Figure 8: Dynamic Clock Recovery

Figure 9: Remaining Jitter

Figure 10: Jitter Measurements

Signal Quality & the Eye Diagram
Timing is only one of the characteristics that contribute to overall signal quality. The goal of all signal quality analysis is to reduce data error in the transceiver link. Errors are often caused by timing and clock issues, but problems stemming from bandwidth, grounding, noise, and impedance matching all can impact how a bit is interpreted by the receiver. The best method for visualizing the holistic data signal quality is the eye pattern or eye diagram test. Real-time eye diagrams are a great way to validate and debug serial data links where throughput and bit error rate are important to system performance.
The eye diagram analyses the data line aligning the bit timing with the recovered clock. The same clock recovery options are available here as in the jitter toolkit. They eye diagram is then created by lining up and overlaying each bit. A density plot is then created from what can be thousands of bit sequences. This is called an eye pattern or eye diagram because the shape in the center resembles an open eye that closes to a point on each side. The goal is to have an open eye where the bit level (0 or 1) is correctly interpreted at the center of the eye.

The eye pattern in Figure 11 shows some potential issues. Depending on the user settable thresholds, the instrument calculates the width and height of the eye. This signal has a bandwidth limitation. We can interpret that because the slope of the rising and falling edges on each side of the eye is not as steep as our design planned for. Analytically, we can determine this by comparing the eye height, eye width, and signal risetime on the screen to our design documents. There also appears to be some frequency uncertainty with regard to the recovered clock. We can see from the histogram that the distribution of the period is not Gaussian implying some non-random causality to the frequency shifts. Lastly, there is some noise causing the amplitude to fluctuate. This closes the eye vertically.
Using the eye diagram as a visual debug tool, evaluate the cables and connections. Also, look for layout, cross-talk, or other emissions that might be impacting signal quality. Once we remove the signal causing the frequency fluctuations we see the eye start to open in Figure 12. The purple histogram now shows that the remaining timing errors are at least symmetrical. This also improves the eye width in the eye measurements window.
Figure 13 is the result once we identified and removed the nearby noise source. This improves the eye height and width and the entire signal is more precise. Now it is clear that the rising and falling bit transitions don’t reach the same high or low level as the non-transitioning bits. We also see that the rising and falling edges themselves have about a 45° slope with these time and voltage settings. The design document indicates that this should be higher. This is likely a bandwidth issue that is both limiting the risetime of the transitions and causing the eye to close vertically when the signal does not return all the way to its peak or base by the middle of the bit.
Finally, Figure 14 demonstrates improved bandwidth after changing our transmitter circuit. The histogram distribution shows that this has also removed some of the outliers in the signal timing. The improved bandwidth shows clearly in the improved Risetime as well as a completely open vertical eye.

Figure 11: Eye Diagram of signal causing errors

Figure 12: Eye Diagram with improved timing

Figure 13: Eye Diagram with improved noise

Figure 14: Eye Diagram after debugging and improvements

Conclusions
Embedded design and debugging of digital data is a critical requirement in modern electronic products. Modern high performance digital oscilloscopes expand the analysis capabilities available to the everyday engineer’s bench. RIGOL’s UltraVision II technology and our MSO8000 Series oscilloscopes (Figure 15) complete these tools with jitter and eye diagram analysis options making complete signal quality analysis affordable and easy to use. Jitter and eye diagram analysis on the MSO8000 simplifies viewing, analysing, and resolving issues involving timing, noise, bandwidth, and overall signal quality in serial data links. With new analysis capabilities built on the deep memory and high sample rate of the UltraVision II platform, RIGOL’s MSO8000 Series oscilloscopes are the high performance debugging tool of choice for today’s embedded engineer.

Figure 15: The MSO8000 High Performance Oscilloscope

Products Mentioned In This Article:

• MSO8000 Series please see HERE

Introduction
Embedded design and especially design work utilising low speed serial signalling is one of the fastest growing areas of digital electronics design. The need to communicate between modules, FPGAs, and processors within a wide array of consumer and industrial electronics is increasing at an astounding rate. Customised communication protocol and bus usage is critical to design efficiency and time to market, but comes with the risk of being sometimes difficult to analyse and debug. The most common sources and types of problems when using low speed serial data in an embedded application include timing, noise, signal quality, and data. We will recommend debug tips and features available in modern oscilloscopes that will make debugging these complex systems faster and easier.
Types of Errors
Timing
Timing is critical in any serial data system, but finding the system timing limitations related to components, transmission length, processing time, and other variables can be difficult. Let’s start with a simple 16 bit DAC circuit. First, make sure you understand the data and timing specifications for the protocol in use. Does it sample data right on the clock edge? How far off can the clock and data be when we still expect good data? In other words: do we have a clock sync error budget defined? Once we understand these timing requirements then we can experimentally verify both the Tx and Rx hardware subsystems. Now we can analyse the system level timing delays and the overall accuracy of the conversions because we can make direct measurements of both the logic and analogue channels in a time correlated fashion. We will also be able to simultaneously view the decoded bit patterns numerically on an oscilloscope that comes in well below your budget limits.
Here is a simple example of measuring a bit on channel 2 (blue) that is driving the DAC output that is creating the Sine wave on channel 1 (yellow).

Utilising parallel bus decoding (Figure 1) we can get a quick look at the transitions of this single line. But this doesn’t give us all the information we need since the DAC is utilising a number of data lines to set its output level. Getting more complete data requires a different approach. Let’s move all the DAC lines (Figure 2) over to the MSO’s digital inputs. Now we can see how the digital lines really coordinate with the DAC output. To investigate further we can simplify the decoding to show Hex values (Figure 3) and zoom in so we can view the decoded data.
Now we can use the zoom feature to clearly see the relationship between the bit and DAC transitions (Figure 4). For the zoom we have turned on analogue channel 2 in blue that is on the DAC clock. Zoomed in by a factor of 500x from 50 usec per division to 100 nsec per division allows us to see that the bit transitions are occurring 100 nsec before the clock transition. The clock transitions in under 5 nsec and the DAC output starts changing in sync with the clock. We can also utilise the scope cursors to make the timing in the transitions clearer and well defined (Figure 5).
Verifying timing in mixed signal systems can be made easier with the right tools. Select a modern scope with the correct set of channels and options to make sure you can easily view what you need on the display when you need it. From digital buses to processing delays, get the full picture of the device’s operation and delve into details as needed to verify timing issues on your device.

Figure 1: DAC output and input bit on a RIGOL MSO5354 Digital Oscilloscope

Figure 2: DAC output and 8 bit input bus on a RIGOL MSO5354 Digital Oscilloscope

Figure 3: DAC output and 8 bit input bus with Hex decode on a RIGOL MSO5354 Digital Oscilloscope

Figure 4: DAC output and 8 bit input bus zoomed in on a RIGOL MSO5354 Digital Oscilloscope

We can also trigger on the digital patterns instead of the analogue signal (Figure 6). Triggering on a digital pattern can be critical for debugging when there is a problem. There isn’t always a good way to track events from the analogue side of a system. When using a digital trigger method make sure to set the additional trigger parameters. These may include start bits or even address and data for some protocols. Even for a simple parallel bus like this you need to define and arrange the channels in the bus for the results to be easiest to interpret.
Accurate timing of Low Speed Serial signals is critical to system stability. Therefore, making sure your measurement tools are up to the task of precise and easy triggering, monitoring, and analysing of your waveforms is vital to improved R&D efficiency and ultimately time to market.

Noise

One of the most common issues in correct serial data measurements is the handling of system noise. Noise in these measurements can come from a number of sources including poor grounding, bandwidth issues, crosstalk, electromagnetic immunity (EMI) problems. Sometimes the problem is in the device, but improved probing and measurement techniques can also improve the results significantly without changing the device under test. A good first step is always to make sure we are using best measurement practices.
Here is a decoded I2C bus segment using a 5000 series oscilloscope (Figure 7). In the first example we have extremely poor grounding on our probes. Because the scope’s ground is tied directly to power ground signals that need to float or simply use a different or noisy ground plane can cause results like this. It is also possible for high current draw through ground in local power to create ground loops that can cause noise to be injected in your system. We solve these problems in order from easy to difficult. First, we can look at our probe connections. Normally, we would use the alligator clip ground strap that connects on the probe to make a ground connection. Assuming we are doing that correctly and still having a problem we may need to use the ground spring instead. The ground spring connects closer to the probe tip and significantly reduces the loop area of the connection. This can significantly improve noise and signal quality (Figure 8) especially for high speed signals or signals sensitive to capacitance or coupled voltages.

Figure 5: DAC output and 8 bit input bus zoomed in with cursors shown on a RIGOL MSO5354 Digital Oscilloscope

Figure 6: DAC output and 8 bit input bus triggered by a digital pattern on a RIGOL MSO5354 Digital Oscilloscope

Figure 7: I2C clock and data with noise from poor grounding in a colour graded display using a RIGOL MSO5354 Digital Oscilloscope

Figure 8: I2C clock and data with ground noise improved in a colour graded display using a RIGOL MSO5354 Digital Oscilloscope

All RIGOL probes come with both the standard ground strap and the ground spring for these types of measurements.
If ground noise is still an issue, try isolating your device from ground. The scope operates best grounded to AC power ground via the plug. If the rest of the device or system being tested can be isolated from ground this eliminates ground loops. If ground noise is still an issue you may consider a differential probe like the RP1100D (Figure 9) which enables measurements without reference to ground on the scope. Differential measurements may be the only way to clearly view some low speed serial data such as a LVDS bus (Low Voltage Differential Signalling). Buses like this purposely move the reference line to maximise bandwidth and increase communication distances, but it may require true differential probing or the use of multiple channels of your scope together to view the signal correctly. RIGOL has several different probe types for these measurements including the RP1000D series differential probes typically used for high voltage floating applications and the RP7150 1.5 GHz differential probe (Figure 10) for high speed data applications.

Now that we have improved our signal to noise ratio by decreasing noise injected from the ground, we can turn our attention to bandwidth filtering. High frequency noise can also enter your measurements via channel to channel cross talk or other high frequency sources nearby or within your

device. One way to address this is to utilise the channel bandwidth limits (Figure 11). Every RIGOL scope channel can limit the bandwidth to the ADC. A 20 MHz limit is pretty standard. Some scopes will have higher options as well.
Additionally, there are a few acquisition mode and triggering settings that can improve performance in the face of noise. Many trigger types have a menu item allowing you to turn on noise rejection for the triggering scheme. The 5000 series even includes HFR and LFR (high and low frequency rejection) as options in how to couple the signal triggered on. The 5000 series comes with High Res or High Resolution mode (Figure 12). This feature uses extra oversampling that is being done behind the scenes on many measurements to provide an average that results in less noise. This is best to use if you are able to set the sampling to take at least 200 samples per time division. This will average rather than reject high frequency signals, so be sure to understand your potential error sources and how they may interact with your measurement setup. Finally, the 5000 series scope also has an NRJ (noise reject) feature directly within the trigger menu. This removes noise that appears in bursts and can be set in time rather than frequency.
To further isolate and locate sources of noise within your system you may want to focus on EMC or EMI related issues. To further investigate these error sources please download the EMC Precompliance app note for use with the Rigol DSA815 Spectrum Analyser at http://www.rigolna.com/EMC

Noise is always a concern when working with low speed serial signals. By definition these signals continue to go to higher speeds, more advanced encoding, farther transmission distances, and lower voltage and power levels. All of these trends make hardware more susceptible to noise. Making careful measurements that limit or eliminate adding noise to our system then enables us to focus on noise in the system that may still cause long term design issues.

Figure 9: RP1100D 100 MHz Differential Probe

Figure 10: RP7150 1.5 GHz Differential Probe

Figure 11: I2C clock data with reduced noise using bandwidth limit on a RIGOL MSO5354 Digital Oscilloscope

Figure 12: I2C clock and data using high resolution mode on a RIGOL MSO5354 Digital Oscilloscope

Signal Quality
Monitoring and improving the quality of low speed serial signals is a critical part of the debugging process. Issues like impedance mismatches, bandwidth, and loading errors can all effect the quality of signals even when noise isn’t present. Now that we are looking more closely at the exact nature of these signals it is important to verify the way we are using our oscilloscope for these tests. For signal quality tests we will be using the analogue channels because they provide the best look at what is actually occurring with our signals. This requires some additional forethought. To clearly see data transitions, we should definitely use a sampling rate that is as high as possible. Sampling at 5x the bit rate of the digital bus should be considered the minimum because of the high frequency components that we need to visualise. Sampling at 10 times the bit rate should enable us to see

any of the issues. But when we decode the signal the scope likely uses a subset of the full memory data to handle the decode analysis. This can be important because you don’t necessarily want to decode being performed at too high of a rate. That can mask problems you will find when a more nominal receiver is used to decode the data. On RIGOL scopes the decode is done on 1 Mpts of memory spread across the acquisition. By setting the memory depth and the time per division the user can determine whether they want the decode to be done directly from the analogue points or from a subset. Decoding is also shown across the display region. To capture more decoded bytes than you can view on the display use the event table function (Figure 13). You can also export the table results to a text file from the event table menu for record keeping or offline timing analysis.
Here is an example table of how the memory depth, time per division, and sample rate effect the actual decode sample rate on a MSO5000 Series. Based on your serial data speeds and the receiver you will eventually use to collect the serial data you can optimise your serial decode rate.

Now that we have set and verified our sampling times for best analogue and decoding results, we also want to set our display up for optimal triggering conditions. When triggering on the rising edge of an analogue signal make sure to keep the trigger level at least 1 division away from the signal low state. This separation allows for consistent

triggering action without any false triggers. When visualising digital signals with the analogue channels use more screen real estate when possible. Using about 2 vertical divisions and about ½ to 1 horizontal division per decode character will allow you to see any major overshoot or impedance issues as well as some of the other types of error we will be looking at. Here is the setup (Figure 14) I prefer to monitor decoded data on a bus like RS232.
On a more complex bus like I2C we view both clock and data lines on the screen. The timing correlation between multiline buses is, of course, vital to successful decoding. Making critical measurements on the screen like risetime and overshoot for each line makes reliability tests simple to setup. We can view the measurements in max/min or using standard deviation notation for more advanced statistical testing (Figure 15).
In addition to the risetime and overshoot for the 4 serial bus lines you can also see the jitter in the clock when compared to the data transition. This test device appears to have the clock transition occur about 1.6 microseconds of jitter on the clock when viewed, as above, in reference to the triggering data transition. In (Figure 16) we zoom in on the data transition to get a more accurate measurement of the risetime and overshoot.
Signal quality encompasses many of the types of issues you find on LSS buses. Efficient debug means making the most of your embedded analysis capabilities to find signal discrepancies that can lead you to design changes as early as possible in your design process. A mixed signal oscilloscope is the perfect tool for measuring signal quality (Figure 17) from risetime variance to ASCII packet data.

Figure 13: I2C clock and data event table view using a RIGOL MSO5354 Digital Oscilloscope

Figure 14: RS232 optional decoded data view settings using a RIGOL MSO5354 Digital Oscilloscope

Figure 15: I2C clock and data min/max signal measurements using a RIGOL MSO5354 Digital Oscilloscope

Figure 16: I2C zoom in on data risetime measurement using a RIGOL MSO5354 Digital Oscilloscope

Data
The key to any Low Speed Serial application is the ability to quickly and easily look at the data being transmitted. This means adding the capability to do embedded decoding on your oscilloscope. Decoding affects both the triggering and display on the scope. It adds a decoded bus display to the instrument’s screen. You can decode values as ASCII or as hex, octal, or binary data depending on what you want to look at. You can also trigger on these values to make sure you are looking at the packets of most interest to you (Figure 18). In addition to triggering on these signals with the decode specific trigger you are also able to trigger on any type of signal with a zone trigger which allows you to not only to trigger on any type of signal but also exclude any unwanted noise or data from a signal. These are created by simply drawing a rectangle on the screen of the instrument (Figure 19).

Figure 17: I2C data measurements with standard deviation using a RIGOL MSO5354 Digital Oscilloscope

Figure 18: RS232 optimal decoded data view settings using a RIGOL MSO5354 Digital Oscilloscope

Figure 19: A zone trigger is added to exclude part of the RS232 signal.

Figure 20: RS232 event table capture of multiple transmissions using a RIGOL MSO5354 Digital Oscilloscope

If you are interested in timing between packets or evaluating more than one or two consecutive packets of data, use the event table mode (Figure 20) to generate a list of data packets on a wider time base. Additionally, with using an event table you are easily able to move around on the decoded signal by stopping the instrument from sampling and then select your desired trigger point in the packet’s submenu on the event table then press the Jump To button to move to the desired trigger point on the captured signal (Figure 21).
You can always utilise the zoom function to see the signals and data from an individual packet in that series (Figure 22).
Another way to view this signal is by using the search and navigation menu. This allows you to view multiple trigger points and easily move around on the signal when the scope has stopped scanning. All of the trigger points are represented on the search and navigation menu and they correspond to the white triangles at the top of the screen. The trigger point that is highlighted on the table corresponds with the red triangle at the top of the screen (Figure23).
To view how decoded segments, differ over time or compare between triggered events when other signals might be affecting the results the best analysis method is often to use record mode. RIGOL’s record mode enables you to capture thousands of frames around a trigger event. Once captured, you can use pass/fail or a trace difference analysis mode to visualise changes from frame to frame (Figure 24).

Figure 21: RS232 Event used to move around on the signal by using the Jump To soft key.

Figure 22: RS232 packet view using zoom mode on a RIGOL MSO5354 Digital Oscilloscope

Figure 23: Using Search and Navigation feature to move around on the RS232 signal.

Figure 24: I2C with pass/fail analysis enabled using a RIGOL MSO5354 Digital Oscilloscope

These recordings can be stored and played back as a movie as well, but the analysis features let you search for failures or outliers while also viewing decoded data for comparison (Figure 25).
Data errors as well as the debugging process are always closely tied to the protocol and its specifications. To be efficient with your test equipment make sure you are utilising the best analysis method to easily view the data you need to see without extraneous results getting in your way.

Figure 25: I2C transmission record mode in playback using a RIGOL MSO5354 Digital Oscilloscope

Keys to Look Out For
Proper Oversampling & Bandwidth
As discussed, proper sampling is critical to making correct measurements as well as completely debugging your low speed serial signal. A good rule of thumb for analogue signals is 5x the bandwidth of the signal you want to measure. This limits your risetime error to about 2%. To view the best detail on high frequency signal components set up your scope to achieve 5-10X over sampling as well. When digital signals this means sampling 5 times in the width of one bit. When sampling on digital lines or for sampling that will be used for decoding oversampling is less important but set up your measurement device so it is as similar as the LSS receiver you will ultimately be using. This gives you the best chance to focus on material errors that will cause problems down the road.

Grounding, Noise, and Differential Signalling Proper probing and understanding the use of
differential vs. ground referenced signals is important to debugging. If your data lines are not ground referenced make sure to understand the impact of ground loops and ground coupled noise on your measurements. Use proper probe techniques and advanced noise cancelling features on the scope to limit noise sources. If necessary, add differential probes to your measurement system to improve measurement quality.
How to Best View Low Speed Serial Signals There are a number of methods for analysing,
viewing, and evaluating LSS bus activity on a modern oscilloscope. The best way differs depending on whether you want to look at a single bit transition for noise, speed, or synchronization; whether you want to look at a complete packet of data; or if you want to compare packets and packet timing over a longer time period. Make sure your bench tools allow you to see everything you need and familiarise yourself with features like zoom, record mode, search and navigation, event tables, deep memory, and automatic measurements as well as how they interact and how best to transition between them when considering your test plan. Ideally, an oscilloscope empowers you to view all the results you need and quickly switch modes to acquire additional information.

Conclusions
Embedded design and debugging of digital data is a growing test requirement in a broad range of consumer and industrial applications. Having the right mixed signal oscilloscope can make viewing, analysing, and resolving issues including timing, noise, signal quality, and data easier and faster. This improves engineering efficiency and time to market. RIGOL’s line of UltraVision II enabled oscilloscopes comes with standard or optional capabilities for the methods and measurements discussed here and are powerful benchtop instruments that provide uncompromising performance at unprecedented value.

Products Mentioned In This Article:

• DSA815 please see HERE
• MSO5000 Series please see HERE
• RP7150 please see HERE

Power and Function
The relationship between power and function in an Internet of Things (IoT) project is perhaps the most fundamental trade-off a design team needs to address; therefore, it must be made with definitive, testable goals from the customer’s perspective. Expert product development always begins with the an IoT development where the final product is a wrapper around the ‘big idea’, but it is all the more important because of it. It can be tempting to design a product around a battery the engineering team has used before or a display they know how to integrate. This design approach focuses on solutions the engineering team can visualise and not what would satisfy or delight the customer. Instead, viewed through a user’s lens, the product may need to work for a week while recharging only once overnight. It may be important to be on instantly when needed or it may work just as well to push a button to wake the device for use. A battery warning may be required or a sleep mode may be acceptable. The best way to truly understand the options is to start with a definition of as many customer use models as reasonable. Ultimately, there is a trade-off between size/weight and use time/energy but there are many choices for optimization and a testing framework can assist in these determinations.
Estimating Power Usage in Development
An important first step is always to estimate the power required to collect data, make decisions, and take responding action within the requirements of your device. Estimating this usage over time in a theoretical model from specifications of components is useful, but ultimately rigorous, iterative use case testing is important to really understanding your power needs. In a modern IoT platform this measurement may not be straight forward.
A low power System on Chip (SoC) for IoT development may specify a power draw for the low energy Bluetooth (BLE) radio of 5-10 mA but that isn’t transmitting constantly. Depending on the power modes available a device could use tens of milliamps in operating mode while consuming less than several microamps in a global system sleep mode. Additionally, with a lot of chip development focused in this area the state of the art is always changing.
Power Test Methodologies
Traditional electronics battery power consumption could be measured simply with a digital multimeter (DMM) monitoring the current draw over time. Today’s IoT platforms may be more complicated. Often, a pulsed draw that is too quick for a typical DMM to measure is utilized. This requires a faster measurement system to verify. The IoT platform may provide a current measurement test point. An oscilloscope typically uses this to measure the voltage around a small sense resistor in the battery circuit. Depending on the accuracy and resolution you need this may be an effective technique. For instance, if a 10 Ohm resistor is used then every mA results in 10 mV. With a typical oscilloscope noise floor near 1-2 mV this may be noisy. Another option would be to use a current probe to capture the signal. The noise performance may not be as good but the connections are significantly easier if no current measurement test point is provided.
After establishing the best measurement technique for your system, I prefer to begin with a static measurement to establish baseline performance. Typically, I would use a standard example program. In this case, we will view the current draw from a simple program that toggles several LEDs. In this mode, we measure a baseline of about 5 mA. As shown in figure 1, activating each LED also requires 10-12 mA of current on this baseline.
Second, establish a start-up or bootup power requirement for the system. Here, we conducted a test from a hard boot. In addition to power we are also monitoring the energy usage using the integration of voltage * current over time as an approximation. Refer to Figure 2. Understanding the start-up power requirements from different boot states is critical to optimizing the design for sleep or shutdown power mode usage.

Not all of the peripherals utilize power in a DC fashion like LEDs. Test other peripherals you are using to see how they pull power from the battery. A simple test of the SPI bus demonstrates power being drawn in a pulsed fashion. Analysing the amplitude, width, and repetition rate of these current pulses (shown in Figure 3) enables us to understand the power usage.
We can use a similar method to test the actual output power of the Bluetooth radio as well as the battery power used during the transmission. This is important once the complete RF antenna layout is completed since power shortages here could result from reflections or mismatch in the RF path. In the test, we leave the Bluetooth Low Energy radio in a constant power transmit to easily monitor the power consumption. In a real use case, the transmit function is never constant, but the power values here are a guide to optimization in on time and power for the radio use cases. In the results below, a transmit power of 0 dBm resulted in 83 mA of power usage while a transmit power of -40 dBm resulted in 67 mA of current. Even in an off state, the radio example uses significant power to prep the radio and peripherals. These baseline values help us to determine the radio power and transmit cycles that may fit into our customer use cases. RF and DC power are shown for these 2 cases in Figure 4.

Once we have determined typical power levels by state and peripheral usage, the next step is to verify that there are no other effects contributing to power usage when in a more dynamic mode of switching operational states. We can test our code examples using a function to both measure instantaneous power and energy over time. With this approach, we can now determine the energy usage of an approach over time and see how different sleep algorithms generally affect battery life. With this level of information, code optimization in response to customer needs becomes much simpler.
In order to complete the IoT design and get a product to market quickly and cost effectively, our information on power usage in different setups and modes is an invaluable tool. The completed tests have enabled us to gather information about static state power usage for our platform and our required peripherals. We also have details on sleep states and boot power from which we can make informed decisions about trade-offs between battery size and use times in our customer use models. With a basic understanding of how power is consumed in our system we can use this as a guideline for incremental improvements throughout our design cycle. For instance, we better understand the advantage of waiting to service the peripherals vs. putting the whole system into sleep mode for a short period. These decisions can then be validated and refined as your application and use cases become clear.
Conclusions and Key Learnings
When working in the fast-changing atmosphere of IoT design and development, reliable test methodologies become increasingly important. As engineers integrate the newest sensors and platforms on the fly to reach highly competitive markets as fast as possible, understanding core customer requirements and trade-offs and how those can be evaluated and compared throughout the development is an important step toward improving the strategic design process.
Whether the challenges of an application are more form or function, issues related to battery life and power usage are fundamental elements of design in the IoT ecosystem that play a significant role in market success. Establishing these principles early in the process and testing them iteratively is one of the best ways to limit budget and schedule risks in the latter stages of the design. Modern, easy to use test equipment that is more affordable than ever can be utilized to develop the limits and baselines that will guide an engineering team through a successful product development.

Products Mentioned In This Article:

• Digital Multimeters please see HERE

Overview

A Bode plot is a graph that maps the frequency response of the system. It was first introduced by Hendrik Wade Bode in 1940.
The Bode plot consists of the Bode magnitude plot and the Bode phase plot. Both the amplitude and phase graphs are plotted against the frequency. The horizontal axis is lgω (logarithmic scale to the base of 10), and the logarithmic scale is used. The vertical axis of the Bode magnitude plot is 20lg (dB), and the linear scale is used, with the unit in decibel (dB). The vertical axis of the Bode phase plot uses the linear scale, with the unit in degree (°). Usually, the Bode magnitude plot and the Bode phase plot are placed up and down, with the Bode magnitude plot at the top, with their respective vertical axis being aligned. This is convenient to observe the magnitude and phase value at the same frequency, as shown in the following figure.

The loop analysis test method is as follows: Inject a sine-wave signal with constantly changing frequencies into a switching power supply circuit as the interference signal, and then judge the ability of the circuit system in adjusting the interference signal at various frequencies according to its output.
This method is commonly used in the test for the switching power supply circuit. The measurement results of the changes in the gain and phase of the output voltage can be output to form a curve, which shows the changes of the injection signal along with the frequency variation. The Bode plot enables you to analyse the gain margin and phase margin of the switching power supply circuit to determine its stability.

Principle

The switching power supply is a typical feedback loop control system, and its feedback gain model is as follows:

From the above formula, you can find out the cause for the instability of the closed-loop system: Given 1 + T(s) =0, the interference fluctuation of the system is infinite.

The instability arises from two aspects:

1) when the magnitude of the open-loop transfer function is:

2) when the phase of the open-loop transfer function is:

The above is the theoretical value. In fact, to maintain the stability of the circuit system, you need to spare a certain amount of margin. Here we introduce two important terms:

•  PM: phase margin.
  When the gain |T(s)| is 1, the phase <T(s) cannot be -180° . At this time, the distance between <T(s) and  -180° is the phase margin. PM refers to the amount of phase, which can be increased or decreased without making the system unstable. The greater the PM, the greater the stability of the system, and the slower the system response.
• GM: gain margin.
  When the phase <T(s)is -180°,  the gain |T(s)| cannot be 1. At this time, the distance between |T(s)| and 1 is the gain margin. The gain margin is expressed in dB. If |T(s)| is greater than 1, then the gain margin is a positive value. If |T(s)| is smaller than 1, then the gain margin is a negative value. The positive gain margin indicates that the system is
  stable, and the negative one indicates that the system is unstable.
  The following figure is the Bode plot. The curve in purple shows that the loop system gain varies with frequency. The curve in green indicates the variation of the loop system phase with frequency. In the figure, the frequency at which the GM is 0 dB is called “crossover frequency”.

The principle of the Bode plot is simple, and its demonstration is clear. It evaluates the stability of the closed-loop system with the open-loop gain of the system.

Loop Test Environment Setup

The following figure is the circuit topology diagram of the loop analysis test for the switching power supply by using RIGOL’s MSO5000 series digital oscilloscope. The loop test environment is set up as follows:
1. Connect a 5Ω injection resistor Rinj to the feedback circuit, as indicated by the red circle in the following figure.
2. Connect the GI connector of the MSO5000 series digital oscilloscope to an isolated transformer. The swept sine-wave signal output from the oscilloscope’s built-in waveform generator is connected in parallel to the two ends of the injection resistor Rinj through the isolated transformer.
3. Use the probe that connects the two analogue channels of the MSO5000 series digital oscilloscope (e.g. RIGOL’s PVP2350 probe) to measure the injection and output ends of the swept signal.

The following figure is the physical connection diagram of the test environment.

Operation Procedures

The following section introduces how to use RIGOL’s MSO5000 series digital oscilloscope to carry out the loop analysis. The operation procedures are shown in the figure below.

Step 1 To Enable the Bode Plot Function
You can also enable the touch screen and then tap the function navigation icon at the lower-left corner of the screen to open the function navigation. Then, tap the “Bode” icon to open the “Bode” setting menu.
Step 2 To Set the Swept Signal
Press Amp/Freq Set. to enter the amplitude/frequency setting menu. Then the Bode Set window is displayed. You can tap the input field of various parameters on the touch screen to set the parameters by inputting values with the pop-up numeric keypad. Press Var.Amp. continuously to enable or disable the voltage amplitude of the swept signal in the different frequency ranges.

The definitions for the parameters on the screen are shown in the following table.

Note:
The set “StopFreq” must be greater than the “StartFreq”.
Press Sweep Type, and rotate the multifunction knob to select the desired sweep type, and then press down the knob to select it. You can also enable the touch screen to select it.

• Lin: the frequency of the swept sine wave varies linearly with the time.
• Log: the frequency of the swept sine wave varies logarithmically with the time.

Step 3 To Set the Input/Output Source
As shown in the circuit topology diagram in Loop Test Environment Setup, the input source acquires the injection signal through the analog channel of the oscilloscope, and the output source acquires the output signal of the device under test (DUT) through the analog channel of the oscilloscope. Set the output and input sources by the following operation methods.
Press In and rotate the multifunction knob to select the desired channel, and then press down the knob to select it. You can also enable the touch screen to select it.
Press Out and rotate the multifunction knob to select the desired channel, and then press down the knob to select it. You can also enable the touch screen to select it.
Step 4 To Enable the Loop Analysis Test
In the Bode setting, the initial running status shows “Start” under the Run Status key. Press this key, and then the Bode Wave window is displayed. In the window, you can see that a Bode plot is drawing. At this time, tap the “Bode Wave” window, the Run Status menu is displayed. Under the menu, “Stop” is shown under the Run Status menu.

Step 5 To View the Measurement Results from the Bode Plot
After the Bode plot has been completed drawing, the Run Status menu shows “Start” again. You can view the Bode plot in the Bode Wave window, as shown in the following figure.

The following table lists the descriptions for the main elements in the Bode plot.

Press Disp Type and rotate the multifunction knob to select “Chart” as the display type of the Bode plot. The following table will be displayed, and you can view the parameters of the measurement results for loop analysis test.

Step 6 To Save the Bode Plot File
After the test has been completed, save the test results as a specified file type with a specified filename.
Press File Type to select the file type for saving the Bode plot. The available file types include “*.png”, “*.bmp”, “*.csv”, and “*.html”. When you select “*.png” or “*.bmp” as the file type, the Bode plot will be saved as a form of waveform. When you select “*.csv” or “*.html”, the Bode plot will be saved as a form of chart.
Press File Name, input the filename for the Bode plot in the pop-up numeric keypad.

Key Points in Operation

When performing the loop analysis test for the switching power supply, pay attention to the following points when injecting the test stimulus signal.
Selection of the Interference Signal Injection Location
We make use of feedback to inject the interference signal. Generally speaking, in the voltage-feedback switching power supply circuit, we usually put the injection resistor between the output voltage point and the voltage dividing resistor of the feedback loop. In the current-feedback switching power supply circuit, put the injection resistor behind the feedback circuit.
Selection of the Injection Resistor
When choosing the injection resistor, keep in mind that the injection resistor you select should not affect the system stability. As the voltage dividing resistor is generally a type that is at or above kΩ level, the impedance of the injection resistor that you select should be between 5Ω and 10Ω.
Selection of Voltage Amplitude of the Injected Interference Signal
You can attempt to try the amplitude of the injected signal from 1/20 to 1/5 of the output voltage.

If the voltage of the injected signal is too large, this will make the switching power supply be a nonlinear circuit, resulting in measurement distortion. If the voltage of the injected signal in the low frequency band is too small, it will cause a low signal-to-noise ratio and large interference.
Usually we tend to use a higher voltage amplitude when the injection signal frequency is low, and use a lower voltage amplitude when the injection signal frequency is higher. By selecting different voltage amplitudes in different frequency bands of the injection signal, we can obtain more accurate measurement results. MSO5000 series digital oscilloscope supports the swept signal with variable output frequencies. For details, refer to the function of the Var.Amp. key introduced in Step 2 To Set the Swept Signal.
Selection of the Frequency Band for the Injected Interference Signal
The frequency sweep range of the injection signal should be near the crossover frequency, which makes it easy to observe the phase margin and gain margin in the generated Bode plot. In general, the crossover frequency of the system is between 1/20 and 1/5 of the switching frequency, and the frequency band of the injection signal can be selected within this frequency range.

Experience

The switching power supply is a typical feedback control system, and it has two important indicators: system response and system stability. The system response refers to the speed required for the power supply to quickly adjust when the load changes or the input voltage changes. System stability is the ability of the system in suppressing the input interference signals of different frequencies.
The greater the phase margin, the slower the system response. The smaller the phase margin, the poorer the system stability. Similarly, if the crossing frequency is too high, the system stability will be affected; if it is too low, the system response will be slow. To balance the system response and stability, we share you the following experience:
● The crossing frequency is recommended to be 1/20 to 1/5 of the switching frequency.

● The phase margin should be greater than 45°. 45° to 80° is recommended.

● The gain margin is recommended to be greater than 10 dB.

Summary

RIGOL’s MSO5000 series digital oscilloscope can generate the swept signal of the specified range by controlling the built-in signal generator module and output the signal to the switching power supply to carry out loop analysis test. The Bode plot generated from the test can display the gain and phase variations of the system under different frequencies. From the plot, you can see the phase margin, gain margin, crossover frequency, and other important parameters. The Bode plot function is easy to operate, and engineers may find it convenient in analysing the circuit system stability.

Upgrade Method
Online Upgrade
After the oscilloscope is connected to network (if you do not have the access to the Internet, please ask the administrator to open the specified network authority) via the LAN interface, you can perform online upgrading for the system software.
1) Enable the touch screen and then tap the function navigation icon at the lower-left corner of the touch screen to enable the function navigation.
2) Tap the “Help” icon, and then the “Help” menu is displayed on the screen.
3) Press Online upgrade or enable the touch screen to tap “Online upgrade”, then a “System Update Information” window is displayed, requesting you whether to accept or cancel “RIGOL PRODUCT ONLINE UPGRADE SERVICE TERMS”. Tap “Accept” to start online upgrade. Tap “Cancel” to cancel the online upgrade.

For the local upgrade, please download the latest firmware from the following website and then perform the upgrade.

Products Mentioned In This Article:

• MSO5000 Series please see HERE
• PVP2350 please see HERE

Introduction
Embedded design and especially design work utilising low speed serial signalling is one of the fastest growing areas of digital electronics design. The need to communicate between modules, FPGAs, and processors within a wide array of consumer and industrial electronics is increasing at an astounding rate. Customised communication protocol and bus usage is critical to design efficiency and time to market, but comes with the risk of being sometimes difficult to analyse and debug. The most common sources and types of problems when using low speed serial data in an embedded application include timing, noise, signal quality, and data. We will recommend debug tips and features available in modern oscilloscopes that will make debugging these complex systems faster and easier.
Types of Errors
Timing
Timing is critical in any serial data system, but finding the system timing limitations related to components, transmission length, processing time, and other variables can be difficult. Let’s start with a simple 16 bit DAC circuit. First, make sure you understand the data and timing specifications for the protocol in use. Does it sample data right on the clock edge? How far off can the clock and data be when we still expect good data? In other words: do we have a clock sync error budget defined? Once we understand these timing requirements then we can experimentally verify both the Tx and Rx hardware subsystems. Now we can analyse the system level timing delays and the overall accuracy of the conversions because we can make direct measurements of both the logic and analogue channels in a time correlated fashion. We will also be able to simultaneously view the decoded bit patterns numerically on an oscilloscope that comes in well below your budget limits.
Here is a simple example of measuring a bit on channel 2 (blue) that is driving the DAC output that is creating the Sine wave on channel 1 (yellow).

Utilising parallel bus decoding (Figure 1) we can get a quick look at the transitions of this single line. But this doesn’t give us all the information we need since the DAC is utilising a number of data lines to set its output level. Getting more complete data requires a different approach. Let’s move all the DAC lines (Figure 2) over to the MSO’s digital inputs. Now we can see how the digital lines really coordinate with the DAC output. To investigate further we can simplify the decoding to show Hex values (Figure 3) and zoom in so we can view the decoded data.
Now we can use the zoom feature to clearly see the relationship between the bit and DAC transitions (Figure 4). For the zoom we have turned on analogue channel 2 in blue that is on the DAC clock. Zoomed in by a factor of 500x from 50 usec per division to 100 nsec per division allows us to see that the bit transitions are occurring 100 nsec before the clock transition. The clock transitions in under 5 nsec and the DAC output starts changing in sync with the clock. We can also utilise the scope cursors to make the timing in the transitions clearer and well defined (Figure 5).
Verifying timing in mixed signal systems can be made easier with the right tools. Select a modern scope with the correct set of channels and options to make sure you can easily view what you need on the display when you need it. From digital buses to processing delays, get the full picture of the device’s operation and delve into details as needed to verify timing issues on your device.

Figure 1: DAC output and input bit on a RIGOL MSO5354 Digital Oscilloscope

Figure 2: DAC output and 8 bit input bus on a RIGOL MSO5354 Digital Oscilloscope

Figure 3: DAC output and 8 bit input bus with Hex decode on a RIGOL MSO5354 Digital Oscilloscope

Figure 4: DAC output and 8 bit input bus zoomed in on a RIGOL MSO5354 Digital Oscilloscope

We can also trigger on the digital patterns instead of the analogue signal (Figure 6). Triggering on a digital pattern can be critical for debugging when there is a problem. There isn’t always a good way to track events from the analogue side of a system. When using a digital trigger method make sure to set the additional trigger parameters. These may include start bits or even address and data for some protocols. Even for a simple parallel bus like this you need to define and arrange the channels in the bus for the results to be easiest to interpret.
Accurate timing of Low Speed Serial signals is critical to system stability. Therefore, making sure your measurement tools are up to the task of precise and easy triggering, monitoring, and analysing of your waveforms is vital to improved R&D efficiency and ultimately time to market.

Noise

One of the most common issues in correct serial data measurements is the handling of system noise. Noise in these measurements can come from a number of sources including poor grounding, bandwidth issues, crosstalk, electromagnetic immunity (EMI) problems. Sometimes the problem is in the device, but improved probing and measurement techniques can also improve the results significantly without changing the device under test. A good first step is always to make sure we are using best measurement practices.
Here is a decoded I2C bus segment using a 5000 series oscilloscope (Figure 7). In the first example we have extremely poor grounding on our probes. Because the scope’s ground is tied directly to power ground signals that need to float or simply use a different or noisy ground plane can cause results like this. It is also possible for high current draw through ground in local power to create ground loops that can cause noise to be injected in your system. We solve these problems in order from easy to difficult. First, we can look at our probe connections. Normally, we would use the alligator clip ground strap that connects on the probe to make a ground connection. Assuming we are doing that correctly and still having a problem we may need to use the ground spring instead. The ground spring connects closer to the probe tip and significantly reduces the loop area of the connection. This can significantly improve noise and signal quality (Figure 8) especially for high speed signals or signals sensitive to capacitance or coupled voltages.

Figure 5: DAC output and 8 bit input bus zoomed in with cursors shown on a RIGOL MSO5354 Digital Oscilloscope

Figure 6: DAC output and 8 bit input bus triggered by a digital pattern on a RIGOL MSO5354 Digital Oscilloscope

Figure 7: I2C clock and data with noise from poor grounding in a colour graded display using a RIGOL MSO5354 Digital Oscilloscope

Figure 8: I2C clock and data with ground noise improved in a colour graded display using a RIGOL MSO5354 Digital Oscilloscope

All RIGOL probes come with both the standard ground strap and the ground spring for these types of measurements.
If ground noise is still an issue, try isolating your device from ground. The scope operates best grounded to AC power ground via the plug. If the rest of the device or system being tested can be isolated from ground this eliminates ground loops. If ground noise is still an issue you may consider a differential probe like the RP1100D (Figure 9) which enables measurements without reference to ground on the scope. Differential measurements may be the only way to clearly view some low speed serial data such as a LVDS bus (Low Voltage Differential Signalling). Buses like this purposely move the reference line to maximise bandwidth and increase communication distances, but it may require true differential probing or the use of multiple channels of your scope together to view the signal correctly. RIGOL has several different probe types for these measurements including the RP1000D series differential probes typically used for high voltage floating applications and the RP7150 1.5 GHz differential probe (Figure 10) for high speed data applications.

Now that we have improved our signal to noise ratio by decreasing noise injected from the ground, we can turn our attention to bandwidth filtering. High frequency noise can also enter your measurements via channel to channel cross talk or other high frequency sources nearby or within your

device. One way to address this is to utilise the channel bandwidth limits (Figure 11). Every RIGOL scope channel can limit the bandwidth to the ADC. A 20 MHz limit is pretty standard. Some scopes will have higher options as well.
Additionally, there are a few acquisition mode and triggering settings that can improve performance in the face of noise. Many trigger types have a menu item allowing you to turn on noise rejection for the triggering scheme. The 5000 series even includes HFR and LFR (high and low frequency rejection) as options in how to couple the signal triggered on. The 5000 series comes with High Res or High Resolution mode (Figure 12). This feature uses extra oversampling that is being done behind the scenes on many measurements to provide an average that results in less noise. This is best to use if you are able to set the sampling to take at least 200 samples per time division. This will average rather than reject high frequency signals, so be sure to understand your potential error sources and how they may interact with your measurement setup. Finally, the 5000 series scope also has an NRJ (noise reject) feature directly within the trigger menu. This removes noise that appears in bursts and can be set in time rather than frequency.
To further isolate and locate sources of noise within your system you may want to focus on EMC or EMI related issues. To further investigate these error sources please download the EMC Precompliance app note for use with the Rigol DSA815 Spectrum Analyser at http://www.rigolna.com/EMC

Noise is always a concern when working with low speed serial signals. By definition these signals continue to go to higher speeds, more advanced encoding, farther transmission distances, and lower voltage and power levels. All of these trends make hardware more susceptible to noise. Making careful measurements that limit or eliminate adding noise to our system then enables us to focus on noise in the system that may still cause long term design issues.

Figure 9: RP1100D 100 MHz Differential Probe

Figure 10: RP7150 1.5 GHz Differential Probe

Figure 11: I2C clock data with reduced noise using bandwidth limit on a RIGOL MSO5354 Digital Oscilloscope

Figure 12: I2C clock and data using high resolution mode on a RIGOL MSO5354 Digital Oscilloscope

Signal Quality
Monitoring and improving the quality of low speed serial signals is a critical part of the debugging process. Issues like impedance mismatches, bandwidth, and loading errors can all effect the quality of signals even when noise isn’t present. Now that we are looking more closely at the exact nature of these signals it is important to verify the way we are using our oscilloscope for these tests. For signal quality tests we will be using the analogue channels because they provide the best look at what is actually occurring with our signals. This requires some additional forethought. To clearly see data transitions, we should definitely use a sampling rate that is as high as possible. Sampling at 5x the bit rate of the digital bus should be considered the minimum because of the high frequency components that we need to visualise. Sampling at 10 times the bit rate should enable us to see

any of the issues. But when we decode the signal the scope likely uses a subset of the full memory data to handle the decode analysis. This can be important because you don’t necessarily want to decode being performed at too high of a rate. That can mask problems you will find when a more nominal receiver is used to decode the data. On RIGOL scopes the decode is done on 1 Mpts of memory spread across the acquisition. By setting the memory depth and the time per division the user can determine whether they want the decode to be done directly from the analogue points or from a subset. Decoding is also shown across the display region. To capture more decoded bytes than you can view on the display use the event table function (Figure 13). You can also export the table results to a text file from the event table menu for record keeping or offline timing analysis.
Here is an example table of how the memory depth, time per division, and sample rate effect the actual decode sample rate on a MSO5000 Series. Based on your serial data speeds and the receiver you will eventually use to collect the serial data you can optimise your serial decode rate.

Now that we have set and verified our sampling times for best analogue and decoding results, we also want to set our display up for optimal triggering conditions. When triggering on the rising edge of an analogue signal make sure to keep the trigger level at least 1 division away from the signal low state. This separation allows for consistent

triggering action without any false triggers. When visualising digital signals with the analogue channels use more screen real estate when possible. Using about 2 vertical divisions and about ½ to 1 horizontal division per decode character will allow you to see any major overshoot or impedance issues as well as some of the other types of error we will be looking at. Here is the setup (Figure 14) I prefer to monitor decoded data on a bus like RS232.
On a more complex bus like I2C we view both clock and data lines on the screen. The timing correlation between multiline buses is, of course, vital to successful decoding. Making critical measurements on the screen like risetime and overshoot for each line makes reliability tests simple to setup. We can view the measurements in max/min or using standard deviation notation for more advanced statistical testing (Figure 15).
In addition to the risetime and overshoot for the 4 serial bus lines you can also see the jitter in the clock when compared to the data transition. This test device appears to have the clock transition occur about 1.6 microseconds of jitter on the clock when viewed, as above, in reference to the triggering data transition. In (Figure 16) we zoom in on the data transition to get a more accurate measurement of the risetime and overshoot.
Signal quality encompasses many of the types of issues you find on LSS buses. Efficient debug means making the most of your embedded analysis capabilities to find signal discrepancies that can lead you to design changes as early as possible in your design process. A mixed signal oscilloscope is the perfect tool for measuring signal quality (Figure 17) from risetime variance to ASCII packet data.

Figure 13: I2C clock and data event table view using a RIGOL MSO5354 Digital Oscilloscope

Figure 14: RS232 optional decoded data view settings using a RIGOL MSO5354 Digital Oscilloscope

Figure 15: I2C clock and data min/max signal measurements using a RIGOL MSO5354 Digital Oscilloscope

Figure 16: I2C zoom in on data risetime measurement using a RIGOL MSO5354 Digital Oscilloscope

Data
The key to any Low Speed Serial application is the ability to quickly and easily look at the data being transmitted. This means adding the capability to do embedded decoding on your oscilloscope. Decoding affects both the triggering and display on the scope. It adds a decoded bus display to the instrument’s screen. You can decode values as ASCII or as hex, octal, or binary data depending on what you want to look at. You can also trigger on these values to make sure you are looking at the packets of most interest to you (Figure 18). In addition to triggering on these signals with the decode specific trigger you are also able to trigger on any type of signal with a zone trigger which allows you to not only to trigger on any type of signal but also exclude any unwanted noise or data from a signal. These are created by simply drawing a rectangle on the screen of the instrument (Figure 19).

Figure 17: I2C data measurements with standard deviation using a RIGOL MSO5354 Digital Oscilloscope

Figure 18: RS232 optimal decoded data view settings using a RIGOL MSO5354 Digital Oscilloscope

Figure 19: A zone trigger is added to exclude part of the RS232 signal.

Figure 20: RS232 event table capture of multiple transmissions using a RIGOL MSO5354 Digital Oscilloscope

If you are interested in timing between packets or evaluating more than one or two consecutive packets of data, use the event table mode (Figure 20) to generate a list of data packets on a wider time base. Additionally, with using an event table you are easily able to move around on the decoded signal by stopping the instrument from sampling and then select your desired trigger point in the packet’s submenu on the event table then press the Jump To button to move to the desired trigger point on the captured signal (Figure 21).
You can always utilise the zoom function to see the signals and data from an individual packet in that series (Figure 22).
Another way to view this signal is by using the search and navigation menu. This allows you to view multiple trigger points and easily move around on the signal when the scope has stopped scanning. All of the trigger points are represented on the search and navigation menu and they correspond to the white triangles at the top of the screen. The trigger point that is highlighted on the table corresponds with the red triangle at the top of the screen (Figure23).
To view how decoded segments, differ over time or compare between triggered events when other signals might be affecting the results the best analysis method is often to use record mode. RIGOL’s record mode enables you to capture thousands of frames around a trigger event. Once captured, you can use pass/fail or a trace difference analysis mode to visualise changes from frame to frame (Figure 24).

Figure 21: RS232 Event used to move around on the signal by using the Jump To soft key.

Figure 22: RS232 packet view using zoom mode on a RIGOL MSO5354 Digital Oscilloscope

Figure 23: Using Search and Navigation feature to move around on the RS232 signal.

Figure 24: I2C with pass/fail analysis enabled using a RIGOL MSO5354 Digital Oscilloscope

These recordings can be stored and played back as a movie as well, but the analysis features let you search for failures or outliers while also viewing decoded data for comparison (Figure 25).
Data errors as well as the debugging process are always closely tied to the protocol and its specifications. To be efficient with your test equipment make sure you are utilising the best analysis method to easily view the data you need to see without extraneous results getting in your way.

Figure 25: I2C transmission record mode in playback using a RIGOL MSO5354 Digital Oscilloscope

Keys to Look Out For
Proper Oversampling & Bandwidth
As discussed, proper sampling is critical to making correct measurements as well as completely debugging your low speed serial signal. A good rule of thumb for analogue signals is 5x the bandwidth of the signal you want to measure. This limits your risetime error to about 2%. To view the best detail on high frequency signal components set up your scope to achieve 5-10X over sampling as well. When digital signals this means sampling 5 times in the width of one bit. When sampling on digital lines or for sampling that will be used for decoding oversampling is less important but set up your measurement device so it is as similar as the LSS receiver you will ultimately be using. This gives you the best chance to focus on material errors that will cause problems down the road.

Grounding, Noise, and Differential Signalling Proper probing and understanding the use of
differential vs. ground referenced signals is important to debugging. If your data lines are not ground referenced make sure to understand the impact of ground loops and ground coupled noise on your measurements. Use proper probe techniques and advanced noise cancelling features on the scope to limit noise sources. If necessary, add differential probes to your measurement system to improve measurement quality.
How to Best View Low Speed Serial Signals There are a number of methods for analysing,
viewing, and evaluating LSS bus activity on a modern oscilloscope. The best way differs depending on whether you want to look at a single bit transition for noise, speed, or synchronization; whether you want to look at a complete packet of data; or if you want to compare packets and packet timing over a longer time period. Make sure your bench tools allow you to see everything you need and familiarise yourself with features like zoom, record mode, search and navigation, event tables, deep memory, and automatic measurements as well as how they interact and how best to transition between them when considering your test plan. Ideally, an oscilloscope empowers you to view all the results you need and quickly switch modes to acquire additional information.

Conclusions
Embedded design and debugging of digital data is a growing test requirement in a broad range of consumer and industrial applications. Having the right mixed signal oscilloscope can make viewing, analysing, and resolving issues including timing, noise, signal quality, and data easier and faster. This improves engineering efficiency and time to market. RIGOL’s line of UltraVision II enabled oscilloscopes comes with standard or optional capabilities for the methods and measurements discussed here and are powerful benchtop instruments that provide uncompromising performance at unprecedented value.

Products Mentioned In This Article:

• DSA815 please see HERE
• MSO5000 Series please see HERE
• RP7150 please see HERE

Introduction
As the Internet of Things continues to expand to include applications including home automation, fitness, video, and tracking as well as traditional embedded electronics use cases the needs for testing and optimising these designs become clearer. Even as IoT expands, the test requirements have begun to crystallise into a set of capabilities that can assist a design team in achieving their goals. This is especially important given the smaller, more versatile teams and companies charting a path in IoT. As companies and engineers often new to large scale design work attempt to make new types of successful consumer products, IoT projects will continue to progress in fits and starts until designers find the optimal mix of form and function for each target audience creating reliability and annoyances like additional time required to charge the IoT device. By first considering test requirements as a method for evaluating these concerns, a design team can speed time to market and ultimately reduce the iterations required to create a successful product platform. Selecting the best test equipment for the task at hand also enables engineers to stay within their start-up budget requirements. Signal integrity is a key design aspects whose importance is magnified by these inherent trade-offs in the IoT landscape. Focusing on signal integrity as a key indicator of the optimal approach for an IoT application from debug through final design enables a small IoT design team to leverage their capabilities and ultimately reward their customers with performance and ease. Here we will be discussing important examples of signal integrity test methodologies for IoT devices and how they impact the user experience from form to function.

From and Reliability
It is crucial to consider how dramatically signal integrity and reliability are affected by mechanical implementation. The trend for IoT products, especially wearables, continues to be sleeker, lighter, and smaller. Optimising the form of the product for users is therefore often in conflict with reliability, ruggedness, and signal integrity requirements. Designs that strike a balance too close to the aesthetic ideal often fail to succeed for these core functional reasons. With more demand for waterproof and rugged designs that also integrate accelerometers and other sensors we create an environment on our device where signal integrity can often be compromised. This can lead to shorter battery life, user feedback delay, and even critical data or system faults.
Let us test a few examples looking for issues in communication on our SPI peripheral bus. The SPI bus is a common communication protocol for accelerometers, GPS chips, and many other sensor and actuators. Continuously monitoring a design to make certain reliable communication will be maintained to quality standards is an important test technique for this type of product development. In these tests, we will provide several methods for verifying and comparing SPI communication that can be used iteratively as your design approaches completion.
First, there are several aspects of serial communication that can be commonly affected by connections, layout, and stress or other aspects of long term use. These include bandwidth, noise, and impedance. Again, our first goal is to establish both a goal and a baseline for these parameters. The first step is to monitor and verify these signals with the analogue channels of an oscilloscope as shown in Figure 1.
In this test we can see that our connections appear to have more than enough bandwidth but we can also see some crosstalk noise especially on the data and chip select lines. The green bus values are an internal decode of that signal by the scope. As long as these are stable for each transmission then the noise is likely acceptable. Since crosstalk is a common issue here it can be important to test the bus while other peripherals are being serviced and activated asynchronously. One methodology is to utilise a pass/fail mask, which we have implemented in Figure 2, looking for unacceptable noise levels in a large sequence of traces.

Figure 1: Basic SPI Analysis with analogue oscilloscope channels

Figure 2: Pass / Fail Analysis to highlight crosstalk on a communication bus

One advantage to this approach is that masks can easily be saved and reused on different board revisions or code revisions within a project. Simple tests can therefore help to quickly identify the version or build that first showed an increase in noise or change in performance. It is important to internalise that the opposite can be true as well. Device performance may be so reliable that different layouts or smaller wires for connections may be possible creating more freedom for the overall mechanical design.
When there are issues with bandwidth or signal levels impedance may ultimately be the culprit. High impedance probing is made to deliver maximum voltage to the scope, but many serial buses have characteristic impedance such as 50 Ohms. In these cases, a valuable test is to transmit signals directly into a 50 Ohm probe setting on the oscilloscope. This makes it possible to visualise what the 50 Ohm receiving end sees during a transmission. If the impedance of the cabling, connections, or transmitter is off then the amplitude may droop or square waves may be misshapen. Regardless of the impedance of your lines, there are RC components that affect the risetime and overshoot of the transitions. Selecting the wrong termination resistors for your bus can cause extraneous power drain or poor transmission settling. System bandwidth and line impedance issues can be caused by these resistances as well as excessive or unstable capacitance. Like noise, these symptoms usually indicate physical hardware issues beyond basic valid data transmissions. When significant data errors or bugs do come into play another verification method can be used. To get a clearer image of how our IoT platform is interpreting this data we can use our mixed signal channels for comparison.
The digital channels on the oscilloscope (shown on the bottom of Figure 3) can be set with threshold values that mimic the bus controller on the IoT platform.

Figure 3: Comparison with mixed signal channels for data interpretation

The device does not see the analogue signals, but interprets their digital equivalent. Therefore, when having data issues it is important to look at both the digital and analogue representation. This enables engineers to quickly discover where data failures are occurring as well as the analogue root cause or noise source that may be contributing.
Lastly, one important consideration when implementing sensors in an IoT device is the latency between bus communication and action. Of course, this is highly dependent on both the platform and the code methodology and can change dramatically. Latency is the time it takes for the system or platform to interpret the peripheral data and take an action. As a latency baseline we ran a simple test that toggles an LED when a SPI read is completed. The cursor measurements on Figure 4 highlight this.

Figure 4: Latency measurement from SPI bus to LED on our IoT development board

From this baseline on your platform you can model how code changes impacts this latency and then you can base decisions about servicing these sensors based on the balance of use case and reliability requirements with battery life and implementation.
Latency, noise, bandwidth, and impedance all effect signal integrity and reliability. These key measurement techniques can be used throughout development, use case, and reliability testing to optimise the overall design and anticipate failure modes. As part of an overall IoT design strategy, continuous evaluation of signal integrity established baselines and limits helps speed time to market and customer acceptance with small impact to equipment budgets.
Conclusions and Key Learnings
When working in the fast changing atmosphere of IoT design and development reliable test methodologies become increasingly important. As engineers integrate the newest sensors and platforms on the fly to reach highly competitive markets as fast as possible, understanding core customer requirements and trade-offs and how those can be evaluated and compared throughout the development is an important step toward improving the strategic design process.
Whether the challenges of an application are more form or function, issues related to signal integrity and reliability are fundamental elements of design in the IoT ecosystem that play a significant role in market success. Establishing these principles early in the process and testing them iteratively is one of the best ways to limit budget and schedule risks in the latter stages of the design. Modern, easy to use test equipment that is more affordable than ever can be utilised to develop the limits and baselines that will guide an engineering team through a successful product development.

Products Mentioned In This Article:

• DS1000Z Series please see HERE

Telonic Instruments Ltd would like to take this opportunity to update all of our customers regarding the current COVID-19 outbreak and what steps we are taking. We have put systems in place to continue business during the current crisis with orders being processed and shipped as usual on a daily basis with our normal courier service APC.

Current Operational Situation

We continue to monitor the developing situation extremely closely and are prioritising the health and safety of our staff and customers before anything else. We are doing everything we possibly can do to ensure the operational aspect of the business remains unaffected for as long as possible. To ensure this happens and to protect the health of our colleagues, our staff are working remotely where possible and where staff do have to come into our offices or warehouse we are exercising distancing measures to keep face to face interaction to an absolute minimum to protect them.

So far, these actions are working to keep all staff healthy and the day to day aspects of the business running as usual.

Ordering

We are still accepting orders from customers through email and by telephone, both our websites remain transactional 24 hours a day with orders being processed on the same working day.

Technical Support

Our technical support team is still fully operational but due to the current circumstances, some members of the team are now working remotely, however, we are still able to support you via the phone, WhatsApp or email.

Ongoing Situation

As the situation continues to evolve we would like to wish our customers the best of health and whatever adverse knock-on effects this may have to the UK economy that these are short-lived and operations return to normal for everyone in the shortest possible time frame.

Thank you for your continued support and business.

Stay Safe

Doug Lovell
Telonic Instruments Ltd