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

0 Members and 1 Guest are viewing this topic.

Offline MrWolfTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Testing DSO auto-measurements accuracy across timebases
« on: December 14, 2016, 05:33:36 pm »
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.

« Last Edit: January 10, 2017, 11:25:33 am by MrWolf »
 
The following users thanked this post: saturation

Offline MrWolfTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #1 on: December 14, 2016, 05:35:19 pm »
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.
« Last Edit: January 09, 2017, 05:16:21 pm by MrWolf »
 
The following users thanked this post: saturation, KrisztiƔn

Offline tautech

  • Super Contributor
  • ***
  • Posts: 28141
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #2 on: December 14, 2016, 06:09:09 pm »
The FW used in any DSO involved in these tests should also be listed.
Avid Rabid Hobbyist
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 

Online Fungus

  • Super Contributor
  • ***
  • Posts: 16561
  • Country: 00
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #3 on: December 14, 2016, 06:24:29 pm »
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.  :popcorn:
 

Offline MrWolfTopic starter

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

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.
 

Online Fungus

  • Super Contributor
  • ***
  • Posts: 16561
  • Country: 00
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #5 on: December 15, 2016, 06:15:03 am »
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.

« Last Edit: December 15, 2016, 06:25:43 am by Fungus »
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 28141
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #6 on: December 15, 2016, 09:30:20 am »
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.
Avid Rabid Hobbyist
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 
The following users thanked this post: MrWolf

Offline MrWolfTopic starter

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

Online Fungus

  • Super Contributor
  • ***
  • Posts: 16561
  • Country: 00
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #8 on: December 15, 2016, 11:26:20 am »
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)

 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 28141
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #9 on: December 15, 2016, 07:39:47 pm »
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.  :P

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

Quote
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.
:bullshit:
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.
Avid Rabid Hobbyist
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 
The following users thanked this post: MrWolf

Offline w2aew

  • Super Contributor
  • ***
  • Posts: 1780
  • Country: us
  • I usTa cuDnt speL enjinere, noW I aR wuN
    • My YouTube Channel
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #10 on: December 15, 2016, 10:23:02 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.  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).
YouTube channel: https://www.youtube.com/w2aew
FAE for Tektronix
Technical Coordinator for the ARRL Northern NJ Section
 
The following users thanked this post: saturation, MrWolf, BrianH_Tektronix

Offline MrWolfTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #11 on: December 15, 2016, 10:30:09 pm »
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
« Last Edit: December 16, 2016, 10:51:38 pm by MrWolf »
 

Offline tautech

  • Super Contributor
  • ***
  • Posts: 28141
  • Country: nz
  • Taupaki Technologies Ltd. Siglent Distributor NZ.
    • Taupaki Technologies Ltd.
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #12 on: December 16, 2016, 12:11:20 am »
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.  :scared:
Avid Rabid Hobbyist
Siglent Youtube channel: https://www.youtube.com/@SiglentVideo/videos
 

Offline MrWolfTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #13 on: December 16, 2016, 09:27:55 am »
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).
« Last Edit: December 16, 2016, 12:32:44 pm by MrWolf »
 

Online Fungus

  • Super Contributor
  • ***
  • Posts: 16561
  • Country: 00
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #14 on: December 16, 2016, 09:59:14 am »
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.   :popcorn:

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.

« Last Edit: December 16, 2016, 10:03:17 am by Fungus »
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #15 on: December 16, 2016, 10:03:30 am »
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?
 

Offline MrWolfTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #16 on: December 16, 2016, 10:30:49 am »
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
« Last Edit: December 16, 2016, 10:41:26 am by MrWolf »
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #17 on: December 16, 2016, 10:47:21 am »
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.
 

Offline MrWolfTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #18 on: December 16, 2016, 10:50:51 am »
The user has control

Gotta love proper oldschool engineering ;)
When I grow up gonna get MDO4000C...
 
The following users thanked this post: w2aew

Offline MrWolfTopic starter

  • Regular Contributor
  • *
  • !
  • Posts: 209
  • Country: ee
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #19 on: December 16, 2016, 10:55:29 am »
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.
« Last Edit: December 16, 2016, 11:00:06 am by MrWolf »
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #20 on: December 16, 2016, 11:15:30 am »
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.
 
The following users thanked this post: ebastler

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19281
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #21 on: December 16, 2016, 11:46:36 am »
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.
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
 
The following users thanked this post: ebastler

Online Fungus

  • Super Contributor
  • ***
  • Posts: 16561
  • Country: 00
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #22 on: December 16, 2016, 12:13:38 pm »
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.
 

Online Fungus

  • Super Contributor
  • ***
  • Posts: 16561
  • Country: 00
Re: Testing DSO auto-measurements accuracy across timebases
« Reply #23 on: December 16, 2016, 12:17:08 pm »
It's not about "making a mess" of your thread

His thread?  :-DD

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

Offline MrWolfTopic starter

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


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf