Rigol DS1052E sample rate vs. timebase setting

[number7]

Hello,

while testing my brand new DS1052E (HW58, FW 2.06.00.01, no hacks),
I came across a strange effect:
In timebase setting 50ms/div the screen refresh rate is about once a second.
This is almost the same for 10ms/div, but with 20ms/div it takes about 2s!
Since refresh rate should mainly depend on sample rate and memory depth,
I checked the refresh rates for all timebase settings (see attached pdf).
I would have expected that sample rate increases steadily with decreasing timebase.
This is also true for 50s/div down to 50ms/div with a maximum of 27.31kSa.
But at 20ms/div the sample rate dramatically decreases down to only 10kSa!
Well, it's not really a big thing, but it's annoying to wait 2s for the screen to refresh ;-)

Does this apply also to FW versions prior to 2.06?
Is there a special reason for this, is it a bug or is it just like it is...?
Another DSO (Agilent 300MHz 2GSa) behaves like I would expect:
Steadily increasing sample rate... OK... with some hold on for several timebase
settings, but never decreasing.

Regards,
number7

[Graham1904]

I have just purchased my DS-1052E and, reading your post to check and using the probe cal waveform as a reference, find that the screen refreshes at 0.5 sec at 50mS/div and at 20mS/div the refresh is not noticeable. My firmware is also 2.06

[vk6zgo]

I don't own a Rigol,or indeed any DSO,but it was my impression that the DS-1052 maintained a higher sample rate than that shown in the PDF, at around 10 & 20ms/div.

This was a major downfall of early DSOs.
In order to compensate for very poor memory depth,they reduced the sample rate radically at long duration time/div settings.
A classic test was to try to look at a video field of PAL(at 20ms/div) or NTSC (at approx 16ms/div) .
If the the sample rate was too low,aliasing of video & line sync information would result in a completely unusable
display.

 PS:Thinking about it,you would normally use 4 div at 5ms/div,so the Rigol wouldn't have any problems with line rate info as the sample rate would be 50kS/s,or you could use 2ms/div,which would give you sample rate of 100kS/s,but give you a fairly small image.(thinking backward--it would be a larger image)
You would still get aliasing from the video info (at up to 5MHz),but the field syncs should be viewable.

[number7]

Oh... thanks for your posts!
I did not expect any answers after almost 4 month any more ;-)

@Graham1904
Just out of curiosity, could you post your sampling rates for 10/20/50ms/div
(Readings in horizontal menu).
Here's mine:

Timebase  |   Normal       |   Long Mem
-------------------------------------------------
50ms/div  |    27,31kSa   |   1,748MSa
20ms/div  |    10kSa        |   1MSa
10ms/div  |    25kSa        |   2MSa


@vk6zgo
Maybe you had in mind the higher sampling rates in Long Mem mode?!

[vk6zgo]

Oh... thanks for your posts!
I did not expect any answers after almost 4 month any more ;-)

@Graham1904
Just out of curiosity, could you post your sampling rates for 10/20/50ms/div
(Readings in horizontal menu).
Here's mine:

Timebase  |   Normal       |   Long Mem
-------------------------------------------------
50ms/div  |    27,31kSa   |   1,748MSa
20ms/div  |    10kSa        |   1MSa
10ms/div  |    25kSa        |   2MSa


@vk6zgo
Maybe you had in mind the higher sampling rates in Long Mem mode?!

As I said,I don't have a DSO,but it surprises me that the sample rate would increase in the Long Mem
mode---total number of samples, maybe.
If you could sample at that rate,why not all the time?

[alm]

Sweep speed is time per division. Long mem has more samples per division, hence a higher sampling rate. Memory is 16 kpts in normal mode and 1 Mpts in long memory mode, so you would expect a 64 times difference in sampling rate. There is apparently some rounding going on (64 * 10 kSa/s = 640 kSa/s, not 1 MSa/s). In normal memory mode it would be unable to capture 10 divs worth of information at the higher sampling rates.

[number7]

As I said,I don't have a DSO,but it surprises me that the sample rate would increase in the Long Mem
mode---total number of samples, maybe.
If you could sample at that rate,why not all the time?

Why should sample rate not increase in Long Mem mode?
In normal mode sampling buffer is 16k, filled with sampling rate of 10kSa/s (at 20ms/div) takes 1,6s.
With Long Mem sampling buffer is 1M. With only 10kSa/s it would take more than 10s to fill the buffer and to update the screen!
Therefore sampling rate increases to 1MSa/s, which takes roughly 1s.

Of course I could always use Long Mem, but the effect (and my question why?) remains the same:
From 50s/div down to 50ms/div sampling rate steadily increases and then drops dramatically at 20ms/div.
With timebase settings smaller than 20ms/div sampling rate steadily increases again.

Although I'm aware of the fact that Long Mem option makes sense in some situations,
I try to use Normal mode in most cases, because the response in screen display is much faster e.g when zooming or horizontal scrolling!

[vk6zgo]

As I said,I don't have a DSO,but it surprises me that the sample rate would increase in the Long Mem
mode---total number of samples, maybe.
If you could sample at that rate,why not all the time?

Why should sample rate not increase in Long Mem mode?
In normal mode sampling buffer is 16k, filled with sampling rate of 10kSa/s (at 20ms/div) takes 1,6s.
With Long Mem sampling buffer is 1M. With only 10kSa/s it would take more than 10s to fill the buffer and to update the screen!
Therefore sampling rate increases to 1MSa/s, which takes roughly 1s.

Of course I could always use Long Mem, but the effect (and my question why?) remains the same:
From 50s/div down to 50ms/div sampling rate steadily increases and then drops dramatically at 20ms/div.
With timebase settings smaller than 20ms/div sampling rate steadily increases again.

Although I'm aware of the fact that Long Mem option makes sense in some situations,
I try to use Normal mode in most cases, because the response in screen display is much faster e.g when zooming or horizontal scrolling!

My main "beef" with DSOs has been that lack of memory depth led to insufficient sample rates at low "sweep speeds".
This makes it difficult to look at "complex" signals,such as analog video,or even fast pulse trains,using 20ms/div or similar, if troubleshooting for the presence of mains hum.

My attitude has always been,"The more samples the better".

What I had not considered till now,is the impact that "more samples" has on the display system,which has to present more data.(hence my highlighting of your last sentence).

Looking back to my original comments,& your reply:

Not being familiar with more modern DSOs,I wrongly assumed that the normal sample rate had been increased to get around the low sweep rate problem I referred to above,& did not realise the significance of the"Long Mem" function.
I now realise that Long Mem would be the appropriate mode for the type of tests referred to above,as it provides a fast enough sample rate to be usable.

This sorts out my confusion,but as you said,doesn't do a thing to explain your original question.

[aghp]

About this  classic video test. Here used Owon SDS7102.
Is is possible someone make this exactly same  test with Rigol?

There is also 1M memory test available with Owon if you are interest so that can compare apple to apple.
Here




Single shot capture one (part of capture is outside from screen, total is 2 field)  PAL field test , using same signal to both channel.

Owon trigger is PAL all field. (not even or odd)

With two channel simultaneous just for fun and to show channels difference if there is.
In some pictures you can find there is red and yeallow traces.


Next pictures are zoomed from this one single shot.
(note bug (or feature) in FW how it show samplerate. It show, samplerate what it use IF scope is running with this horizontal speed)


Captured one field:


After then scope is in stop state.


With this first picture single shot, zoomed to line level.





Zoomed more to color burst. (original single shot capture is in first picture)





Zoomed more (10000x)   (original single shot capture is in first picture)







Zoomed more (40000x) cursors one color burst cycle.   (original single shot capture is in first picture)












About samplerate:


Here it can clearly see how memory affect to samplerate.
(Owon all memory is full speed)

It is nice if there is same table for Rigol?

[vk6zgo]

The "zoomed" line rate & burst pictures would be regarded as usable in the TV industry,but the first picture, of a field,is approaching being useless.
You may be able to see 50Hz "hum" with it,but any artifacts in the field sync/blanking interval would be impossible to discern.
Note also the sinewave shaped shading at the  bottom right hand side of the pix.

