DSO sampling rate at slow time bases

[jpb]

This post is prompted by some discussion on another thread where the question was asked: what is your scope's sample rate at 50msec/div timebase?

The straight forward answer in my case, where my scope has 500k memory per channel, is 1MS/sec giving a nominal bandwidth of 500kHz.

But then it struck me that my scope only displays 500 points on the screen (if persistence mode is turned off) and I realised that I don't know how it selects those 500 points from the 500k it has sampled. If, as I suspect is the case, it just selects from the samples then the effective sampling rate is a 1000 times worse at only 1kS/sec with an effective bandwidth of only 500Hz! (I'm assuming that peak detect is not being used either.)

If this is the case then if you don't use persistence mode or peak detect the fact that extensive memory allows fast sampling will not protect you from seeing aliasing effects on the screen.

Given the drive for high waveforms per second rates I would have thought that only one point per horizontal pixel is used; so are the samples sampled for display?
Or do scopes average in some way every 1000 stored samples to produce one displayed sample - I suspect that they don't because it would introduce an overhead and slowdown the display rate.


EDIT : I think my post above is based on the false premise that my scope only plots 500 points because there are only 500 pixels.

[KedasProbe]

Maybe you first have to ask yourself what you would ideally like to see on an 0.5sec wide screen of 10 cm. (assume infinite display pixels for a moment)

[cyr]

A good scope will show you all the information it has captured, that means using all points from every waveform it has captured since it last refreshed the screen. Intensity grading will show how many samples have been captured that fall on/near a particular pixel on screen.

If your scope is a "good" scope according to that definition I have no idea

[jpb]

A good scope will show you all the information it has captured, that means using all points from every waveform it has captured since it last refreshed the screen. Intensity grading will show how many samples have been captured that fall on/near a particular pixel on screen.

If your scope is a "good" scope according to that definition I have no idea

Yes, I think that you are right and my scope plots many more than 500 points (it has a gradient display).

In fact I decided I'd been slightly silly and tried to delete my original post but as I was the OP I wasn't allowed to!

[KedasProbe]

My point was that your eyes can't see that high resolution on your screen.
Assume you have a screen with an extreme high resolution 2400DPI (the 'Retina display' from apple is about 8 times lower) beyond that your eyes will just see grey.

Example: 2400DPI or about 4*2400 pixels= 9600 pixels on 10cm/0.5sec
0.5sec/9600 or about 0.05ms per pixel, for a square wave you need 2 pixels: period=0.1ms or 10kHz, so still much below your sample rate.

Or with other words your eyes are the limited factor, an infinite DPI can't help, that's why you have to stretch it out and trigger on the part you want to see.

But that doesn't really answer your question "which samples do you see".
Ideally if a spike is present you want to see it even if it is much smaller than 1 pixel. (like 200 times smaller)
Knowing that 1 pixel will be much too wide to represent the spike.
So will it?

I wasn't 100% sure what my scope would do so I did the test to see if my scope would show it.
So on the 50ms/div scale or 1 pixel/ms, 500KS/s (sample every 2µs)
I provided an 5µs wide pulse every 50ms.
As you see below, the scope is showing it without problem.
(I also tried 2 short pulses right after each other, the brightness of the spike went up, 3 spikes a little bit more bright etc.)

So no you don't see all samples and no they are not averaged and you also don't miss anything important on the screen, the 500 samples for each pixel are processes and something 'appropriate' is displayed. But obviously you need to zoom in to really see it.

On the next screen-shot you see the same but I reduced the pulse width to 1µs this is below the sample rate time and you see it's starting to show wrong measurements as expected.
Edit: the interruption in the noise line is the update position of the scope.

[marmad]

This post is prompted by some discussion on another thread where the question was asked: what is your scope's sample rate at 50msec/div timebase?

The straight forward answer in my case, where my scope has 500k memory per channel, is 1MS/sec giving a nominal bandwidth of 500kHz.

But then it struck me that my scope only displays 500 points on the screen (if persistence mode is turned off) and I realised that I don't know how it selects those 500 points from the 500k it has sampled. If, as I suspect is the case, it just selects from the samples then the effective sampling rate is a 1000 times worse at only 1kS/sec with an effective bandwidth of only 500Hz! (I'm assuming that peak detect is not being used either.)

If this is the case then if you don't use persistence mode or peak detect the fact that extensive memory allows fast sampling will not protect you from seeing aliasing effects on the screen.

Given the drive for high waveforms per second rates I would have thought that only one point per horizontal pixel is used; so are the samples sampled for display?
Or do scopes average in some way every 1000 stored samples to produce one displayed sample - I suspect that they don't because it would introduce an overhead and slowdown the display rate.

It's true that on some scopes, only every n-th data point is displayed: the DSO just uses decimation (throwing out) of the unneeded sample points. This technique allows the fastest waveform update rates, but as the display data is decimated, important signal details can be lost, because (as you pointed out) the sample rate is effectively reduced.

A much better way is to do a peak to peak assessment: if a number of samples occur within one pixel of the display, then the extreme values are displayed vertically and joined together; then all of the samples per pixel are visible. This, of course, requires more processing - so slower wfrm/s rates.

One other thing I might point out in this discussion that is relevant - but not understood by some DSO users: deep memory is not just important in SINGLE SHOT mode; it has a direct and important impact on running the scope in NORMAL mode (at slower time base settings) = because the memory length determines the sampling rate.

Look at the two attached images showing the exact same signal at 50ms/div: the first with sample length set to 14k, so the rate is 20kSa/s (thus missing some of the 20us spikes); the second with sample length set to 56MB, so the rate is 50MSa/s.

[Hydrawerk]

Here it's useful to have a scope with large memory. Agilent with 100kpoints per channel is not ideal. 

[marmad]

Given the drive for high waveforms per second rates I would have thought that only one point per horizontal pixel is used; so are the samples sampled for display?
Or do scopes average in some way every 1000 stored samples to produce one displayed sample - I suspect that they don't because it would introduce an overhead and slowdown the display rate.

A diagram showing the two different methods adopted by DSO manufacturers for reducing/displaying extra samples per pixel point:

[Someone]

Use a tool wrong and of course it gets the wrong answers, here are the pulse widths where the signal stops being reliably visible for a range of scopes when set to 40-50 ms/division.

Scope	Mode	Pulse Width	Sample Rate
Tektronix 7834		200nS
Tektronix 2430A	Normal	1ms
Tektronix 2430A	Envelope	<10ns
Tektronix TDS3014B	Normal	40us	25kSa/s
Tektronix TDS3014B	Peak	<10ns	25kSa/s
Lecroy 324	Normal	1us	1MSa/s
Lecroy 324	Peak	<10ns	1MSa/s
Agilent MSOX3104A	Normal	800ns	2MSa/s
Agilent MSOX3104A	Peak	<10ns	500kSa/s
Tektronix MSO4054	Normal	40ns	25MSa/s
Tektronix MSO4054	Envelope or Peak	<10ns	25MSa/s

All scopes were set for their maximum memory depth. The width they will catch is a function of the sample rate achievable (which is dominated by the memory capacity), but even the historic Tektronix scope will still catch it at any setting when you enable the peak/envelope acquisition mode.

As to the change in point memory when switching to peak mode, only the Agilent X series dropped its acquisition rate. They use 4 times the memory to store min/max data rather than the expected 2 times (some peculiarity of the asic? http://www.home.agilent.com/owc_discussions/thread.jspa?threadID=17257&tstart=825), which raises the question how do other scopes maintain the memory depth between sampling and peak/envelope modes?

[jpb]

As to the change in point memory when switching to peak mode, only the Agilent X series dropped its acquisition rate. They use 4 times the memory to store min/max data rather than the expected 2 times (some peculiarity of the asic? http://www.home.agilent.com/owc_discussions/thread.jspa?threadID=17257&tstart=825), which raises the question how do other scopes maintain the memory depth between sampling and peak/envelope modes?

On my scope, the LeCroy (Iwatsu) WaveJet it defines peak mode as being the maximum and minimum values in twice the sampling interval so the number of points per sampling interval remains at 1 so no extra memory is required but of course more processing. I think this is a fairly standard way of doing it.

The question this doesn't answer is what time values are assigned to each? In normal mode the samples are at fixed whole time steps, in peak mode the maximum and minimum will be at arbitrary values within the two time steps so are they simply ordered in time and then the earlier one assigned to the first time step and the later one to the second time step or is some attempt made to assign them to their correct times (eg if both actually occur in the second time step)?

[jpb]

I wasn't 100% sure what my scope would do so I did the test to see if my scope would show it.
So on the 50ms/div scale or 1 pixel/ms, 500KS/s (sample every 2µs)
I provided an 5µs wide pulse every 50ms.
As you see below, the scope is showing it without problem.
(I also tried 2 short pulses right after each other, the brightness of the spike went up, 3 spikes a little bit more bright etc.)

So no you don't see all samples and no they are not averaged and you also don't miss anything important on the screen, the 500 samples for each pixel are processes and something 'appropriate' is displayed. But obviously you need to zoom in to really see it.

On the next screen-shot you see the same but I reduced the pulse width to 1µs this is below the sample rate time and you see it's starting to show wrong measurements as expected.
Edit: the interruption in the noise line is the update position of the scope.

Presumably this was in normal sampling mode rather than peak mode? In peak mode I presume it would show all the spikes even at the lower memory depth?

[marmad]

Use a tool wrong and of course it gets the wrong answers, here are the pulse widths where the signal stops being reliably visible for a range of scopes when set to 40-50 ms/division.

Who exactly are you responding to? I thought the thread was about what DSOs do with extra samples per pixel point - not about what pulse widths are visible at any particular time base setting.

[Wuerstchenhund]

A diagram showing the two different methods adopted by DSO manufacturers for reducing/displaying extra samples per pixel point:
[/img]

The right diagram is not fully correct. It says all data points are displayed, but that is strictly only true for the example waveform, but not necessarily the case with all waveforms. Peak-to-Peak (as the name implies) is quite similar to Peak Detect mode, it takes the extrema of n number of samples and uses them as display points. This generally produces a much better replication of the original waveform, but it still means that data points are thrown away.

There's also a third method (Binning) which really ensures that any data point ends up on the display and no information is lost. It's much slower, and thus doesn't provide the high waveform rates that nowadays people want to see.

Most low end scopes use Decimation, and most better scopes (midrange/highend) use Peak-to-Peak. Some newer high end scopes and even older LeCroy scopes (9300/LC/Waverunner LT/WavePro 900) use Binning.

[marmad]

The right diagram is not fully correct. It says all data points are displayed, but that is strictly only true for the example waveform, but not necessarily the case with all waveforms. Peak-to-Peak (as the name implies) is quite similar to Peak Detect mode, it takes the extrema of n number of samples and uses them as display points. This generally produces a much better replication of the original waveform, but it still means that data points are thrown away.

But if all data points are being mapped to the same vertical line of pixels (which they must be) - and if the minimum and maximum data points are connected by a vertical line - how are possible data points in-between visibly lost? Where would they be shown otherwise?   

BTW, the diagram is from some Yokogawa literature.

[Wuerstchenhund]

But if all data points are being mapped to the same vertical line of pixels (which they must be) - and if the minimum and maximum data points are connected by a vertical line - how are possible data points in-between visibly lost? Where would they be shown otherwise?

The thing is that Peak-to-Peak only considers the Extrema, and throws away the points in between. They are lost.

To give you a (very simple!) example:

Say we have the following data points:

+2

|

+2.3

|

+2.6

|

-4

|

-2.8

|

-1.3

|

-0.5

|

+3

Now we take the Extrema which are '-4' and '+3'. These two data points are now used to build the next display point (there are several methods to do that, which for that example don't matter).

Now lets look at a second sample set:

+2.8

|

+2.7

|

+1.8

|

-2.4

|

-4

|

-0.5

|

+1.5

|

+3

Again we take the Extrema which are still '-4' and '+3', which would result in the same display point. But if you actually plot both data sets you'll see that the underlying waveform is completely different. But with Peak-to-Peak this information is lost.

BTW, the diagram is from some Yokogawa literature.

It's a good diagram (despite this small error) and shows the general difference between the two most used methods to create display points. But it's probably a bit biased in the method I guess Yokogawa wants to promote (probably similar to looking for information on the relevance of waform rates in Agilent literature).

[Yaksaredabomb]

....Where would they be shown otherwise?

....
Again we take the Extrema which are still '-4' and '+3', which would result in the same display point. But if you actually plot both data sets you'll see that the underlying waveform is completely different. But with Peak-to-Peak this information is lost....

I'm not sure you really answered Marmad's question.  I understand what information is lost with peak detect, but not how "binning" would show anything additional.  There is only 1 pixel column with which to represent all the samples.
 
I suppose intensity grading could be used.  For instance, for the data (-4,-4,-2,-2,4,4,4) peak detect would show a plain vertical pixel line from -4 to 4.  But for peak detect with grading the line would be brighter at -4, -2, and 4 than the points in between (with the line being brightest by 4).
 
That's just something I came up with off the top of my head - no clue if any scopes really do this or if it would be of any real benefit.  Just trying to brainstorm how you can display more information in a single pixel width.

[marmad]

Peak-to-Peak (as the name implies) is quite similar to Peak Detect mode, it takes the extrema of n number of samples and uses them as display points. This generally produces a much better replication of the original waveform, but it still means that data points are thrown away.

I don't think this is correct.

Peak-to-Peak is just compression from the sample data to the display data in Normal mode: all samples gathered within the period of time represented by one screen pixel are reduced to a single vertical line of pixels. Nothing is lost from what is sampled - if I stop the DSO and 'zoom' in, all of the original sampled data should still be visible at it's correct position in time (but the DSO will have missed any pulses smaller than the original sample rate).

Peak Detect mode is optimization at slower sampling rates, allowing the capture and display of pulses smaller than the 'given' sample rate (determined by initial time base and sample length). But if I stop the DSO and 'zoom' in, the sampled points/positions are not necessarily 'true'.

[marmad]

I'm not sure you really answered Marmad's question.  I understand what information is lost with peak detect, but not how "binning" would show anything additional.  There is only 1 pixel column with which to represent all the samples.
 
I suppose intensity grading could be used.  For instance, for the data (-4,-4,-2,-2,4,4,4) peak detect would show a plain vertical pixel line from -4 to 4.  But for peak detect with grading the line would be brighter at -4, -2, and 4 than the points in between (with the line being brightest by 4).
 
That's just something I came up with off the top of my head - no clue if any scopes really do this or if it would be of any real benefit.  Just trying to brainstorm how you can display more information in a single pixel width.

Yes, I think you're correct - the only way to show more information in a single pixel line is with an added 'dimension' - in this case, with a gradient.

[jpb]

Peak-to-Peak (as the name implies) is quite similar to Peak Detect mode, it takes the extrema of n number of samples and uses them as display points. This generally produces a much better replication of the original waveform, but it still means that data points are thrown away.

I don't think this is correct.

Peak-to-Peak is just compression from the sample data to the display data: all samples gathered within the period of time represented by one screen pixel are reduced to a single vertical line of pixels. Nothing is lost from what is sampled - if I stop the DSO and 'zoom' in, all of the original sampled data should still be visible at it's correct position in time (but the DSO will have missed any pulses smaller than the original sample rate).

Peak Detect mode is optimization at slower sampling rates, allowing the capture and display of pulses smaller than the 'given' sample rate (determined by initial time base and sample length). But if I stop the DSO and 'zoom' in, the sampled points/positions are not necessarily 'true'.

My understanding from what I've read is that data is lost in the sense that only the minimum and maximum points in twice the sample interval are retained. But the sample interval itself may be a lot smaller than one pixel width.

For example, on my WaveJet the sample memory is 500k points and the screen width is 500 pixels, at a time base of 50msec/div or 500msec per screen even if I set the memory to the maximum 500k the sample interval will be 1 microsecond. With peak detect it will sample at 1nsec intervals for 2 microseconds and pick the maximum and minimum points so it will retain only 2 out of 2000 points. Each pixel width is 1msec so is a 1000 of the 1microsec sample steps so you could still do a lot of zooming.

[marmad]

My understanding from what I've read is that data is lost in the sense that only the minimum and maximum points in twice the sample interval are retained. But the sample interval itself may be a lot smaller than one pixel width.

Yes, but again, there is a definite distinction between using Peak-to-Peak to just compress sample data to display data in Normal mode - and using Peak Detect mode to optimize the display.

As per my other post, two images showing the DSO zoomed into the same signal in Normal and Peak Detect mode:

[Wuerstchenhund]

I don't think this is correct.

I'm pretty sure this is correct. Peak-to-Peak was never about retaining all data points.

Peak-to-Peak is just compression from the sample data to the display data: all samples gathered within the period of time represented by one screen pixel are reduced to a single vertical line of pixels.

This is not what peak-to-peak does (unless Yokogawa came up with a variant of their using under this term, which is not impossible of course). Peak-to-Peak is about data reduction, i.e. one method (which I guess is what Yokogawa is using) by taking the Extrema and drawing vertical a line between them. This however only describes the range in which the thrown away sampling points must be located (they can't be bigger or smaller than the Extrema), but this method does no weighting (i.e. in which area are most of the data points), and in the end looses a lot of information.

Nothing is lost from what is sampled - if I stop the DSO and 'zoom' in, all of the original sampled data should still be visible at it's correct position in time.

Try it, you will find that it's gone. And even if Peak-to-Peak would work as you believe it does, you would still use the time information as to where the individual data points had been located in time. But this information would be required to 'restore' the full set of information.

Peak Detect mode is optimization at slower sampling rates, allowing the capture and display of pulses smaller than the 'given' sample rate (determined by initial time base and sample length). But if I stop the DSO and 'zoom' in, the sampled points/positions are not necessarily 'true'.

Right, but the same principle is used by Peak-to-Peak.

[jpb]

My understanding from what I've read is that data is lost in the sense that only the minimum and maximum points in twice the sample interval are retained. But the sample interval itself may be a lot smaller than one pixel width.

Yes, but again, there is a definite distinction between using Peak-to-Peak to just compress sample data to display data in Normal mode - and using Peak Detect mode to optimize the display.

As per my other post, two images showing the DSO zoomed into the same signal in Normal and Peak Detect mode:

Your screen grabs are instructive. I assume that it is meant to be a single spike (or narrow pulse) and it can be seen that the peak-detect has inserted a minimum point in the middle of it which shows that it has shifted the minimum point in time. This implies that for the Rigol at least the minimum and maximum points are saved in a fixed order regardless of which actually occurred first.

But I don't think peak-to-peak is any different (I don't know because it is not a mode that I have on my scope).

I unfortunately don't yet have a function generator so can't repeat your experiment on the WaveJet to see if it orders the points better.

The lesson I guess is that peak-detect is designed to do that, that is detect glitches. If you need to zoom in on them you probably need to re-trigger at a faster timebase.

[marmad]

Try it, you will find that it's gone. And even if Peak-to-Peak would work as you believe it does, you would still use the time information as to where the individual data points had been located in time. But this information would be required to 'restore' the full set of information.

Of course it's there! We seem to be having a misunderstanding here: a mix-up between how a DSO converts it's sample memory to it's display memory in Normal mode - and then other acquisition modes; these are two distinct and different things.

If my sample length is 14k @ 50ms/div, the sample rate of my DSO is 20kSa/s - or 50us per sample. OTOH, my waveform display area is 700 pixels wide - which means that each pixel is equivalent to 20 samples - which can be reduced by either decimation OR peak-to-peak - binning makes no sense in this regard (except perhaps if taking a third dimension [grading] into consideration). But if I stop my DSO, I can zoom and SEE the samples at 50us spacing - so nothing has been lost.

Now I have no knowledge of which technique my Rigol uses for reducing sample data to display data - but I suspect, due to it's low cost, that it's likely decimation. But I'll have to think up an experiment to try to capture it.

[marmad]

Your screen grabs are instructive. I assume that it is meant to be a single spike (or narrow pulse) and it can be seen that the peak-detect has inserted a minimum point in the middle of it which shows that it has shifted the minimum point in time. This implies that for the Rigol at least the minimum and maximum points are saved in a fixed order regardless of which actually occurred first.

Yes - exactly.

But I don't think peak-to-peak is any different (I don't know because it is not a mode that I have on my scope).

Again, this is NOT a switchable mode - it's just a technique your DSO might use to solve the problem you posted in your original post: how to reduce many samples to a single vertical line of pixels for display while in Normal acquisition mode?

[marmad]

Ok, I did some experimentation using an AWG file of three consecutive short pulses with increasingly higher voltages - with the DSO triggering on the second of the three pulses.

It appears the Rigol DS2000 does Peak-to-Peak conversion from sample to display memory in Normal mode, since if it only displayed every 20th point (using decimation), you wouldn't see the amplitude of the third pulse when looking at the display at the 100ms/div setting.

The attached images show 100ms/div and 200us/div displays of Normal mode (@ both 14k and 56Mpts sample lengths) and 100ms/div and 200us/div of Peak Detect mode @ 14kpts.

As mentioned above, Peak Detect is a different mode of acquisition - I've included it just to show that it can affect the contents of sample memory (as shown at 200us/div) - while Peak-to-Peak in Normal mode does not.

Edit: I've attached the 4000pt. ARB Express .CSV file (zipped), if anyone else wants to try this.