Testing DSO auto-measurements accuracy across timebases

[MrWolf]

Besides visual inspection of waveform shape digital storage oscilloscopes also offer wide variety of automated measurements. Usually DSOs are compared based on analog bandwidth and sampling rate / memory depth. Moderately skilled in art will assume that horizontal (time-related) auto-measurements accuracy is directly related to mentioned "headline values". Reality is more complex and even weird. I personally used two DSOs for long time - first having 16kS and second 48kS of main memory. This limits sampling rate for low frequency, but on the other hand horizontal auto-measurements are pretty accurate and can be compared to "4-digit" or "10,000 count" in multimeter world. For example at 20us/div horizontal setting 48kS oscilloscope can give accurate frequency/period for frequencies at least 2000 times apart on same timebase, because it is using full memory buffer analysis. This can become very handy in mechatronics and other applications where scope is used as real-time "instrument panel" for complex machinery. CROs and rare DSOs do this by enabling different timebases for channels, but most have single timebase and zoom is used instead.

Since I needed higher analog bandwidth scope did buy new one with seemingly massive sampling rate and memory compared to old ones - expecting mindblowing performance in automated measurements. Was quite shocked that it barely delivered "3-digit" or "1,000 count" in single spot-on timebase, and completely failed "2 frequency test" compared to old ones. This sparked extensive investigation and revealed "things not in the datasheets"...



Accepted theory: Real-Time Bandwidth = Sample rate / 2.5
Reality found on some scopes:
Timebase=5ns/div, 1GS/s (reported by scope), calculates (correct) risetime 9ns for signal, calculated RTBW 400MHz.
Timebase=500us/div, 1GS/s (reported by scope), calculates risetime 20us for same signal, RTBW still 400MHz but seems more like 15kHz!?
So what's the real bandwidth of such a scope across timebases regarding automated measurements? There are various ways to test but best so far is "32768Hz test":

General logic behind the test is to check timebases (horizontal ns/div) from smallest possible to 5ms/div against risetime and period measurement accuracy. Signal is "nasty" 32768Hz clock signal (very long period but sharp fronts, precise period). This will reveal what is the size of buffer scope actually uses for automated (horizontal) measurements. Can deduce if scope is "single buffer" or "dual buffer" and whether it will suit particular application or not.

"32768Hz" test procedure

Signal generation, mandatory part:

Waveform: square wave
Duty cycle: 50%
Frequency: 32768Hz if you have signal gen, or use Arduino program supplied here. Arduino clock frequencies may differ, look here.

This can be varied depending on available hardware:

Risetime: <= 10ns (Arduino: ~5ns) NB! Do not use rise exceedingly over the analog bandwidth of scope!
Jitter: <= 1ns  (Arduino: ~100ps)
Amplitude: 1Vpp (Arduino: 5VDC)
Coupling if using signal gen: AC or DC - choose which gives best risetime on smallest timebase with specific scope.

Signal source could also be 32.768kHz clock quartz/crystal. Makes interesting little project.
Watch out for scope probe ground lead inductance, explained here.

DSO configuration:

Channel coupling: AC or DC - choose which gives best risetime on smallest timebase with specific scope.
Vertical setting (V/div): 200mV/div (Arduino: 1V/div)
Timebase, eg horizontal setting (ns/div): all timebases from 1ns to 5ms

Values to write down to test table:

Timebase (horizontal setting ns/div)
Sampling rate reported by DSO in MSa/s
Leading edge risetime min,avg,max (ns)
Signal period min,avg,max (us)

Equipment perferred to be warmed up (30 min). Stats must be reset when changing ranges. Averaging (if applied) must not affect Min/Max.

Unfilled Excel table:
DSO_auto_measurements_test__BLANK__v1_1.xls

Blank for printing w/o automated graphs:
DSO_auto_measurements_test_for_printing__v1_1.pdf

Proposals how to fix issues with problematic DSO models:

To display substantially erroneous readings w/o any indication about their (correct!) standard deviation cannot be considered a good industry practice, especially when indicated sampling rate implies much higher precision of reading.

- manufacturers need to specify horizontal measurements accuracy in datasheets, just like it's done with multimeters - so customer can make informed decision. Buying scope with substandard horizontal auto-measurements accuracy can lead to need buying various other gear (multimeters, frequency counters, ...) that is not needed with seemingly similar scope.

- near-zero cost proposal: Instead of "=", use "<=" before reading, since detecting reduced accuracy condition internally is trivial. Alternately switch the reading off (PicoScope) and/or display "?" (Tek).

- correct readings w/o realtime performance hit could be obtained when doing accurate calculations in only STOP mode. Combine with method 1. GW Instek seems to do this on GDS 1000B series.

- there may be user-selectable option to perform calculations from secondary buffer (fast) or actual sample memory (slow). Combine with method 1. This is already implemented with Rigol DS1000Z (DS1054Z) FFT math function (up to 16kS is used) but all other functions rely on 1.2kS "secondary buffer". Option to use larger buffer should be made global.

- do not use substandard buffer size as default for calculations. I consider 5kS as absolute minimum.

Bottom line

Having "secondary buffer" is not necessarily bad thing, it is just not the best... May be unavoidable with very large main memory and cost-effective hardware. However user needs to be aware of limitations. Scope having only 5kS total may perform better in many situations than scope having almost non-existent secondary buffer and large main memory. Scope having 50kS for calculations and large main memory will do ok in most situations. However scopes having large main memory and doing all calculus based on original precisely timed sample points are in different class and can be used similar to scopes with multiple independent timebases.

[MrWolf]

DSOs tested:

Rigol DS1000Z / DS1054Z (100MHz, 4ch, 2016 model, tester "MrWolf"):
DSO_auto_measurements_test__Rigol_DS1000Z.pdf (original 32768Hz, <=10ns rise test)
DSO_auto_measurements_test__Rigol_DS1000Z__Arduino.pdf (Arduino 32771Hz, <=5ns rise test)
DSO_auto_measurements_test_AC__Rigol_DS1000Z__120MHz.pdf (120MHz AC signal test on 5-100ns timebases)
DSO_auto_measurements_test_AC__Rigol_DS1000Z__12MHz.pdf (12MHz AC signal test on 5-1000ns timebases)
Secondary buffer detected. Suggested size 1200pts. Readings seem to correlate with formula:
Secondary (screen/buffer) sampling rate = 1 / (Timebase / 25)
which implies 300pts effective horizontal resolution (non-zoomed).
New updated tests, very important is to press [CLEAR] after changing timebase!
It sort of resets stats on timebase change but Min, Max may get weird values. Pressing [CLEAR] sorts it out.

Gw Instek GDS1054B (50MHz, 4ch, tester "saturation"):
DSO_auto_measurements_test__Gw_Instek_GDS1054B.pdf  (original 32768Hz, <=10ns rise test)
Secondary buffer detected, but seems to be very large. Needs further analysis.

Siglent SDS1102X+ (100MHz, 2ch, tester "rf-loop")
DSO_auto_measurements_test__Siglent_SDS1102X+.pdf (original 32768Hz, <=10ns rise test)
Secondary buffer detected. Suggested size at least 70kpts. Readings seem to correlate with formula (50us - 1ms ranges):
Secondary (screen/buffer) sampling rate = 1 / (Timebase / 1666.666...)
which implies 23333.333... pts effective horizontal resolution  (non-zoomed).
Details explained here.

LeCroy WaveJet 334 (350MHz, 4ch, tester "jpb"):
DSO_auto_measurements_test__LeCroy_WaveJet_334.pdf (original 32768Hz, <=10ns rise test)
Secondary buffer not detected.

PicoScope 2205 MSO (25MHz, 2ch+16ch, 2013 model, tester "MrWolf"):
DSO_auto_measurements_test__PicoScope_2205_MSO.pdf  (original 32768Hz, <=10ns rise test)
DSO_auto_measurements_test_AC__PicoScope_2205_MSO__12MHz.pdf (12MHz AC signal test on 50-500ns timebases)
Secondary buffer not detected.

PicoScope 2205 (25MHz, 2ch, 2010 model, tester "MrWolf"):
DSO_auto_measurements_test__PicoScope_2205.pdf (original 32768Hz, <=10ns rise test)
Secondary buffer not detected.

[tautech]

The FW used in any DSO involved in these tests should also be listed.

[Fungus]

And if you don't have all the fancy equipment just connect it up to the test signal and tell us if the rise time varies or not when you zoom. 

[MrWolf]

And if you don't have all the fancy equipment just connect it up to the test signal and tell us if the rise time varies or not when you zoom. 

Please take note of example image provided in first post of the thread:
"DS1000Z_measuring_rise_and_period.png"
You would be welcome to provide a customer guide, how one would take precise automated measurement of 32768Hz signal period using zoom feature or otherwise. By precise I mean better than 30.5us, which implies 10MS/s class device. 1GS/s class device should be able to provide reading 30.517us +- 0.001us.

Actually very pleased you asked, found severe bug with zoom and stats, filed under bugs thread.

[Fungus]

Actually very pleased you asked, found severe bug with zoom and stats, filed under bugs thread.

No you haven't. The stats for things like 'minimum' and 'maximum' are supposed to remember the, um, minimum and maximum values they've seen until you reset them.

It's correct behavior.

[tautech]

Wolf.
I've done the tests on a couple of scopes (1 entry level, 1 top of our line)..........interesting results but they can wait until we clear a couple of things up.

DSO Auto tests xls file

Range tested.......what's this? 

Chart itself:
Memory MS/s ? ? ? ?

Should this be Sampling as in M or G Sa/s or Memory depth as in Mpts ?

I'll be making some changes to timebase settings on 1 chart as one of the scopes uses 1, 2.5, 5 steps and the other matches what you've laid out: 1, 2, 5. I'll add a note, watch for it.

I should get these posted in the next day or so after I've entered all the data into the spreadsheet.
That's the evening gone now, time for sleep.

[MrWolf]

Range tested.......what's this? 

Vertical setting (V/div)

I'm not native english speaker so there might be slight wording issues
But please look new much improved quality Rigol test attached to second post, there it is evident what is meant for every box.

Memory MS/s ? ? ? ?
Should this be Sampling as in M or G Sa/s or Memory depth as in Mpts ?

Sampling rate MSa/s. Mem depth is probably not important since sampling
rate and timebase will suggest minimal depth.

I will update charts to clear it up soon. Updated, download from thread's first post.

[Fungus]

I'll be making some changes to timebase settings on 1 chart as one of the scopes uses 1, 2.5, 5 steps and the other matches what you've laid out: 1, 2, 5. I'll add a note, watch for it.

I'm not sure how the timebase settings are important. Either it works in screen space or in sample space. ie. The risetime numbers will change with zoom or not.

It might be interesting to know if there's a definite switchover point on some 'scopes.

Apart from that? I don't see the point in trying to quantify it. It says nothing about the quality of the 'scope or its firmware. Wrong is wrong. The fact that one scope is somehow "less wrong" than another is meaningless.

(in fact I'd prefer more wrongness if I have a choice - make the wrong value stand out as much as possible)

[tautech]

I'll be making some changes to timebase settings on 1 chart as one of the scopes uses 1, 2.5, 5 steps and the other matches what you've laid out: 1, 2, 5. I'll add a note, watch for it.

I'm not sure how the timebase settings are important. Either it works in screen space or in sample space. ie. The risetime numbers will change with zoom or not.

We do this exercise properly or not at all. 

It might be interesting to know if there's a definite switchover point on some 'scopes.

There is, for the 2 I've checked, the entry level unit being lower.

Apart from that? I don't see the point in trying to quantify it. It says nothing about the quality of the 'scope or its firmware. Wrong is wrong. The fact that one scope is somehow "less wrong" than another is meaningless.

Proper analysis IS required and changes to FW CAN AND DO affect results.

I'm going to go a further step than Wolf has suggested and run the tests again in DOT mode.

[w2aew]

Note that on scopes like the Tek DPO/MSO/MDO series, measurements are always made on the full acquired record - not a subset of points used for display or measurement.  The user has control over the number of points being used (memory depth being used), and the display shows both the record length selection and the resulting sample rate for a given horizontal timebase setting.  So, you can easily tell by inspection what sample granularity is being used for the measurement.  If you don't have sufficient sample rate at a given horizontal timebase setting, then you simply crank up the record length.  These scopes will also tell you if you have insufficient sample rate for a given measurement (like rise/fall).

[MrWolf]

Have received strict orders to leave lab corner... But managed to get needed signal from Arduino Uno! It might turn out as pretty mean "scope killer": 5ns rise and no jitter to speak of!
Arduino program attached.
5Vpp signal, so set coupling to AC and vertical div to 1V.

Edit: I tested it on Arduino Uno R1, seems it has slight clock issue:
https://www.eevblog.com/forum/testgear/testing-dso-auto-measurements-accuracy-across-timebases/msg1092582/#msg1092582

[tautech]

Have received strict orders to leave lab corner... But managed to get needed signal from Arduino Uno! It might turn out as pretty mean "scope killer": 5ns rise and no jitter to speak of!
Arduino program attached.
5Vpp signal, so set coupling to AC and vertical div to 1V.

Interesting, I'm routinely getting under 7ns from my old SDG1010 but I do wonder why you have asked for the test to be conducted with AC input coupling ? I'd never consider doing risetime measurements with other than DC input coupling.
I might take the time to check a few measurements with both because AC input coupling for risetime just seems wrong. 

[MrWolf]

I do wonder why you have asked for the test to be conducted with AC input coupling ?

Because:
- it is not about actual analog response measuring, its about seeing when risetime measured at lowest timebase (taken as reference for specific scope) gets corrupted by digital processing on larger timebases
- low end scopes often do not have true DC offset capability, so measuring +DC square from Arduino (+inevitable small overshoot) could force to use bigger vertical div and wfm would occupy <50% of the screen => test results not easily comparable

Edit: actual experiment:

Pico 2205 (2010 model):
Measuring risetime 90/10% from Arduino
2V/div, DC coupling: 8.941ns s.d. 131ps
1V/div, AC coupling: 8.945ns s.d. 109ps

So indeed, DC coupling forced to more coarse V/div, little bigger s.d. and had to fiddle with trigger (which is just smack on 0V for AC coupling).

[Fungus]

I wonder where the GW-Instek fanboys are?

Usually they're the first to jump into any thread and tell us how amazing and perfect and bug-free their 'scopes are. I'm beginning to wonder if they're covering something up.   

Does nobody here own an R&S? That's a shame. They're really nice scopes, If I had loads of money I'd buy an R&S with all the options and MSO addons.

[Howardlong]

Note that on scopes like the Tek DPO/MSO/MDO series, measurements are always made on the full acquired record - not a subset of points used for display or measurement.  The user has control over the number of points being used (memory depth being used), and the display shows both the record length selection and the resulting sample rate for a given horizontal timebase setting.  So, you can easily tell by inspection what sample granularity is being used for the measurement.  If you don't have sufficient sample rate at a given horizontal timebase setting, then you simply crank up the record length.  These scopes will also tell you if you have insufficient sample rate for a given measurement (like rise/fall).

Alan

Firstly thank you for your input!

My main criticism with the way the MDO3000 does measurements is mainly around the indication that it's significantly sub-sampling: true, it states "Low resolution" but it's in the standard font and colour, and is not highlighted or otherwise annunciated. For clipped values there is a clear warning annunciator indicating it's a likely to be a nonsense measurement. In addition it still tries to make a measurement that, by itself, is not immediately obvious as nonsense. You'll see rapidly changing granular values closely around, for example, 37.9ns.

What is good (in my opinion!) is that it automatically resets the stats on a sample rate change, either through a change in timebase or change of memory depth.

In more general terms, regarding rise times, I was thinking about the scenarios where I'd be interested in that. I can't think of a case where I wouldn't be zooming in anyway to see it to see any other facets such as preshoot, overshoot, undershoot and ringing, and the way they manifest themselves. So I'm wondering if these concerns over rise time calculations are really largely synthetic?

[MrWolf]

So I'm wondering if these concerns over rise time calculations are really largely synthetic?

Good rise time on signal is mainly here to ensure low trigger jitter. What is most revealing is period measurements. Since I have nothing to compare to, besides Picos, have to do it again. Is it "synthetic concern" that my old 25MHz scopes did measure period correctly* on all timebases from 5us to 5ms and my new 100MHz scope failed on period measurement on all timebases, despite vast superiority in analog bw and sampling rate? Or we are getting to a point in history where period of 32768Hz CLOCK signal is no longer of importance? 

Based on period length: 32768Hz measured 32765,4Hz on Pico vs 32786,9Hz on Rigol.
Skilled in art will notice that Rigol number has certain digital ring to it...

*accounting for analog bw and indicated sampling rate

[Howardlong]

So I'm wondering if these concerns over rise time calculations are really largely synthetic?

Good rise time on signal is mainly here to ensure low trigger jitter. What is most revealing is period measurements. Since I have nothing to compare to, besides Picos, have to do it again. Is it "synthetic concern" that my old 25MHz scopes did measure period correctly on all timebases from 5us to 5ms and my new 100MHz scope failed on period measurement on all timebases, despite vast superiority in analog bw and sampling rate? Or we are getting to a point in history where period of 32768Hz CLOCK signal is no longer of importance? 

No, I think you just need to spend time learning and understanding how to best use your instrument, and any limitations it may have, documented or otherwise. As I've said before, I am sure we could find plenty of facets on the Pico that are done differently to other scopes that one person might consider a bug, whereas another might find it a feature.

And, as I said earlier, if I am interested in rise time, I can't think of a reason why I wouldn't be zoomed in, that is why I consider it a largely synthetic test: while it might be interesting academically speaking, in practical terms I can't think why I'd be making measurements in the way you are proposing.

[MrWolf]

The user has control

Gotta love proper oldschool engineering
When I grow up gonna get MDO4000C...

[MrWolf]

And, as I said earlier, if I am interested in rise time,

I'm very much interested in periods.
As mentioned in in some other thread - measuring long periods to high precision is of paramount importance with mechanical engineering, slow electrical resonators etc.
So why make a mess of my thread if you have different interests?

No, I think you just need to spend time learning and understanding how to best use your instrument, and any limitations it may have, documented or otherwise.

Moreover, "Wolfs test" will reveal undocumented limitations of scope in 10 minutes. Without weeks trial-and-error poking around in random circuits.

[Howardlong]

And, as I said earlier, if I am interested in rise time,

I'm very much interested in periods.
As mentioned in in some other thread - measuring long periods to high precision is of paramount importance with mechanical engineering, slow electrical resonators etc.
So why make a mess of my thread if you have different interests?

Respectfully, it was you who was concerned about rise times. 

I am also concerned about periods. I set up the instrument appropriately to measure both, which, depending on the scenario and the instrument, will very often mean setting up more than one configuration to make the two measurements. Frequently I might run more than one instrument to make simultaneous measurements, that is certainly not uncommon, some instruments are stronger in some facets than others, as you are finding out. Again, it is down to learning and understanding your instrument(s).

It's not about "making a mess" of your thread, it's about understanding that some people don't consider the tests to be something that's representative of how you'd actually use the instrument in a practical situation.

This is not to discount the test in itself, the value of the test is to highlight that you shouldn't be using the instrument in the way you are to make those measurements.

[tggzzz]

I'm very much interested in periods.
As mentioned in in some other thread - measuring long periods to high precision is of paramount importance with mechanical engineering, slow electrical resonators etc.

In that case I would wouldn't use a scope. I would use either a time/frequency counter or a spectrum analyser. If using an FFT-based mechanism to determine the frequency, ensure the capture buffer is adequately long.

If you are looking at mechanical frequency response, then in some cases it may be beneficial to determine how the frequency response varies over time/amplitude due to non-linear effects. Such effects also occur in electronic systems, but usually every effort is made to minimise such effects.

[Fungus]

And, as I said earlier, if I am interested in rise time, I can't think of a reason why I wouldn't be zoomed in, that is why I consider it a largely synthetic test

I'm very much interested in periods.

So find an instrument that meets your needs. If Picoscope works for you then use that. 

Complaining that the rest of the world isn't doing it your way is pointless.

[Fungus]

It's not about "making a mess" of your thread

His thread? 

This is not to discount the test in itself, the value of the test is to highlight that you shouldn't be using the instrument in the way you are to make those measurements.

It's a way that seems counter-intuitive. I don't recall anybody else ever complaining about it or calling it a bug (which it isn't, not really, it's just the way it works).

[MrWolf]

Respectfully, it was you who was concerned about rise times. 

Initially yes, it was surprised that these do not align with indicated sampling rate. However there you can at least get the result when zooming in. But what about stuff you cannot measure automatically (why? think time-varying signals) on specific instrument, despite "headline figures" indicating it would do just fine?

This is not to discount the test in itself, the value of the test is to highlight that you shouldn't be using the instrument in the way you are to make those measurements.

...and also to point out that it is not good UI practice not to have visual indication about true accuracy, which I do no find acceptable as former professional UI designer.

[MrWolf]

Since it's getting too philosophical... Did use lunch pause to go to store and buy brand new Arduino Uno R3. Yesterday code was tested on Uno R1. Seems that all crystals are not created equal:

Pico 2205 @ 5us/div & 100MS/s (10 ns sampling interval)

Arduino Uno R1:
   Frequency: 32.73kHz, s.d. 3.901Hz
   Cycle time: 30.55us, s.d. 3.64ns
   
Arduino Uno R3:
   Frequency: 32.77kHz, s.d. 5.369Hz
   Cycle time: 30.52us, s.d. 4.998ns

Note that Uno R3 has much more precise crystal. Crystal aligns "too well" with 10ns sample interval and Pico clock, which gives larger 4.998ns standard deviation. No dithering - no enchanced resolution! Textbook stuff, gotta love it 

Edit: Confirmed with 3 different hw counters:

Uno R1:
32.734176 kHz (Siglent SDG2000X)
32.734 kHz (Agilent U1272A)
32.7345 kHz (Rigol DS1000Z)
Risetime 5ns, jitter +-100ps (Rigol DS1000Z)

Uno R3:
32.770604 kHz (Siglent SDG2000X)
32.771 kHz (Agilent U1272A)
32.771 kHz (Rigol DS1000Z)
Risetime 4ns, fall 6ns, jitter +-100ps (Rigol DS1000Z)

Quite possibly R3s also differ. Measure yours with hardware counter if you have one and change "Frequency" to correct one in test form.

[MrWolf]

In that case I would wouldn't use a scope. I would use either a time/frequency counter or a spectrum analyser. If using an FFT-based mechanism to determine the frequency, ensure the capture buffer is adequately long.

If you are looking at mechanical frequency response, then in some cases it may be beneficial to determine how the frequency response varies over time/amplitude due to non-linear effects. Such effects also occur in electronic systems, but usually every effort is made to minimise such effects.

Both valid points. But on the other hand it is to be expected even from scope to deliver according to its sampling rate and memory. Especially important if you are budget-limited and cannot buy special tool for every task. Better one of my old scopes had 200MSa/s (non-ETS) and 48kS memory. New has 1GSa/s and 24M. Yet does not deliver even as old one. With all due respect - WTF? 

[tautech]

I do wonder why you have asked for the test to be conducted with AC input coupling ?

Because:
- it is not about actual analog response measuring, its about seeing when risetime measured at lowest timebase (taken as reference for specific scope) gets corrupted by digital processing on larger timebases
- low end scopes often do not have true DC offset capability, so measuring +DC square from Arduino (+inevitable small overshoot) could force to use bigger vertical div and wfm would occupy <50% of the screen => test results not easily comparable

Edit: actual experiment:

Pico 2205 (2010 model):
Measuring risetime 90/10% from Arduino
2V/div, DC coupling: 8.941ns s.d. 131ps
1V/div, AC coupling: 8.945ns s.d. 109ps

So indeed, DC coupling forced to more coarse V/div, little bigger s.d. and had to fiddle with trigger (which is just smack on 0V for AC coupling).

OK, let me tell you a little secret about DSO's............Fine adjustment of V/div. (called Var (Variable) on a CRO)


So we want to measure risetimes...........done by having the rising edge amplitude EXCEEDING the 10 and 90% graticules. From one step to the next V/div it is very common to exceed the displayed area with too much amplitude or too little to do so. I guess in my case it's a throwback from the days I spent with CRO's where you had to use the graticules for this measurement and I still set up a scope in this old manner when wanting risetime measurements.
Probably dumb I know.....just how I do it but even with the first DSO's I had (Tek TDS2012B) measurement accuracy was setting dependant.

However I can't remember a time ever where I've needed AC coupling for risetime measurements for the work that I've done with scopes.

Trigger settings, easy with a DSO......push the level knob and it autosets to a 50% level.

AC coupling for these tests...........nah, not at 1V p-p levels.

But here's a AC coupled screenshot anyway:



With the other DSO but using DC coupling:

[MrWolf]

OK, let me tell you a little secret about DSO's............Fine adjustment of V/div. (called Var (Variable) on a CRO)

Not every DSO has it. Test mostly low end stuff here 
Edit: also - wouldnt it be just moving pixels around on DSO w/o proper hardware DC offset? With AC coupling you get full 8bits vertical. Operating on half of the vertical (no matters where pixels are moved) would downgrade to 7 or less bits, no?

Trigger settings, easy with a DSO......push the level knob and it autosets to a 50% level.

Well one more operation... if done wrong, will affect triggering seriously and may introduce jitter which will ruin the test.
If something is done across wildly variable tech and user base should minimize variables whenever possible.

But if you know your stuff - why not  Test any way you like while respecting core idea of the test which is to measure low frequency but precisely timed signal.

[tautech]

OK, let me tell you a little secret about DSO's............Fine adjustment of V/div. (called Var (Variable) on a CRO)

Not every DSO has it. Test mostly low end stuff here 

Surely a 1054Z has that ?
Push the V/div knob to get to fine adjustments.

You can see from the screenshots that both mine are ~130's mV/div

[MrWolf]

Surely a 1054Z has that ?

Look previous post (edited), do not think it will give best possible vertical resolution.

[w2aew]

Another factor that you need to consider for accurate rise/fall time measurements is the scope's interpretation of the 0 and 100% levels.  Waveform artifacts such as overshoot, ringing, droop, settling duration, etc. can all affect the rise/fall measurements because they can affect how the scope determines what it will use for the 0 and 100% levels.  If you adjust the timebase to zoom in on the edge, you might not get accurate 0 and 100% levels because they'll not be included in the waveform being measured.

[Fungus]

...and also to point out that it is not good UI practice not to have visual indication about true accuracy, which I do no find acceptable as former professional UI designer.

I don't think anybody disagrees that it could be improved. The disagreement is whether it's a real problem or not.

The fact that you're the first person to make a lot of noise about would suggest that it isn't a big problem in real life usage.

[Howardlong]

With the other DSO but using DC coupling:

I might have misunderstood what's being shown here, but is that second one measuring off screen? If it isn't, it's not going to give an accurate rise time result as you need to have a stable start and end. As shown, it's not at its final rest position (to properly calculate the 90% voltage) and there could be overshoot in the displayed trace (although I doubt the is any looking at the waveform in this case!)

That's why (in my opinion) you need to measure your rise time with reasonable visibility of what's really going on at the transition.

FWIW AC coupling is a valid scenario for measuring, for example, PCIe and TMDS with single ended probes where there may be significant relative DC common mode offset, but the signal itself is coded with differential DC balance (i.e. equal numbers of zeros and ones over time). Not that you'd be measuring PCIe and TMDS with the scopes we're discussing of course ;-) but there are also slower and longer distance communications technologies with DC balance encoding where you might find an application for it at this level.

