0
\$\begingroup\$

I'm using a Tektronix TDS 1002B oscilloscope. I was investigating some glitch issues on pulses/square-waves and decided to save the time-series data to a USB drive in CSV file format to plot in MATLAB.

Input to the scope is a square-wave or pulse.

When I set the scope's Acquire feature to 'Peak Detect' setting, and observe the signal on the scope's screen live I only see over-shootings at the rising edges but the pulse seems it has no glitches. But then I save this signal data(using Save feature) to a USB drive in CSV file format to plot in MATLAB.

In the following example, the input to the scope is a 50Hz 4Vpp square-wave.

When I set the Acquire to 'Peak Detect' and saved the data in CSV format, here is what I plot in MATLAB:

enter image description here

And here in the zoomed view I see glitch on each falling edge:

enter image description here

On the other hand, when I set the Acquire to 'Sample' and saved the data in CSV format, here is what I plot in MATLAB:

As you see the square-wave is clean and free of glitches:

enter image description here

I tested this measurement with different inputs I mean different function generators and pulse outputting devices at various frequencies. But I always see same type of glitch always on the falling edges when the Acquire is set to 'Peak Detect' and saved as in CSV format.

I made the same test with a chinese scope Siglent SDS1102CML and when I saved the data in Peak Detect mode I don't see any glitches.

What would the reason be for those glitches after each falling edge. Is that an oscilloccope error?

Edit:

Following PlasmaHH's advice I checked the measuremtns with more horizontal settings. When I decrease the division enough, at some point the saved data for falling edges are clean, glitches disappear.

When the horizontal is set to 50us here is the data saved:

enter image description here

And here is the zoomed view of a glitchy falling edge:

enter image description here

When the horizontal is set to 5us there is no glitch, here is the data saved:

enter image description here

When the horizontal is set to 250ns there is no glitch, here is the data saved:

enter image description here

Edit 2

Horizontal is set to 5ms per division. The input is 50Hz square wave.

Here are the results:

enter image description here

Each falling edge has glitch. And here is the zoomed view:

enter image description here

And here below is the data from CSV file where the first glitch occurs:

t = [-0.01006 -0.01004 -0.01002 -0.01 -0.00998 -0.00996 -0.00994 -0.00992 -0.0099 -0.00988 -0.00986 -0.00984 ];

V= [2.76 2.76 2.8 -2.72 2.76 -2.76 -2.68 -2.76 -2.68 -2.76 -2.68 -2.76 ]

plot(t,V)

\$\endgroup\$
9
  • 1
    \$\begingroup\$ It likely is just doing its job, you never tell us the details about the waveform and what settings (esp on the horizontal) you have your scope set to. \$\endgroup\$
    – PlasmaHH
    Commented Nov 25, 2016 at 8:55
  • \$\begingroup\$ @PlasmaHH Same issues on various horizontal settings any divisions I mean. But this is happening for all pulse like inputs from different devices. And after every falling edge. The other scope doesnt show any glitch with the same input. The only difference is the locations/places Of the scopes. They are 1km far way from each other. Can that be the EMI or some other noise interfering to falling edges? \$\endgroup\$
    – floppy380
    Commented Nov 25, 2016 at 9:23
  • \$\begingroup\$ So the scopes don't display the same signal source? \$\endgroup\$
    – PlasmaHH
    Commented Nov 25, 2016 at 9:24
  • \$\begingroup\$ Same source. I carry the input device to both locations. \$\endgroup\$
    – floppy380
    Commented Nov 25, 2016 at 9:27
  • \$\begingroup\$ There are so many variables to measuring and so many things that can go wrong. How are they connected? directly BNC? terminated? scope probes? What signal sources have you tried, a known good function generator? how fast are the edges? Can you test those signal sources that exhibit the behaviour on high end scopes? The same model scope elsewhere? The question really is whether the glitch is there or an artifact. We could make an educated guess, but I personally prefer looking at all facts before telling that an old scope is buggy \$\endgroup\$
    – PlasmaHH
    Commented Nov 25, 2016 at 9:34

1 Answer 1

Reset to default
1
\$\begingroup\$

It seems that this scope saves the min and max values per sample when in peak detect mode, as long as the sample rate is not at the maximum setting (one of the main features of peak detect mode, you get the extremes during the sampling period).

Ordering it this way in the csv file will make it seem to jump back and forth, but if you sort it again the other way round, then you will notice that for your falling edge it will look like a falling edge over a few samples, but then again it will look like these glitches on the rising edge.

To properly plot it, I think you want to take every other value and plot one as min, the other as max.

\$\endgroup\$
3
  • \$\begingroup\$ Please see Edit 2 \$\endgroup\$
    – floppy380
    Commented Nov 25, 2016 at 12:41
  • \$\begingroup\$ "min and max values per sample". But isnt there only one sample value for each sample? \$\endgroup\$
    – floppy380
    Commented Nov 25, 2016 at 12:55
  • \$\begingroup\$ @doncarlos: over the time tek has done different ways of saving csv data, usually with peak detect having two values, either min/max or "normal and peak" (whatever that is supposed to mean). That is exactly the purpose of peak detect in most scopes: oversample and display the most extremes. \$\endgroup\$
    – PlasmaHH
    Commented Nov 25, 2016 at 13:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.