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.5Reality 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 procedureSignal 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.xlsBlank for printing w/o automated graphs:
DSO_auto_measurements_test_for_printing__v1_1.pdfProposals 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 lineHaving "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.