[tautech]

Another factor that you need to consider for accurate rise/fall time measurements is the scope's interpretation of the 0 and 100% levels.  Waveform artifacts such as overshoot, ringing, droop, settling duration, etc. can all affect the rise/fall measurements because they can affect how the scope determines what it will use for the 0 and 100% levels.  If you adjust the timebase to zoom in on the edge, you might not get accurate 0 and 100% levels because they'll not be included in the waveform being measured.

Quite correct.
If part of the waveform is off-screen it does affect all auto measurements.

[tautech]

With the other DSO but using DC coupling:

I might have misunderstood what's being shown here, but is that second one measuring off screen? If it isn't, it's not going to give an accurate rise time result as you need to have a stable start and end. As shown, it's not at its final rest position (to properly calculate the 90% voltage) and there could be overshoot in the displayed trace (although I doubt the is any looking at the waveform in this case!)

That's why (in my opinion) you need to measure your rise time with reasonable visibility of what's really going on at the transition.

Please be assured Howard that any instability in the waveform IS adjusted so that it's outside the risetime graticules, not that it should make much difference to a DSO. Sanity check is measurements are what I've routinely had from my SDG1010 AWG over some years now.
Just also realised I did not have the graticule brightness set to max as is needed in these Siglents to show up well on screenshots.
I'll come back with a better pic in an edit soon......

[tautech]

As already seen of Wolf's 1054 tests there are settings where there is some accuracy for both measurements but more cycles are needed on the display for Period measurements to be more accurate, conversely less cycles for Risetime measurements to be accurate.
My initial results also confirm this to be so.

This screenshot shows the timebase setting that's the best compromise for accuracy of both.
SDS2304X Dot mode.
Trace and Graticule @ 100% brightness.

[MrWolf]

Since natural sciences are about experimentation...
Let's mutilate my poor old 2010 model 25MHz Pico with 5ns riser from Arduino.
2205 does not have true DC offset much like DS1000Z AFAIK.

+-5V (1V/div), AC coupling, 4GS/s ETS, 5ns/div
DC average: -402mV s.d. 2.61mV
Rise time: 9.06ns s.d. 104.3ps

+-10V (2V/div), DC coupling, 4GS/s ETS, 5ns/div
DC average: 2.096V s.d. 4.651mV
Rise time: 9.239ns s.d. 103.6ps

+-5V (1V/div), AC coupling, 900MS/s ETS, 1us/div
DC average: 3.474mV s.d. 2.043mV
Rise time: 9.097ns s.d. 547.3ps

+-10V (2V/div), DC coupling, 900MS/s ETS, 1 us/div
DC average: 2.514V s.d. 2.142mV
Rise time 9.248ns s.d. 540.6ps

Note waveform general look and placement on screen is same AC vs DC mode = controls were operated correctly.
I can see lost precision (look s.d.) due to less vertical bits in "simulated DC offset mode" and DC values are seriously affected in small timebases (=zoom from large timebase on DS1000Z due to screen buffer based processing).

[tautech]

Now you've got us chasing our tails. 

Aren't the tests @ 1V p-p ?

[MrWolf]

Now you've got us chasing our tails. 
Aren't the tests @ 1V p-p ?

Arduino is 5V DC device. Also input voltage does not affect results if signal to volts/div ratio is in same ballpark. I'm interested in Arduino because every punk can have it for couple of bucks and run the test at any location.

BTW I did NOT operate controls correctly  DC trigger is at 2V, not 2.5V. New pics shortly.

Edit:
New pics and data in original post. Looks like DC vs AC coupling significantly affect rise measurements on "simulated DC offset" scopes.
To experimentally validate "chasing tails" claim will run Arduino test on DS1000Z. Meanwhile gotta eat and get beatings from wife cause I'm "stuck at work" suspiciously long

[tggzzz]

In that case I would wouldn't use a scope. I would use either a time/frequency counter or a spectrum analyser. If using an FFT-based mechanism to determine the frequency, ensure the capture buffer is adequately long.

If you are looking at mechanical frequency response, then in some cases it may be beneficial to determine how the frequency response varies over time/amplitude due to non-linear effects. Such effects also occur in electronic systems, but usually every effort is made to minimise such effects.

Both valid points. But on the other hand it is to be expected even from scope to deliver according to its sampling rate and memory. Especially important if you are budget-limited and cannot buy special tool for every task. Better one of my old scopes had 200MSa/s (non-ETS) and 48kS memory. New has 1GSa/s and 24M. Yet does not deliver even as old one. With all due respect - WTF? 

Thus illustrating why people still swear by and pay good money for old equipment they know and trust

_{(Lights blue touchpaper and retires )}

[nctnico]

Now you've got us chasing our tails. 

A friendly word of advice: stop wasting your time on this. It is really not worth it because it is not a real issue. Tektronix already wrote a ridiculous bash-note about it comparing their scopes with Agilent's.

[saturation]

The 1054B analyzes the input buffer but needs ~ 2 graticules peak to peak and for very slow waveforms, like 60 Hz, a time base showing as least one full period, after which very little difference occurs in automated measurements; measurements change mostly to the sampling rate and  chosen memory depth.

The default auto measurements are on the entire buffer, but it can be user selected to the screen or between cursor regions.

There is no algorithm to mark that the sample size is insufficient for measurement, as was mentioned for many Tek DSOs.

What I do is cross check an automated Vpp against a visual Vpp on the graticule.  Then derived calculations such as RMS are then as expected. 

A threshold for when the calculations start to deviate and that the sampling or waveform size is insufficient can be seen when a previous stable value sudden varies widely or is unstable, and as an index the standard deviation abruptly rises on the new settings compared to the prior stable value.

You can improve the measurement by filtering away noise and averaging the tracing.

Since Wolf's test will demonstrate how this works I'll or have someone work on this and post.

[jpb]

I don't quite know what it shows other than the Wavejet is a very straight forward scope so as the sample rate drops due to memory limitations the rise time calculation goes haywire.

Anyway, attached is the results for the LeCroy Wavejet, probably not quite warmed up when I started. It does min and max but not average (you can of course measure averaged waveforms but you can't average directly measurements from non-averaged waveforms).

The minimum values all seem a bit out which is an interesting quirk. The spec for the rise time (Agillent 33522A) is 8.4 nsecs. By setting 5 nsec/div, Equiv time sampling(100GS/s) and 256 point averaging I get a very smooth curve with the rise time of 8.32x nsecs where the x digit varies but the min is 8.181 and the max 8.367 but I think both of these are outliers.

I attach the spreadsheet.

[Fungus]

So a LeCroy Wavejet does it, too? 

This thread is now officially 

[MrWolf]

Tested DS1000Z for AC vs DC coupling. Moving wfm up and down with vertical control do not change abs voltages or auto-readings. Did not test for movement limits. Switching between AC and DC in same vertical range and moving wfm to middle with vertical yield exactly same results. So dunno what it's doing but it do not seem to be actual analog DC offset and not old Pico style system either.
If someone has full understand what it's doing or know a post about this please give ref.

Just FYI that there is also weird stuff called VerticalRef.=Ground|Center under [Utility]
Here's little talk about it:
https://www.eevblog.com/forum/testgear/rigol-ds1054z-vertical-pain-in-the-ass/

Bottom line - since readings are not affected it's not important which coupling to use on DS1000Z.
May vary with other scopes.

Another more interesting matter. Arduino seems to kick out quite sharp edges. Measuring them with 10x probe with ground clip attached is no-go. Since output on pin ~9 and ground are nearby I managed to hook probe spring ground using some bent wires. Much less ringing, rise is 4ns, fall is 6ns according to DS1000Z. Images attached:
Setup with spring hook; rise with regular ground lead; rise with spring; fall with spring.

Also tested if 10ns edge could be generated with Arduino.
Easy: about 300ohms in series. Stick resistor staright in. 10x probe/scope provides C.
Compared to signal gen results: No difference despite 1V vs 5V.
Theory that only thing that matters is signal height in bits is correct. Makes sense since test is about digital artefacts not analog front end.
Also there was no difference 4ns rise vs 10ns rise starting at 200ns/div and larger timebase on DS1000Z. Again because digital artefacts overwhelm analog frontend.
But just for the record gonna run the test with Arduino. Very good tool for the job.

[saturation]

1054B prelim data

I'll spot check the accuracy and repost if changes required

[MrWolf]

I don't quite know what it shows other than the Wavejet is a very straight forward scope so as the sample rate drops due to memory limitations the rise time calculation goes haywire.

Thank you for helping humanity in struggle against crap programming. I can confirm that it shows Wavejet as being honest scope and not doing secondary buffering. Operator can assume ballpark precision at any point based on reported sampling rate 
Difference with Pico is that Pico sniffs trouble and switches reading off, Wavejet just soldiers on.

[saturation]

Final Results

No changes except the labels marked in yellow.

[MrWolf]

Final Results

Seems that buffer kicks in only at 200us (for risetime), so it must be quite large. Period good on all timebases. At extreme 5ms, does it give any hint that accuracy is reduced or just displays result as usual? Overall good scope, cannot see any serious issues with it for normal operation 

First time I see that scope can do such long period (that does not fit on the screen) measurement  on small timebases. So it must be processing full memory record all the time <200us timebase. Actually quite logical thing to do on DSO. Engineers must have been thinking making this one.

[Howardlong]

Now you've got us chasing our tails. 

A friendly word of advice: stop wasting your time on this. It is really not worth it because it is not a real issue.

Regrettably I agree, I only realised too late, and not before needlessly investing my time on what is practically speaking a non-problem if you're prepared to learn and understand. A bit of a pedant's curse, navel gazing while Rome burns, in my opinion of course!

[MrWolf]

Nice move with tautech comment out of context But in a way youre right. Better the brand, less the problem. So far DS1000Z is only utter failure. Lets see if couple more scopes pop up and then maybe time for combined chart - will be quite a sight.

[MrWolf]

Did Arduino test with DS1000Z. As suspected this test is about ratios, not absolute values (signal amplitudes etc). In both cases (original ~10ns, and now ~5ns rise) precision starts failing by more than 10% @ 50ns timebase. With increasing timebases (500ns for example) relative error is 50% bigger than in ~10ns rise test. So I stick to my guns that DS1000Z somewhat lives up to its analog bw and 1GS/s sampling rate only at 5...20 ns timebases. While with properly engineered scopes timebase has usually no effect, only sampling rate and analog bw. Did separate test to confirm that, will be posted later.

[MrWolf]

Since it is accepted theory that scope Real-Time Bandwidth = Sample rate / 2.5 and should have nothing to do with scope timebase (horizontal setting) did some further tests. These test differs from original "Wolfs test" idea with large period and sharp rise. It's just basic AC signal.

1) 120MHz 1Vpp sine into DS1000Z. Values recorded for timebases where scope did show them (5...100ns). As seen scope does not conform to bandwidth formula and manages only on 5 and 10ns timebases.
DSO_auto_measurements_test_AC__Rigol_DS1000Z__120MHz.pdf

2) Since we are looking into soul of digitizer here, not analog performance, decided to scale test to more manageable 12MHz. Other params same.  It can be seen that indeed, scope starts failing proportionally, at 100ns timebase. Note that scope runs at 1GSa/s reported!
DSO_auto_measurements_test_AC__Rigol_DS1000Z__12MHz.pdf

3) Did run same 12MHz test on Pico 2205 MSO. It did agree to show values on on 50...500ns timebases and was running at 100MSa/s (10x less than DS1000Z). It can be seen that values are accurate on all timebases and conform to DSO theory.
DSO_auto_measurements_test_AC__PicoScope_2205_MSO__12MHz.pdf

