Author Topic: Testing DSO auto-measurements accuracy across timebases  (Read 34530 times)

0 Members and 1 Guest are viewing this topic.

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26754
  • Country: nl
    • NCT Developments
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #75 on: December 21, 2016, 02:40:30 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline MrWolfTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #76 on: December 21, 2016, 02:57:24 pm »
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.
« Last Edit: December 21, 2016, 02:59:20 pm by MrWolf »
 

Offline TheoB

  • Regular Contributor
  • *
  • Posts: 62
  • Country: nl
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #77 on: December 21, 2016, 05:36:42 pm »
Quote
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?
 

Offline MrWolfTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #78 on: December 21, 2016, 08:50:25 pm »
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.

« Last Edit: December 27, 2016, 06:47:52 pm by MrWolf »
 

Offline MrWolfTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #79 on: December 27, 2016, 05:15:19 pm »
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.
« Last Edit: December 27, 2016, 08:06:43 pm by MrWolf »
 

Offline MrWolfTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #80 on: January 09, 2017, 03:11:51 pm »
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.
« Last Edit: January 09, 2017, 03:16:01 pm by MrWolf »
 
The following users thanked this post: saturation

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26754
  • Country: nl
    • NCT Developments
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #81 on: January 09, 2017, 03:27:03 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline MrWolfTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #82 on: January 09, 2017, 03:31:55 pm »
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.
« Last Edit: January 09, 2017, 03:37:15 pm by MrWolf »
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16561
  • Country: 00
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #83 on: January 09, 2017, 04:18:04 pm »
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).

 

Offline MrWolfTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #84 on: January 09, 2017, 04:58:24 pm »
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.
« Last Edit: January 09, 2017, 06:51:00 pm by MrWolf »
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16561
  • Country: 00
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #85 on: January 09, 2017, 06:54:06 pm »
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.

 

Offline MrWolfTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #86 on: January 09, 2017, 07:24:56 pm »
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...



« Last Edit: January 09, 2017, 07:58:13 pm by MrWolf »
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 16561
  • Country: 00
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #87 on: January 09, 2017, 08:03:15 pm »
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?
« Last Edit: January 09, 2017, 08:08:58 pm by Fungus »
 

Offline MrWolfTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #88 on: January 09, 2017, 08:46:08 pm »
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.
 
The following users thanked this post: saturation

Offline saturation

  • Super Contributor
  • ***
  • Posts: 4787
  • Country: us
  • Doveryai, no proveryai
    • NIST
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #89 on: February 23, 2017, 12:17:56 am »
As promised so long ago, Rigol 1052e 2009 edition unhacked
« Last Edit: February 23, 2017, 11:55:11 am by saturation »
Best Wishes,

 Saturation
 
The following users thanked this post: MrW0lf

Offline MrW0lf

  • Frequent Contributor
  • **
  • Posts: 922
  • Country: ee
    • lab!fyi
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #90 on: February 23, 2017, 09:30:15 am »
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.

« Last Edit: February 23, 2017, 09:55:45 am by MrW0lf »
 

Offline saturation

  • Super Contributor
  • ***
  • Posts: 4787
  • Country: us
  • Doveryai, no proveryai
    • NIST
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #91 on: February 23, 2017, 02:40:42 pm »
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]
Best Wishes,

 Saturation
 

Offline MrW0lf

  • Frequent Contributor
  • **
  • Posts: 922
  • Country: ee
    • lab!fyi
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #92 on: February 23, 2017, 02:55:56 pm »
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).
« Last Edit: February 23, 2017, 03:04:47 pm by MrW0lf »
 

Online ebastler

  • Super Contributor
  • ***
  • Posts: 6202
  • Country: de
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #93 on: February 23, 2017, 03:06:38 pm »
I may have missed something. Are "MrWolf" and "MrW0lf" the same person? What gives?
 

Offline MrW0lf

  • Frequent Contributor
  • **
  • Posts: 922
  • Country: ee
    • lab!fyi
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #94 on: February 23, 2017, 03:26:18 pm »
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.
 

Offline Keysight DanielBogdanoff

  • Supporter
  • ****
  • Posts: 777
  • Country: us
  • ALL THE SCOPES!
    • Keysight Scopes YouTube channel
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #95 on: February 24, 2017, 04:49:59 am »
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.
 
The following users thanked this post: newbrain

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #96 on: February 24, 2017, 09:59:11 am »
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.

Quote
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline MrW0lf

  • Frequent Contributor
  • **
  • Posts: 922
  • Country: ee
    • lab!fyi
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #97 on: February 24, 2017, 10:02:34 am »
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...


« Last Edit: February 24, 2017, 10:17:04 am by MrW0lf »
 

Offline MrW0lf

  • Frequent Contributor
  • **
  • Posts: 922
  • Country: ee
    • lab!fyi
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #98 on: February 24, 2017, 10:24:10 am »
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.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #99 on: February 24, 2017, 10:30:43 am »
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.

Quote
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.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf