Testing DSO auto-measurements accuracy across timebases

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