Testing DSO auto-measurements accuracy across timebases

[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)