Why use less than full memory depth on a Rigol DS1054Z oscilloscope?

[cjs]

I have a Rigol DS1054Z, which has 24/12/6 Mpoints of sample memory per channel, depending on if you have 1, 2 or 3-4 channels enabled. The `Acquire » Mem Depth` option lets me set the buffer size, or "depth" as they seem to call it, to 3k, 30k, 3M or 6M samples. (Those figures are multiplied by 2 or 4 if only 2 or 1 channels are enabled). It also has an `Auto` option that will simply use whatever depth is necessary for the time period shown on the screen at the maximum sample rate available. (In all cases it will automatically reduce the sample rate if the specified depth is too small to hold the screen period at maximum sample rate.)

So what is the point of this option? I.e., under what circumstances would you ever want to use less than the maximum depth? Having more samples stored than can fit on your screen seems harmless, in theory, since you're not forced to use them. (For example, zoom still operates only on samples displayed on the screen, and dumping the data to a CSV file dumps only the screen samples, not the entire sample buffer, unless you change that setting from the default.)

Does it perhaps slow down the 'scope or something like that? I didn't notice any slowdown when I was mucking about looking at some old video signals with two channels running.

[2N3055]

I have a Rigol DS1054Z, which has 24/12/6 Mpoints of sample memory per channel, depending on if you have 1, 2 or 3-4 channels enabled. The `Acquire » Mem Depth` option lets me set the buffer size, or "depth" as they seem to call it, to 3k, 30k, 3M or 6M samples. (Those figures are multiplied by 2 or 4 if only 2 or 1 channels are enabled). It also has an `Auto` option that will simply use whatever depth is necessary for the time period shown on the screen at the maximum sample rate available. (In all cases it will automatically reduce the sample rate if the specified depth is too small to hold the screen period at maximum sample rate.)

So what is the point of this option? I.e., under what circumstances would you ever want to use less than the maximum depth? Having more samples stored than can fit on your screen seems harmless, in theory, since you're not forced to use them. (For example, zoom still operates only on samples displayed on the screen, and dumping the data to a CSV file dumps only the screen samples, not the entire sample buffer, unless you change that setting from the default.)

Does it perhaps slow down the 'scope or something like that? I didn't notice any slowdown when I was mucking about looking at some old video signals with two channels running.

Of course it slows down the scope. Even if you set it to capture at 10ns/div (total of 120ns per screen, 120 sample point visible), you will have to wait for it to capture rest of 23999880 point after what you see on the screen, before it can retrigger.. That's 24 ms (0.024 s). That is 41.6 triggers per second and huge blind time. This way you guarantee blind time of 0,02399988 sec for every 120ns of usable capture.

If you are doing something interactive and you want scope's display to behave like analog scope would, you would set it to Auto. And should keep it at Auto most of the time. Unless you want deliberately to capture full buffer all the time and fast triggering is not a problem for you.
In which case you set it that way.

Even simple scopes like  DS1054Z are very complicated and there are no set rules that something should be done only one way. That is the beauty of scope, it is so versatile it can do many things... But that requires being able to work with settings to achieve the goal..

[Fungus]

It can slow down a LOT if you badly mismatch sample rate and memory depth.

[cjs]

Even if you set it to capture at 10ns/div (total of 120ns per screen, 120 sample point visible), you will have to wait for it to capture rest of 23999880 point after what you see on the screen, before it can retrigger.. That's 24 ms (0.024 s). That is 41.6 triggers per second and huge blind time. This way you guarantee blind time of 0,02399988 sec for every 120ns of usable capture.

Ok, I'd not really thought through the implications a larger sample buffer would have on retriggering, so this is starting to make some sense to me.