Also it can be concluded from Min/Max values that DS1000Z operates at 100ps resolution for calculation source values. Pico operates at 10ps resolution. Consequently delivers period value of 83.33ns for 12MHz sine signal.
To take advantage of its analog bw and sampling rate DS1000Z should operate at 1ps resolution for calculations (Edit: noticed Picos do operate at 1ps precision in ETS mode, so it can be done on entry level scope).
So suggest take that into account when making your purchasing decision*.
*I'm not Pico's salesman, I just do not have any other scope conforming to DSO theory. If you do, replication of tests is most welcome!

Conclusion: With something simple as Arduino or not-too-fancy signal generator you can take a good look into your scopes digitzer soul, if you keep in mind that it's shortcomings will be revealed when looking for error ratios, not absolute values.

[saturation]

Thanks for all the good work Mr Wolf,  could you combine the data into one spreadsheet so users can compare the performance of the tested scopes against each other?

[MrWolf]

Thanks for all the good work Mr Wolf,  could you combine the data into one spreadsheet so users can compare the performance of the tested scopes against each other?

Appreciate! I was hoping that someone has balls to put Rigol 2000 or better series to the test - these might be programmed ok. And theres new kid on the block - Micsig. Also USB Owons and Hanteks would be very interesting, especially after low-end USB scope (OWON VDS1022I) is Daves new recommendation for $300 lab. But if no new data pops up will make combined chart based on current findings.

[Fungus]

It's something worth bearing in mind when looking at the screen I guess. 

As a more general rule though:
a) Always maximize everything on screen when looking at numbers.
b) Go with ntnicos's sig.

[rf-loop]

I do not accept this claim. Only small error is if scope do not note for user that result is out of accuracy or something.
How designer select measurement buffer length is NOT programming error.  Of course it is nice if also cheap oscilloscope can have enough brute force for acquisition buffer data processing so that it still can keep good wfm/s rate. Designer need select apple or orange. He can not select both when there is (very)limited processing resources available.

Edit: Oh you changed...  so my comment is bit obsolete

[MrWolf]

Of course it is nice if also cheap oscilloscope can have enough brute force for acquisition buffer data processing so that it still can keep good wfm/s rate.

No need for brute force actually. GW Instek has made clever move with more precise STOP mode processing (havent tested personally, but that's what owners claim). It's big difference whether you have to be twisting knobs until they fall out of sockets or just press STOP, record the value and move on.
Also no need to underestimate possibilites of cheap tech or what can be implemented in cheap tech. Averaging (or ETS) can work wonders on repeated signals if source data is timed with high enough precision.
I see sort of "manual" or "automatic" analog with cars. Many like to clunk with a stick once a while but eventually you just need to get thru traffic with minimal effort. Currently there is no way to tell which it is based on "headline figures" for oscilloscopes.

[Fungus]

I do not accept this claim.

I don't accept it as a bug. It's a logical consequence of working with data that was reduced to screen pixels.

Making charts to find out which 'scopes are "more" or "less" wrong seems pointless to me. Wrong is wrong. 

The lesson is to always maximize things on screen when you measure them (something I suspect most people would naturally do horizontally, if not vertically).

[MrWolf]

The lesson is to always maximize things on screen when you measure them (something I suspect most people would naturally do horizontally, if not vertically).

Seems simple but may fire back as pointed out by w2aew here.
Did small test on it: same wavefront seen at 5ns/div and 1us/div.
Specific scope manages to get more-less same value for rise, but True RMS, AC RMS, DC average substantially differ due to horizontally clipped ringing. So I would argue that if scope is capable taking precise measurement on relatively larger timebase, it may deliver better picture if several auto-measurements are used at same time.

[rf-loop]

I do not accept this claim.

I don't accept it as a bug. It's a logical consequence of working with data that was reduced to screen pixels.

Making charts to find out which 'scopes are "more" or "less" wrong seems pointless to me. Wrong is wrong. 

The lesson is to always maximize things on screen when you measure them (something I suspect most people would naturally do horizontally, if not vertically).

My comment was  for MrWolf...
Sorry it looks like comment for you in timeline.

[rf-loop]

 ´

[Fungus]

My comment was  for MrWolf...

So was mine.

Better the brand, less the problem. So far DS1000Z is only utter failure. Lets see if couple more scopes pop up and then maybe time for combined chart - will be quite a sight.

Wolfie seems determined to prove the DS1054Z is the worst thing ever, that being "less wrong" is somehow OK. 

I'm going to leave him to it. I've been using my DS1054Z happily for two years and never really noticed this huge elephant of a problem.

[MrWolf]

We seem to have identified two quite different mindsets here 

Just out of curiosity, how "this is pseudoproblem" people manage to solve any problems more complex than risetime in efficient manner? Ok you zoomed in, you got your risetime. After that you have to zoom out to work on something else. That something else probably gets corrupted in malicious manner if the risetime is off. Would you prefer keep zooming for that trivial risetime measurement all the time to check what is source for problem? Or its gonna be left for just luck? What if there are 10 other params to monitor? Hassle with each one like well trained knob-monkey every 5 minutes? If there is some param you cannot monitor "off the shelf" you gonna leave that for luck also or make a math function to monitor it?

Especially gets me utter bullshit "it cannot be done because it would drive cost up". Only thing that this drives up is   . 200€ soabox from 2010 operates at 10ps calc resolution, 1ps calc reso for 4GS/s ETS no problem. Middle pricelass soapbox that does 50GS/s probably goes into femtoseconds math wise. Cannot be done? No practical value to ETS or precision math? Ever heard of phases?



Dude should really zoom in vertically here, but the point is still valid:


Suppose its anyone personal choice if he would like stay stuck in 30 year old tech and practices applicable there I'm gonna expect these kinds of possibilites from any scope from any manufacturer. Since it's not in the datasheet, I'm gonna do the test. Substandard contraptions made by schoolkids that did poke their nose in math class are going to be left at the store. 

I'm going to leave him to it. I've been using my DS1054Z happily for two years and never really noticed this huge elephant of a problem.

We here in former CCCP know all about that. Lada was considered pinnacle of automotive industry, noone had problem with it, many spent their lives (literally!) scraping the money together. It's normal when you have not used to anything better. And if someone says your Lada is crock of s*it cognitive dissonance kicks in. Eventually you gonna realize I'm right.

[Fungus]

We seem to have identified two quite different mindsets here 

Just out of curiosity, how "this is pseudoproblem" people manage to solve any problems more complex than risetime in efficient manner? Ok you zoomed in, you got your risetime. After that you have to zoom out to work on something else. That something else probably gets corrupted in malicious manner if the risetime is off.

a) Why would the rise time of a digital signal change? 

b) If I suspected signal integrity problems I might use one of the oscilloscope's signal integrity problem detection functions

What if there are 10 other params to monitor?

There aren't. Once I've seen a single rise time I usually don't need to monitor it visually.

I could ask you the same question: If your rise times are a problem then how will showing a number on screen help with that?

You need to zoom in to isolate the problem with your wires. Looking at it when it's zoomed out won't help at all.

[Fungus]

We here in former CCCP know all about that. Lada was considered pinnacle of automotive industry

No it wasn't. Everybody knew they were crap.

People only drove Ladas because that was all the government allowed them to have. Communism, remember?

Edit: Damn, I replied. That's the last one, I promise. You're on your own with this one, Wolfie. I simply don't care about it and you don't seem to be using your 'scope for real work.

Have you even seen the pass/fail detection modes of the DS1054Z? That's your varying rise time problem solved, right there.

[ebastler]

Eventually you gonna realize I'm right.

Yes, sure.

Or, of course, you might realize that quite a few of us simply don't care about this "issue" you have identified. I am not saying you are wrong; it might just have to do with different ways in which we are using our scopes. I have always considered a scope a "visual" instrument -- first and foremost I want to visually assess a signal on the display. The measurements are just an added convenience, and it would not occur to me to try and measure something which I cannot see clearly on the screen. Hence, taking measurements on the display data totally works for me. (While it might not work for you.)

Get that? Otherwise, have fun with your thread...

[Fungus]

it might just have to do with different ways in which we are using our scopes.

ie. We're using them to do real things, he isn't.

[tggzzz]

Summary...

1: choose the right instrument; I don't think a scope is the most appropriate instrument for the OPs' problem.

2: don't trust your equipment, don't trust your understanding of your equipment. Understand, then predict, then test each pieceyour equipment on a known signal, and repeat. If there is a discrepancy then either your equipment is faulty or your understanding is faulty; either way, you have learned something useful.

The OP has done 2 (that's good)and asked for our help. To me it seems that neither his equipment nor his understanding is fatally flawed. Instead this piece of equipment is behaving slightly unexpectedly in this circumstance.

That's fine; just avoid using this instrument in this way. People shouldn't make over general statements based on this experiment.

[MrWolf]

We here in former CCCP know all about that. Lada was considered pinnacle of automotive industry

No it wasn't. Everybody knew they were crap.

Have you lived in CCCP? Party had good trolls to convince everybody that they are living on the edge of possible. And 51% always believed. Noone works for half a life to get a car unless they think it's absolute best.

a) Why would the rise time of a digital signal change? 

Because you fiddled with wires on your proto and some inductance kicked in?

There aren't. Once I've seen a single rise time I usually don't need to monitor it visually.

Then you probably do some very basic digital stuff that does not involve motors, mechanics etc.

I could ask you the same question: If your rise times are a problem then how will showing a number on screen help with that?

1) zoom in to check visually, take note of auto-calculated values
2) zoom out to work on some more complex system, auto measurement will keep track of value to same accuracy as in zoomed in state
3) there is problem
4) check all auto-reading for match with point 1, if no match goto step 1, if match youre doing something wrong on more abstract level

If your scope does not support accuracy in zoomed out state you will going to have substantially more checking to do.

ie. We're using them to do real things, he isn't.

