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\$
  • 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 Nov 25 '16 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 Nov 25 '16 at 9:23
  • \$\begingroup\$ So the scopes don't display the same signal source? \$\endgroup\$ – PlasmaHH Nov 25 '16 at 9:24
  • \$\begingroup\$ Same source. I carry the input device to both locations. \$\endgroup\$ – floppy380 Nov 25 '16 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 Nov 25 '16 at 9:34
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\$
  • \$\begingroup\$ Please see Edit 2 \$\endgroup\$ – floppy380 Nov 25 '16 at 12:41
  • \$\begingroup\$ "min and max values per sample". But isnt there only one sample value for each sample? \$\endgroup\$ – floppy380 Nov 25 '16 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 Nov 25 '16 at 13:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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