But while I can see that a large blind time on a human scale would mean that the display would not update for changes (e.g., if you're capturing 500 ms of data in the buffer and something in the waveform changes every 250 ms you might see a static waveform on the screen rather than see that section of the waveform "blinking"), I find it difficult to see why a 20 ms. blind time is an issue, since it seems that would update too fast to see. Or is that captured by the brightness gradations, which might not appear if the part of the signal that would produce a lower brightness gradation is always later in the buffer, off the screen?

If you are doing something interactive and you want scope's display to behave like analog scope would, you would set it to Auto. And should keep it at Auto most of the time. Unless you want deliberately to capture full buffer all the time and fast triggering is not a problem for you.

Right. So generally using `Auto` unless you have a specific reason not to do so makes sense to me, but this question was triggered by Rigol's video "Using Video Triggering." (I'm currently doing some analysis of the pseudo-NTSC 240p signals produced by old 8-bit computers), where they start out by suggesting you set depth to maximum instead of using the default `Auto`. It now sounds to me as if there's not much point to this unless they're expecting you to stop the capture and then start comparing frames to each other. What am I missing here?

Here's the video link. Sorry about the large, useless image, but I can't figure out how to stop the forum from including this in my post.

[David Hess]

Ok, I'd not really thought through the implications a larger sample buffer would have on retriggering, so this is starting to make some sense to me.

It does both; a long record length slows performance and increases trigger rearm time.  Some DSOs support a segmented record to decrease trigger rearm time and increase acquisition rate.

A long record can be advantageous for automatic measurements and decoding, but the Rigol DS1000Z series does these things on the display record.

[Fungus]

if you have 24Mb of memory and 250k samples/sec then it takes 100 seconds to fill the memory (more or less). That's 100 seconds between sweeps, 100 seconds between triggers.

I don't remember how low it goes, exactly, but it's a lower then 250k samples/sec.

You really wouldn't want to use full memory depth down there...

[vk6zgo]

if you have 24Mb of memory and 250k samples/sec then it takes 100 seconds to fill the memory (more or less). That's 100 seconds between sweeps, 100 seconds between triggers.

I don't remember how low it goes, exactly, but it's a lower then 250k samples/sec.

You really wouldn't want to use full memory depth down there...

If you have 250k  samples/sec don't even fantasise about looking at video signals.
An analog composite video signal at field rate has frequency components from 50Hz/60Hz up to around 5MHz, so at the above rate, you will just get a mess of aliased crap.

Your sampling rate has to be around 20M samples/second to get a useable display.
To fill a screen with one field of video, over a 20ms period requires 400k samples of memory.

This is why, when Tek & HP salesmen tried to sell early DSOs with tiny memories to TV Studios, they went away disappointed.
To make it even harder, we usually liked to display two fields.
Most of the old DSOs couldn't even cope at line rate!

The display on the linked video is really pretty poor----I'm sure I've seen better screenshots of video signals where the user had a DS1054Z.
Maybe it is the moving image---- the video component looks like it is continually drifting w.r.t. the syncs--- a most disturbing illusion!

On an analog 'scope, the signals stay synced, with the video signal just changing in amplitude & frequency
components.lo

PS. It just dawned on me what the problem with the linked video is.

It isn't a failing of the Oscilloscope, but rather, of the person producing the video.

They almost certainly didn't have a source of composite video, but did have one for composite syncs & blanking.
They happily added a non- synched signal from a sig generator & "called it good"!

I do remember seeing a very similar effect many years ago, when we were trying to check our BW Transmitters prior to colour mods, but didn't yet have any proper PAL generators.
We just added a 4.433MHz sine wave to a source of blanking & syncs, & the "video" drifted w.r.t. syncs in exactly the same way.

[2N3055]

Why did you connect 250kS/s with video signal?

DS1054Z has 24 Ms so can sample 24 ms with full 1 GS/s, or 48 ms with 500 MS/s.
So more than plenty to capture one full frame at super high sample rate...

[vk6zgo]

Why did you connect 250kS/s with video signal?

DS1054Z has 24 Ms so can sample 24 ms with full 1 GS/s, or 48 ms with 500 MS/s.
So more than plenty to capture one full frame at super high sample rate...

Because the original question from cjs was connected with his efforts to display composite video.
Fungus mentioned  250kS/s, so I wanted the OP to understand that simple time/div isn't the most important thing with complex signals of this type.

I should really have addressed the answer to cjs.

[2N3055]

OP original question was not about Video.. that was mentioned later as a refrence to something mentioned in video..
But whole post is confusing I agree..