Fair remark. I had huge plans about what I'm gonna do with Z scope. But all the parts are just lying in the drawer because cultural shock was so heavy that I got interested in device itself more than my project  Guess some sort of "Stockholm syndrome". From tests collected so far it seems indeed in its own class unless some low-end Hantek or Owon outpixels it.

[Fungus]

a) If there's more than one rising edge on the screen (likely when zoomed out/looking at a "motor") then which rising edge should it display?

b) If you "fiddled with wires on your proto and some inductance kicked in" then you need to zoom in anyway. 

[MrWolf]

a) If there's more than one rising edge on the screen (likely when zoomed out/looking at a "motor") then which rising edge should it display?

Auto-measurements can track everything possible that has relevance to the functioning whole. Phases, timings, sensor firing jitter, voltages, currents, feedback function values. When you do a custom motor there will be loads of stuff that you need to monitor. When high inductance high Q coil gets wrong timing it can blow half your equipment into zombified state with EMF pulse.

b) If you "fiddled with wires on your proto and some inductance kicked in" then you need to zoom in anyway. 

Yes but you will know in the zoomed out state which param has gone off norm. If you know your project you will fiddle you wires again and it'll be ok without needing to zoom at all.

I'm beginning to see why theres sort of "conflict of worlds there". I have zero interest in purely digital stuff. Its forced necessity to run my physics experiments. We are viewing those measurement boxes from 180' phase angle

[nctnico]

We here in former CCCP know all about that. Lada was considered pinnacle of automotive industry

No it wasn't. Everybody knew they were crap.

The ones they exported where fine. Not very economic when it came to fuel consumption but very reliable especially compared to the French Simcas (which drew their outline with rust when you shut the door and provided my mother a new hobby involving putty, glass fiber sheet and spray paint) my parents owned before. My parent's first Lada even had a crank so you could start it manually through a hole in the front bumper. It was never needed. The second was a (IIRC) 2105 model station wagon. I'd like to drive that model again for old time's sake.

[MrWolf]

Did little checking around. Looks we have a potential winner in honesty contest  , its Tek:

Tek TBS2000 datasheet, page 7.
"Maximum duration of time captured at highest sample rate (all channels): 40 ms"
It's listed first in the horizontal system. Important stuff...

MDO4000C datasheet, page 21.
"Maximum duration at highest sample rate (all/half channels): <=500 MHz models and 1 GHz models (with option SA3 or SA6 and 4 channels enabled): 8/8 ms"

Aligns well with what's said here:

Note that on scopes like the Tek DPO/MSO/MDO series, measurements are always made on the full acquired record - not a subset of points used for display or measurement.  The user has control over the number of points being used (memory depth being used), and the display shows both the record length selection and the resulting sample rate for a given horizontal timebase setting.

Think it's important to learn from industry leaders how things are done properly. Low cost products should just have proportionally lower, not "sneaky" specs / operating logic. It's not a fish market...

[nctnico]

Note that on scopes like the Tek DPO/MSO/MDO series, measurements are always made on the full acquired record - not a subset of points used for display or measurement.  The user has control over the number of points being used (memory depth being used), and the display shows both the record length selection and the resulting sample rate for a given horizontal timebase setting.

Think it's important to learn from industry leaders how things are done properly. Low cost products should just have proportionally lower,

You keep ignoring Keysight uses the display data for measurements on scopes which sell for a little less than 6 figures. So there is no real proper way of doing things. As argued before there is very little use of measuring something in a waveform if you can't see the shape of a waveform. For example: there are tools like AC voltmeters and frequency counters to measure amplitude and frequency more accurately than you can do using an oscilloscope.

[MrWolf]

You keep ignoring Keysight uses the display data for measurements on scopes which sell for a little less than 6 figures. So there is no real proper way of doing things.

Well if Keysight measurements are in same ballpark as Teks and do not differ from accuracy that can be expected based on accepted theory (Real-Time Bandwidth = Sample rate / 2.5) then it's not a slightest concern for end user. However if Teks are more accurate then there is a proper way of doing things.

As argued before there is very little use of measuring something in a waveform if you can't see the shape of a waveform.

This can be argued only at the very basic level of task complexity. If user is unsure how many channels he wants, what project he will do etc it's not important indeed, especially if scope has good and professional looks. However as soon as mechanical / analog / digital domains gets mixed up it's different story. Scope becomes "instrument panel" for complex system where many params have to monitored at all times. I am personally very interested in various amateur tech projects that involve mechanics, have done some stuff myself and if I can be of some assistance to other interested parties - it all for the good cause. Currently end user cannot decide what is what based on specs listed for most scopes, which can and will lead to heavy disappointment...

For example: there are tools like AC voltmeters and frequency counters to measure amplitude and frequency more accurately than you can do using an oscilloscope.

Have been at the stage where I had my whole desk covered with multimeters. Moved on since.

[TheoB]

Proposals how to fix issues with problematic DSO models:

To display substantially erroneous readings w/o any indication about their standard deviation cannot be considered a good industry practice, especially when indicated sampling rate implies much higher precision of reading.

1) Near-zero cost proposal: Instead of "=", use "<=" before reading, since detecting reduced accuracy condition internally is trivial. Alternately switch the reading off (PicoTech DSOs do this).

I tried and the DS1054Z reports indeed >1.00kHz when the timebase is >=10ms. The build-in counter displays 1.000001kHz. For the risetime is reports 3.100us (too much digits I find). But from 20us/div it reports <3.400us (and for longer timebases <60.00us). Feels like a decent implementation to me. You are using the same scope right?

[MrWolf]

Feels like a decent implementation to me. You are using the same scope right?

Well it's a bit of a mess as will be shown below. Indeed it sometimes shows me signs (Edit: turns out sometimes they are wrong  ). But not in the useful view. Regular one-row reading is not useful because it gives no clue about standard deviation.

Signal generator: Siglent SDG2000X
Stored waveform: SquareDuty66
Frequency: 666.666666Hz
Amplitude: 1Vpp
Arb Mode: DDS (ensures 5ns rise)

Math check:
Period: 1.5ms
+Width: 0.99ms
-Width: 0.51ms

Sanity check 1: Agilent U1272A
Frequency: 666.67Hz
+Width: 0.98ms
-Width: 0.51ms
+Duty: 65.97%
-Duty: 34.04%
DC: 0.154V
TrueRMS AC: 0.4695V
TrueRMS AC+DC: 0.494V

Sanity check 2: Siglent SDG2000X (second one, not-clock-locked to first one)


DUT 1: Rigol DS1000Z (2016 model)
This one must be on some "flavoured electrons". Just look at it's confidence showing s.d. of zero. Cannot be delta-zeroed before test so DC average mesurements are off.

200 us/div:

Claimed: Sample rate: 1GS/s, Samples: 2.4M
Calculated: Sample rate: 125kS/s

Cycle time: 1.5ms s.d 0s
Frequency: 667Hz
+Width: 988us s.d. 0s
+Duty: 65.87% s.d. 0%
Rise: 8us s.d. 0s (correct "<" in "one line" mode)

Comment: "almost there" by humanitarian approach but fail compared to sample rate

10 ms/div:

Claimed: Sample rate: 50MS/s, Samples: 6M
Calculated:  Sample rate: 2.5kS/s

Cycle time: 1.4ms s.d. 0s
Frequency: 714Hz
True RMS: 489mV
AC RMS: ?
DC Average: 110mV
+Width: 800us s.d. 0% (wrong "<" in "one line" mode)
+Duty: 57.14% s.d. 0% (wrong "<" in "one line" mode)
Rise: 400us s.d. 0s (correct "<" in "one line" mode)

Comment: complete failure in horizontal measurements

DUT 2: PicoScope 2205 MSO (2013 model)
This old soapbox has only 48kS memory. So it really bogs down sample rate and it decides not to show rise.

200 us/div:

Sample interval: 130ns
Sample rate: 7.682MS/s
Samples: 15385

Cycle time: 1.5ms s.d. 63.98ns
Frequency: 666.7Hz s.d. 28.44mHz
+Width: 990.1us s.d 26.38ns
-Width: 509.9us s.d. 62.77ns
+Duty: 66.01% s.d. 0.003%
Rise: -

Comment: Spot on.

10 ms/div:

Sample interval: 2.04us
Sample rate: 490kS/S
Samples: 49020

Cycle time: 1.5ms s.d. 62.6ns
Frequency: 666.6Hz s.d. 27.83mHz
True RMS: 498.9mV s.d. 121uV
AC RMS: 474.8mV s.d. 61.96uV
DC Average: 153.3mV s.d. 313uV
+Width: 998.1us s.d. 79.9ns
+Duty: 66.67% s.d. 0%
Rise: -

Comment: +Width/+Duty wee bit off for my taste but nothing really embarrassing. Compares very well with Agilent U1272A in vertical measurements, both have been delta-zeroed before test.

[MrWolf]

New 2 channel test:

Signal on CH1: 6,660Hz
Signal on CH2: 6,660Hz...13,639,680Hz  in 6,660*2^n steps

General idea is to see how different frequencies scope can track at the same time on single timebase. "In the old days" this would have been solved by having dual-timebase scope. However it is shown that with large enough buffer for calculations it is no problem to keep automated track of quite different frequencies/periods.

DUT 1: Rigol DS1000Z, 1.2kpts/24Mpts "dual memory" scope:



DUT 2: PicoScope 2205 MSO, 48kpts "single memory" scope:



NB! Different Y-axis scale in "Absolute error %" graph. Full details in attached PDFs.

Interesting that from 106,650Hz to 852,480Hz Rigol "gains accuracy", probably has to do with buffer points dividing well with frequency.

[MrWolf]

Often it is said that not only Rigol DS1000Z / DS1054Z uses "screen" source for measurements but respectable manufacturers also. It occurred to me that perhaps only word "screen" is common and in fact it is just convenient boundary from where actual sample points are taken.