[aghp]

The "zoomed" line rate & burst pictures would be regarded as usable in the TV industry,but the first picture, of a field,is approaching being useless.
You may be able to see 50Hz "hum" with it,but any artifacts in the field sync/blanking interval would be impossible to discern.
Note also the sinewave shaped shading at the  bottom right hand side of the pix.

Of course first picture is useless. It is just for show what is single shot realtime capture behind next images.

How it can  understand next images if there is not this information what is first single shot captured before zoomed inside to sample buffer.

Even with this first "useless" image it was propably misunderstooded?

This first image is capture where from all these  next pictures are zoomed.   Just for show what  memory affct  to samplerate.  It can single shot capture 20 full field and still all video signal timing details can measure with enough acuracy. (40ns time resolution) This can not at all do with 1M or 2ch 500k sample buffer. Also it is important (if go to higher speed signals) that sample buffer speed is fast. (Rigol and Hantek example and most of others in this entry level class have only very limited (some kilo samples) full speed sample buffer.

All zoomed pictures are zoomed from this one (2 field lenght total) single shot capture. Single shot total amount is 40ms. (20 div where on the TFT is around 15div visible) 
This single shot with two channel simultaneously is 2 x 250MSa/s and both channel lenght in sample buffer is 10Msample (what is exactly 10000000 sample). 

After this one single shot scope is in stop state and (next pictures) zoomed in to captured signal. In all pictures (stop state) real captured samplerate is 2 x 250MSa/s of course. (display there have wrong information - it show what is samplerate if scope is running with this horizontal speed used in zoom)

This was not video signal test, it was just show what mean 2 separate simultaneous ADC (not interleaved) and 2x10Msample full speed sampling buffer (memory).



"Note also the sinewave shaped shading at the  bottom right hand side of the pix."

If you mean this first picture...

There is 10Mega points in capture. On the screen is 7500000 sample. But TFT have 750pixel for 15div.
How you want make image from this. "Maybe" it need drop some samples out? In other case you just see exactly full yellow continuous area and in some other cases it is not welcome. But what is other solution to do this. maybe it need think more than one hour and find that there is small posibilities. How select what samples drop out...  we can think displayed is only very slow samplerate, of course. Rest (dropped oout) samples are still in vapture buffer. Now we zoom in and can see more and more these.
This dropping out samples (for rendering image) and how these samples visible in display produce "virtual" aliazing effect need littlebit simple understanding.

It is sometimes good to take piece of paper and pen and try imagine how it go. People who understand this do not look at all these kind of effects in image becouse he understand these nature.

[vk6zgo]

I misunderstood your intention with the pictures.
Yes,I can see that the field rate captured signal does have a sufficient sampling rate to display the full video bandwidth of the zoomed part of the signal.
I understand that the 'scope does have a sufficiently fast sample rate to do this.

The "classic video test"has a different basis.
A standard test for analog TV signals is to look at  a video signal at field rate real time,& examine the blanking level through the field group for any distortions,such as hum,clamp pulse breakthrough,etc.

To do this,a field rate display must not exhibit any artifacts which are inherent to the Oscilloscope or waveform monitor,as they tend to  mask  the distortions being tested for.
Early DSOs could not give anything approaching a usable display,as the sample rate at these sorts of time/div would be of the same order as line line rate information.
The captured field rate waveform of Pix (1) is far better than the "old timers",but it does exhibit artifacts which would make it unusable for this test.

If you set out to give the best possible display for this video test,can you obtain a better result?

[chrome]

It is nice if there is same table for Rigol?

I don't know if there was but I've made my own just now:

[aghp]

chrome: tnx this data.

Without your permission I borrowed it for this comparison. (But there is note about source)

At the same time, it becomes very clear how sample buffer size and speed affect to samplerate.

This is not "who is best" it is "how memory affect" to sampling speed.
All these scopes "total" have pros and cons and they are in different area of features so it depends what user need what is better than other.  (and of course also price)

The differences are greater than the minimal.

Here this small table.