Examine video about Tek's new TBS2000:

https://www.youtube.com/watch?v=S51Jv8imskk&feature=youtu.be&t=1m40s

...and take close look to what is referred as "Gating".



Quote: "Gating determines, which sample points are used to calculate the measurement."

60Hz = ~16.6ms/cycle.
3.12MSa/s * 4ms = 12.48kS/div
12.48kS/div * 16divs = 199680kS ~=200kS
12.48kS/div * 15divs = 187.2kS (Screen)

So we see that "screen" is just convenient method for "gating" the actual sample points. It has nothing to do with 800px horizontal resolution of screen. As it should be, because to any UI specialist it is absurd concept to mix up real data and graphical representation, which is subject to many secondary effects and will totally destroy the accuracy.

[nctnico]

There are many ambiguous terms used when it comes to oscilloscopes. Take 'envelope mode' for example. On Japanese oscilloscopes it means peak-detect while Tektronix sees it as the minimum and maximum values for a number of consequtive sweeps.

Still you shouldn't be too concerned about accuracy on an oscilloscope because the error introduced by using the pixel position versus the real sample is way smaller than the error from the analog front-end and frequency response of the oscilloscope. Note that only DC accuracy is specified for oscilloscopes and I have never seen a graph for the amplitude and phase shift versus frequency in an oscilloscope's datasheet.

[MrWolf]

Note that only DC accuracy is specified for oscilloscopes and I have never seen a graph for the amplitude and phase shift versus frequency in an oscilloscope's datasheet.

Scopes I have been using are proven fully worthy of creating spec for horizontal measurement accuracy also. There are applications requiring large horizontal accuracy. I succsessfully do subnanosecond phase measurements with 25MHz analog bandwidth DSOs while not forced to keep "just right" timebase that fits one period. So perhaps it is time to change this convention dating to CROs I presume. Soon start working on a bit bigger project that perhaps will bring the change someday.

[Fungus]

Often it is said that not only Rigol DS1000Z / DS1054Z uses "screen" source for measurements but respectable manufacturers also. It occurred to me that perhaps only word "screen" is common and in fact it is just convenient boundary from where actual sample points are taken.

'Screen' is only a name for this.

The DS1054Z displays 600 pixels on screen. If you look in the programming manual the commands to grab sample data work with 1200 byte blocks. This gives us two samples per screen pixel and there's no reason to think the on-screen values wouldn't be computed using less than half-pixel resolution (maybe you could confirm that).

[MrWolf]

This gives us two samples per screen pixel and there's no reason to think the on-screen values wouldn't be computed using less than half-pixel resolution (maybe you could confirm that).

Practical horizontal resolution of 300 points (0.3kSa) for DS1000Z / DS1054Z was found by analyzing errors with phase auto-measurements on 12/11/16. Formula for calculating "screen sampling rate" at any given timebase was determined to be 1 / (timebase div / 25). Here you can download first test where reported and calculated sampling rates are compared against auto-calculated values. "Screen MS/s" means calculated "screen sampling rate" rate which is 5MSa/s at 5us/div.

After that did more perfected tests:
Signal gen test at 32768Hz: period is 30.518us, DS1000Z shows 30.5us at 5us/div
Arduino test at 32771Hz: period is 30.515us, DS1000Z shows 30.5us at 5us/div
These tests characterize all horizontal time-related auto-measurements. Measurements are totally off in all other timebases but the "prefect one"  - 5us/div for 32768Hz.

Reason why there is 1200pts is "peak-detection" which requires "2pts per pt". So in general saying that DS1054Z has 1.2kS buffer not being specific. For normal mode seems to be 600pts but some additional processing degrades it even further. Confirmed by "jumping" auto-cursors when tied to some horizontal measurement. So it ends up at having only 0.3kS buffer. I have yet not tested it but suspect even <$100 Owons have 5kS buffer for calculations. Suggestion to Rigol add option to use at least 4kS for calculations. Somehow they managed to upgrade FFT from "screen" to max 16kS from memory. So it is possible on current hardware. Yes this would lessen refresh rate but million times faster than forced to be "knob-monkey" and even then maxing out at "3-digits" horizontal.

In this post is loads of test data with various scopes, where it can be seen that not only all other tested scopes deliver good numbers at 5us, but also at much larger variation of timebases. Currently I'm working to get even more data from different scopes.

From example in 32768Hz test Gw Instek GDS1054B shows 30.51...30.52us on timebases from 5ns to 2ms. Only loses little accuracy at 5ms. (out of prod) PicoScope 2205 MSO shows constant 30.52us from 5us to 5ms.

With scope delivering "4-digit" horizontal accuracy over such wide range there is very little need to buy various additional hardware to complement and compensate because it not just "wiggly lines" but good accurate data. My personal goal is to identify at least "5-digit" horizontal scope or if not found develop according math for some functions.

[Fungus]

This gives us two samples per screen pixel and there's no reason to think the on-screen values wouldn't be computed using less than half-pixel resolution (maybe you could confirm that).

Measurements are totally off in all other timebases but the "prefect one"  - 5us/div for 32768Hz.

OK, so it looks like it is actual pixels, not half pixels. 

PS: Values like 30.4 and 30.6 are not "totally off" compared to a value of 30.5.

It's statements like that that make people think you're exaggerating.

[MrWolf]

OK, so it looks like it is actual pixels, not half pixels. 

Take note that sometimes discretization points will match to real values which gives impression of higher accuracy. Look "dual frequency" test - "artificial accuracy" 106,560Hz to 852,480Hz in absolute error % posted above. So you have to look the whole test to get the correct idea. Thats why doing test with one "too discrete" value is very bad idea (testing duty accuracy with 50% etc).

It's statements like that that make people think you're exaggerating.

How about 400us at 5ms? Where others show 30.52 +-0.01us?

In general this is question of engineering ethics. Sometimes boss is some humanitarian who only cares sales numbers. It is up to a tech people deliver better than customers know. If now other companies take note and see they can sell weird contraptions like this - engineers might be ordered to skip the effort - which will move accurate tech into "for scientific research" price class. Which would take away whole point of living in 21th century - having access to mindblowing T&M tech at burger prices.

So as general suggestion...

[Fungus]

How about 400us at 5ms?

I'd never measure a rise time at 5ms/div, so... 

Where others show 30.52 +-0.01us?

What 'others'? Have you made a comprehensive list?

[MrWolf]

I'd never measure a rise time at 5ms/div, so... 

Not rise, period. But I see why mixup:
32768Hz & 30.518us period - it thinks 400us rise, 300us period.
32771Hz & 30.515us period - it thinks 200us rise, 400us period.
Thats why I say do not draw conclusions from single "discrete value". Tiniest change may flip the coin.

What 'others'? Have you made a comprehensive list?

6 scopes so far here.

In due time there will be combined table.

[saturation]

As promised so long ago, Rigol 1052e 2009 edition unhacked

[MrW0lf]

Thanks, I had doubts - maybe DS1052E was better product than new DS1000Z in some areas. After all it was tied to Agilent, had ETS... But no... Calculus engine is quite primitive. If effective resolution of DS1000Z calculus seem to hover around 300pts horizontal, here it seems to changing between 100...200pts. So usage logic for auto-measurements pretty much the same - only in exact right timebase with single wfm occupying maximum possible screen area.

Rendered "standardized" PDF so it can easily compared to others. Please see if all ok. Skipped 500MSa/s measurements in smallest timebases because this test is mainly about showing absolute best that scope can do with measurements.

[saturation]

At least the auto measurements provided by the 1052e didn't mislead or lie to you; in the 1052e design still with a strong Agilent influence, the measurements shown to the user would be marked with some other symbol when the firmware decided the reported value was too off.  In the auto period measurement, what actually was shown was a flashing unstable <= sign beside the value.  So the lowly 1052e at least gave you its best shot and didn't mislead its users by reporting a measurement that was likely most erroneous [ which users could manually double check via cursors or a graticule/div measurement].

The measurements were hardly affected by the memory depth and sampling rate. 

The 1052e was released about 2008, and is ~> 9 yrs old.

Thanks, I had doubts - maybe DS1052E was better product than new DS1000Z in some areas...[/img]

[MrW0lf]

At least the auto measurements provided by the 1052e didn't mislead or lie to you;

Fair point, no argument there. I was more referring to technological principle of ultra low fidelity math as such. TBS1000 from same era has 2.5k mem per channel, probably calculates off the ~full record (at least FFT has 2k spec).

[ebastler]

I may have missed something. Are "MrWolf" and "MrW0lf" the same person? What gives?

[MrW0lf]

I may have missed something. Are "MrWolf" and "MrW0lf" the same person? What gives?

Could say thing or 2 on subject but better not, might get banned again Which would actually piss me off this time.

[Keysight DanielBogdanoff]

You keep ignoring Keysight uses the display data for measurements on scopes which sell for a little less than 6 figures. So there is no real proper way of doing things.

Well if Keysight measurements are in same ballpark as Teks and do not differ from accuracy that can be expected based on accepted theory (Real-Time Bandwidth = Sample rate / 2.5) then it's not a slightest concern for end user. However if Teks are more accurate then there is a proper way of doing things.

The InfiniiVision scopes do make their measurements based on the screen, so a lot of the time-sensitive measurements should be made when zoomed in appropriately. Vertical measurements are more about ADCs, ENOB, and vertical scaling (regardless of manufacturer).

It comes down to this: you should know your equipment, especially if a couple % points in accuracy make a big difference for you.

Regarding the acquisition data vs plotted data, it's really a matter of design philosophy. Making measurements on the acquisition memory has a cost in responsiveness.

[tggzzz]

It comes down to this: you should know your equipment, especially if a couple % points in accuracy make a big difference for you.

Just so; precisely.

I can't understand people that simply take any number at face value without wanting to know how it was generated and what the limits are. In the worst case you find it is one of the 37% of numbers that are simply made up on the spot to support the author's statements.

With instruments, any engineer will want to understand how their instrument interacts with their circuit. They will do initial tests on known circuits, change something in the circuit and/or instrument, and check that the results vary in the way the expect. If so, good, if not then they have learned something and avoided being mislead.

Regarding the acquisition data vs plotted data, it's really a matter of design philosophy. Making measurements on the acquisition memory has a cost in responsiveness.

Just so. Both philosophies is sound, provided they are stated and understood.

Personally I really like to see the instrument showing me how it calculate the magic number. For risetime that means four cursors showing the V,t of both points. I can then decide whether it is realistic.

[MrW0lf]

The InfiniiVision scopes do make their measurements based on the screen

By "based on screen" you mean "screen gating" or "screen pixels"? From ballpark calculations based on some videos *SOX3000T seem to deliver about 20kpts horizontal, which is much better than just "screen pixels". Maybe this is result of some averaging process? If yes it is still better than Rigol because with latter even averaging does not help.

Overall I have 2 main points:
- specify horizontal measurement accuracy of scopes in datasheet, then customer can choose based on need & application
- make it user configurable (gating etc). Probably in digital comms glitch hunt you need ultimate responsiveness, but when doing some analog/sensor/scientific/mechanics stuff accuracy is far more important

For multimeters you have pretty thick spec sheet for every possible measurement  Why not do it with scopes, currently just list "X different measurements"? I know, it is not done traditionally, but there is influx of >8bit scopes that easily rival many DMMs in accuracy...

[MrW0lf]

They will do initial tests on known circuits, change something in the circuit and/or instrument, and check that the results vary in the way the expect.

This is best done while checking against spec of instrument It may be quite expensive for employer when engineer has to map instrument performance, because there is no spec. Especially nasty if during mapping it turns out that instrument is no good for specific work...

Personally I really like to see the instrument showing me how it calculate the magic number. For risetime that means four cursors showing the V,t of both points. I can then decide whether it is realistic.

+1, in stats mode showing correct (!) s.d. would also help etc.

[tggzzz]

They will do initial tests on known circuits, change something in the circuit and/or instrument, and check that the results vary in the way the expect.

This is best done while checking against spec of instrument It may be quite expensive for employer when engineer has to map instrument performance, because there is no spec. Especially nasty if during mapping it turns out that instrument is no good for specific work...

That is a subset of what an engineer will do.

Even with a fully functional instrument with more than adequate performance, an engineer will test their understanding and how it interacts with the circuit.

Personally I really like to see the instrument showing me how it calculate the magic number. For risetime that means four cursors showing the V,t of both points. I can then decide whether it is realistic.

+1, in stats mode showing correct (!) s.d. would also help etc.

Stats are inherently difficult to verify. Great care, and very small steps are required.

[MrW0lf]

Even with a fully functional instrument with more than adequate performance, an engineer will test their understanding and how it interacts with the circuit.

Exactly, understanding (of staying within spec)! Engineer cannot be forced to create spec. Full spec for simplest instrument can be quite extensive. Following your logic there is no need for spec at all - just give engineer a "black box" and do not count on him for year until he is mapping the thing 

How long it would take to create in full detail, this small outtake from U1282A spec? Now sum individual time for each engineer that has the thing, each one individually spending time to spec it   

[Fungus]

Even with a fully functional instrument with more than adequate performance, an engineer will test their understanding and how it interacts with the circuit.

Exactly, understanding (of staying withing spec)! Engineer cannot be forced to create spec.

It all comes down to a simple rule: "Maximize the thing you're measuring on screen".

You can't tell us an engineer wouldn't do that for important measurements, that he'd sit around making a horizontal 'spec' instead and moaning about poor instruments if the numbers varied slightly. 

I assume you already do this for vertical measurements (all DACs have limited bits!) so why the massive problem with doing it for horizontal measurements? It's really the same thing.

To me it just seems totally natural to zoom in when looking at a rising edge.

Same for pulse widths. For me there was never an expectation in my head that pulse width measurements would be accurate when they're only half a dozen pixels wide on screen. It seems natural to hit zoom and maximize a single pulse on screen for measurement.

If we take a poll on whether this is an issue or not then you'll probably be in the minority. Maybe you could start one and find out. 

[MrW0lf]

If we take a poll on whether this is an issue or not then you'll probably be in the minority. Maybe you could start one and find out. 

Of course it's not issue if people do not know any better. Did snail mail users complain about letters arriving already on next day? I think it best not to get stuck in opinions here, better demonstrate some use cases not obvious to traditional scope user. Next week if all goes well.

[tggzzz]

Even with a fully functional instrument with more than adequate performance, an engineer will test their understanding and how it interacts with the circuit.

Exactly, understanding (of staying within spec)! Engineer cannot be forced to create spec. Full spec for simplest instrument can be quite extensive. Following your logic there is no need for spec at all - just give engineer a "black box" and do not count on him for year until he is mapping the thing 

Sigh. No, your extrapolation does not follow from my statement. Your extrapolation is no more than a strawman argument - and a silly one at that.

How long it would take to create in full detail, this small outtake from U1282A spec? Now sum individual time for each engineer that has the thing, each one individually spending time to spec it   

Don't be silly; silly statements merely hide any validity there might be in your other statements.

[MrW0lf]

  So what exactly is silly, mapping full spec to unspeced device? But mapping spec to partially unspeced device is ok? Is it at least ok in your opinion that U1282A has horizontal measurement spec or it is also silly because nobody uses DMM for horizontal stuff or something... ?
My story is pretty simple, spent 10x device cost in time/money equivalent to mapping "white areas" in certain scope performance just to discover it is not ok for my application (while it may perfectly ok for some other application!). Why is critical for customer to go thru this lottery-like process? IMHO this is silly to put mildly and it WILL change.

[Fungus]

So what exactly is silly

Let's see... 

it WILL change.

This ^

[MrW0lf]

While investigating 16bit Pico 5443A specs in other thread, developed irresistible itch to try out high-bit scope. 2408B is already on the way and I needed pattern gen anyway - so Analog Discovery 2.

First impressions: schowcase what can be done applying proper math to simplistic hardware.
Bandwidth only about 15MHz, but within that competes with 60k count DMM (U1282A), including vertical.

For starters did 32768Hz test.
Gen is Siglent SDG2000X, which has spec of +-1ppm@25C, jitter ~150ps RMS, rise ~9ns.

Calculated period 30.517578125us

Measured:
Agilent U1272A: 32768Hz
Keysight U1282A: 32769Hz
Second SDG2000X as counter: 32768.002Hz; 30.518us
AD2@10us/div: 32768.569013Hz; 30.517048199us

From that would rate AD2 at approx 100,000 count, 5digit horizontal +-2LSD (worst it did in later test was 30.516492940us).

9 digits after dp are of course bit excessive. But its meant as learning tool so probably useful to students to analyze effects of various settings on accuracy.

Risetime error aligns reasonably well with sampling rate and available memory (16k per ch).

No indication about reduced accuracy, which is bad. But there is no hidden trickery, so it can be assumed based on standard theory and sample rate.

32768Hz test PDF attached.

[MrW0lf]

PicoScope 2408B I'm reviewing in other thread:

In this case "classic" ~10ns rise 32768Hz test is not enough to reveal anything about calculation buffer size. It knows better, but still rounds everything down to 4digits at UI level. This is enough do show risetime in full detail down to 5ms timebase, but limits period accuracy (always 30.52us). I found a way to access "real deal" accuracy it hides - but it's a bit "hacking" and more suitable for using DSO directly as frequency/period/duty counter. Details later.

[rf-loop]

This is not tested using same parameters (I'm extremely busy, no time for follow some others tests exactly) as some previous tests but perhaps this still tell how different SDS1202X-E is compared to SDS1kX. (No mind to compare Rigol Z box)
In all images signal is same. Around 50ns wide pulses and frequency around 9MHz. Signal risetime around 9ns.
Last image only show that when zoom from 1ms/div to 1ns/div it measure from  whole length and not from zoomed part of memory (of course).



Example, from tests. (1ms/div, signal 9MHz, 50ns wide pulses and pulse risetime is around 9ns.
Other attached images same signal.

[rf-loop]

Here SDS1202X-E  32768Hz test result.

[MrW0lf]

Well behaved little puppy Folds at 2ms vs 200ns on DS1000Z. So about 5 orders of magnitude better Now all missing is test on some Owon...
But why X-E drops sample rate so suddenly at 5ms? I see its marked also in table.

[rf-loop]

I do not want makew this table for this scope.
But here some
Signal same what was with SDS1202X-E

XDS3kA do not have statistics so can not give min max

I give mutual average from numbers blinkig in measutrement.
For keep it not forced to 12 bit I keep 40M memory with all time bases.

5ms, 400MSa/s, rt ?, per?    (no result)

All next 1GSa/s
.2ms,  rt ?, per ?
.1ms,  rt ?, per?
500us, rt <10.000us, per 56.512us
200us, rt <4.000us, per 30.505us
100us, rt <2.000us, per 30.490us
.50us, rt <1.000us, per 30.542us
.20us, rt <400.0ns, per 30.533
.10us, rt <200.0ns, per 30.550
...5us, rt <100.0ns, per 30.550
...2us, rt <80.00ns, per ?   (period longer than display width)
...1us, rt <40.00ns, per ?
500ns, rt <20.00ns, per ?
200ns, rt 12.00ns, per ?
100ns, rt 7.000ns, per ?
..50ns, rt 8.000 / 9.000ns, per ?   / = visual pick up some very short time  min and max
..20ns, rt 7.600 / 8.400ns, per ? (notable trigger position time jitter, not very severe)
..10ns, rt 7.400 / 8.000ns, per ? (notable trigger position time jitter, not very severe)
....5ns, rt 7.500 / 8.000ns, per ? (notable trigger position time jitter, not very severe)
....2ns, rt 7.000 / 7.540ns, per ?
1ns (not in XDS3102A)