Testing DSO auto-measurements accuracy across timebases - Page 1
Forum section: electronics / testgear

author: MrWolf
author_rank: Regular Contributor
timestamp: December 14, 2016, 05:33:36 pm
content: Besides visual inspection of waveform shape digital storage oscilloscopes also offerwide variety of automated measurements. Usually DSOs are compared based onanalog bandwidthandsampling 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 andcan be compared to "4-digit" or "10,000 count" in multimeter world. For example at 20us/div horizontal setting 48kS oscilloscope can giveaccurate frequency/period for frequencies at least 2000 times aparton 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, andcompletely 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 9nsfor signal, calculated RTBW400MHz.Timebase=500us/div,1GS/s(reported by scope), calculatesrisetime 20usfor same signal, RTBW still 400MHz but seems more like15kHz!?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 testis 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 waveDuty 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)Couplingif 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 5msValues to write down to test table:Timebase(horizontal setting ns/div)Sampling ratereported by DSO in MSa/sLeading edge risetimemin,avg,max (ns)Signal periodmin,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.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 14, 2016, 05:35:19 pm
content: 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  after changing timebase!It sort of resets stats on timebase change but Min, Max may get weird values. Pressing  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.

author: tautech
author_rank: Super Contributor
timestamp: December 14, 2016, 06:09:09 pm
content: The FW used in any DSO involved in these tests should also be listed.

author: Fungus
author_rank: Super Contributor
timestamp: December 14, 2016, 06:24:29 pm
content: 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.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 14, 2016, 07:24:25 pm
content: Quote from: Fungus on December 14, 2016, 06:24:29 pmPlease 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 preciseautomatedmeasurement 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.

author: Fungus
author_rank: Super Contributor
timestamp: December 15, 2016, 06:15:03 am
content: Quote from: MrWolf on December 14, 2016, 07:24:25 pmNo you haven't. The stats for things like 'minimum' and 'maximum' aresupposedto remember the, um, minimum and maximum values they've seen until you reset them.It's correct behavior.

author: tautech
author_rank: Super Contributor
timestamp: December 15, 2016, 09:30:20 am
content: 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 fileRange tested.......what's this?Chart itself:Memory MS/s ? ? ? ?Should this be Sampling as in M or G Sa/sorMemory 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.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 15, 2016, 10:49:05 am
content: Quote from: tautech on December 15, 2016, 09:30:20 amVertical setting (V/div)I'm not native english speaker so there might be slight wording issuesBut please look newmuch improved quality Rigol test attached to second post, there it is evident what is meant for every box.Quote from: tautech on December 15, 2016, 09:30:20 amSampling rate MSa/s. Mem depth is probably not important since samplingrate and timebase will suggest minimal depth.I will update charts to clear it up soon.Updated, download from thread's first post.

author: Fungus
author_rank: Super Contributor
timestamp: December 15, 2016, 11:26:20 am
content: Quote from: tautech on December 15, 2016, 09:30:20 amI'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 prefermorewrongness if I have a choice - make the wrong value stand out as much as possible)

author: tautech
author_rank: Super Contributor
timestamp: December 15, 2016, 07:39:47 pm
content: Quote from: Fungus on December 15, 2016, 11:26:20 amWe do this exerciseproperlyor not at all.QuoteThere is, for the 2 I've checked, the entry level unit being lower.QuoteProper 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.

author: w2aew
author_rank: Super Contributor
timestamp: December 15, 2016, 10:23:02 pm
content: 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).

author: MrWolf
author_rank: Regular Contributor
timestamp: December 15, 2016, 10:30:09 pm
content: Have receivedstrictorders 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

author: tautech
author_rank: Super Contributor
timestamp: December 16, 2016, 12:11:20 am
content: Quote from: MrWolf on December 15, 2016, 10:30:09 pmInteresting, 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.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 16, 2016, 09:27:55 am
content: Quote from: tautech on December 16, 2016, 12:11:20 amBecause:- 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 comparableEdit: actual experiment:Pico 2205 (2010 model):Measuring risetime 90/10% from Arduino2V/div, DC coupling: 8.941ns s.d. 131ps1V/div, AC coupling: 8.945ns s.d. 109psSo 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).

author: Fungus
author_rank: Super Contributor
timestamp: December 16, 2016, 09:59:14 am
content: I wonder where the GW-Instek fanboys are?Usually they're the first to jump intoanythread and tell us how amazing and perfect and bug-free their 'scopes are. I'm beginning to wonder if they're covering something up.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.

author: Howardlong
author_rank: Super Contributor
timestamp: December 16, 2016, 10:03:30 am
content: Quote from: w2aew on December 15, 2016, 10:23:02 pmAlanFirstly 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?

author: MrWolf
author_rank: Regular Contributor
timestamp: December 16, 2016, 10:30:49 am
content: Quote from: Howardlong on December 16, 2016, 10:03:30 amGood rise time on signal is mainly here to ensure low trigger jitter. What is most revealing isperiodmeasurements. 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

author: Howardlong
author_rank: Super Contributor
timestamp: December 16, 2016, 10:47:21 am
content: Quote from: MrWolf on December 16, 2016, 10:30:49 amNo, 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.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 16, 2016, 10:50:51 am
content: Quote from: w2aew on December 15, 2016, 10:23:02 pmGotta love proper oldschool engineeringWhen I grow up gonna get MDO4000C...

author: MrWolf
author_rank: Regular Contributor
timestamp: December 16, 2016, 10:55:29 am
content: Quote from: Howardlong on December 16, 2016, 10:47:21 amI'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?Quote from: Howardlong on December 16, 2016, 10:47:21 amMoreover, "Wolfs test" will revealundocumentedlimitations of scope in 10 minutes. Without weeks trial-and-error poking around in random circuits.

author: Howardlong
author_rank: Super Contributor
timestamp: December 16, 2016, 11:15:30 am
content: Quote from: MrWolf on December 16, 2016, 10:55:29 amRespectfully, 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, willvery oftenmean 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.

author: tggzzz
author_rank: Super Contributor
timestamp: December 16, 2016, 11:46:36 am
content: Quote from: MrWolf on December 16, 2016, 10:55:29 amIn 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.

author: Fungus
author_rank: Super Contributor
timestamp: December 16, 2016, 12:13:38 pm
content: Quote from: MrWolf on December 16, 2016, 10:55:29 amSo 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 ityourway is pointless.

author: Fungus
author_rank: Super Contributor
timestamp: December 16, 2016, 12:17:08 pm
content: Quote from: Howardlong on December 16, 2016, 11:15:30 amHisthread?Quote from: Howardlong on December 16, 2016, 11:15:30 amIt'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).

author: MrWolf
author_rank: Regular Contributor
timestamp: December 16, 2016, 12:20:20 pm
content: Quote from: Howardlong on December 16, 2016, 11:15:30 amInitially 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 youcannotmeasure automatically (why? think time-varying signals) on specific instrument, despite "headline figures" indicating it would do just fine?Quote from: Howardlong on December 16, 2016, 11:15:30 am...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.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 16, 2016, 12:25:52 pm
content: Since it's getting too philosophical... Did use lunch pause to go to store and buy brand new Arduino Uno R3. Yesterday code was tested on Uno R1. Seems that all crystals are not created equal:Pico 2205 @ 5us/div & 100MS/s (10 ns sampling interval)Arduino Uno R1:Frequency: 32.73kHz, s.d. 3.901HzCycle time: 30.55us, s.d. 3.64nsArduino Uno R3:Frequency: 32.77kHz, s.d. 5.369HzCycle time: 30.52us, s.d. 4.998nsNote that Uno R3 has much more precise crystal. Crystal aligns "too well" with 10ns sample interval and Pico clock, which gives larger 4.998ns standard deviation. No dithering - no enchanced resolution! Textbook stuff, gotta love itEdit: Confirmed with 3 different hw counters:Uno R1:32.734176 kHz (Siglent SDG2000X)32.734 kHz (Agilent U1272A)32.7345 kHz (Rigol DS1000Z)Risetime 5ns, jitter +-100ps (Rigol DS1000Z)Uno R3:32.770604 kHz (Siglent SDG2000X)32.771 kHz (Agilent U1272A)32.771 kHz (Rigol DS1000Z)Risetime 4ns, fall 6ns, jitter +-100ps (Rigol DS1000Z)Quite possibly R3s also differ. Measure yours with hardware counter if you have one and change "Frequency" to correct one in test form.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 16, 2016, 12:41:28 pm
content: Quote from: tggzzz on December 16, 2016, 11:46:36 amBoth valid points. But on the other hand it is to be expected even from scope to deliver according to its sampling rate and memory. Especially important if you are budget-limited and cannot buy special tool for every task. Better one of my old scopes had 200MSa/s (non-ETS) and 48kS memory. New has 1GSa/s and 24M. Yet does not deliver even as old one. With all due respect - WTF?

author: tautech
author_rank: Super Contributor
timestamp: December 16, 2016, 02:02:37 pm
content: Quote from: MrWolf on December 16, 2016, 09:27:55 amOK, let me tell you a little secret about DSO's............Fine adjustment of V/div. (called Var (Variable) on a CRO)So we want to measure risetimes...........done by having the rising edge amplitude EXCEEDING the 10 and 90% graticules. From one step to the next V/div it is very common to exceed the displayed area with too much amplitude or too little to do so. I guess in my case it's a throwback from the days I spent with CRO's where you had to use the graticules for this measurement and I still set up a scope in this old manner when wanting risetime measurements.Probably dumb I know.....just how I do it but even with the first DSO's I had (Tek TDS2012B) measurement accuracy was setting dependant.However I can't remember a time ever where I've needed AC coupling for risetime measurements for the work that I've done with scopes.Trigger settings, easy with a DSO......push the level knob and it autosets to a 50% level.AC coupling for these tests...........nah, not at 1V p-p levels.But here's a AC coupled screenshot anyway:With the other DSO but using DC coupling:

author: MrWolf
author_rank: Regular Contributor
timestamp: December 16, 2016, 02:13:20 pm
content: Quote from: tautech on December 16, 2016, 02:02:37 pmNot every DSO has it. Test mostly low end stuff hereEdit: also - wouldnt it be just moving pixels around on DSO w/o proper hardware DC offset? With AC coupling you get full 8bits vertical. Operating on half of the vertical (no matters where pixels are moved) would downgrade to 7 or less bits, no?Quote from: tautech on December 16, 2016, 02:02:37 pmWell one more operation... if done wrong, will affect triggering seriously and may introduce jitter which will ruin the test.If something is done across wildly variable tech and user base should minimize variables whenever possible.But if you know your stuff - why notTest any way you like while respecting core idea of the test which is to measure low frequency but precisely timed signal.

author: tautech
author_rank: Super Contributor
timestamp: December 16, 2016, 02:19:59 pm
content: Quote from: MrWolf on December 16, 2016, 02:13:20 pmSurely a 1054Z has that ?Push the V/div knob to get to fine adjustments.You can see from the screenshots that both mine are ~130's mV/div

author: MrWolf
author_rank: Regular Contributor
timestamp: December 16, 2016, 02:25:06 pm
content: Quote from: tautech on December 16, 2016, 02:19:59 pmLook previous post (edited), do not think it will give best possible vertical resolution.

author: w2aew
author_rank: Super Contributor
timestamp: December 16, 2016, 02:28:28 pm
content: Another factor that you need to consider for accurate rise/fall time measurements is the scope's interpretation of the 0 and 100% levels. Waveform artifacts such as overshoot, ringing, droop, settling duration, etc. can all affect the rise/fall measurements because they can affect how the scope determines what it will use for the 0 and 100% levels. If you adjust the timebase to zoom in on the edge, you might not get accurate 0 and 100% levels because they'll not be included in the waveform being measured.

author: Fungus
author_rank: Super Contributor
timestamp: December 16, 2016, 02:31:34 pm
content: Quote from: MrWolf on December 16, 2016, 12:20:20 pmI don't think anybody disagrees that it could be improved. The disagreement is whether it's a real problem or not.The fact that you're the first person to make a lot of noise about would suggest that it isn't a big problem in real life usage.

author: Howardlong
author_rank: Super Contributor
timestamp: December 16, 2016, 02:35:20 pm
content: Quote from: tautech on December 16, 2016, 02:02:37 pmI might have misunderstood what's being shown here, but is that second one measuring off screen? If it isn't, it's not going to give an accurate rise time result as you need to have a stable start and end. As shown, it's not at its final rest position (to properly calculate the 90% voltage) and there could be overshoot in the displayed trace (although I doubt the is any looking at the waveform in this case!)That's why (in my opinion) you need to measure your rise time with reasonable visibility of what's really going on at the transition.FWIW AC coupling is a valid scenario for measuring, for example, PCIe and TMDS with single ended probes where there may be significant relative DC common mode offset, but the signal itself is coded with differential DC balance (i.e. equal numbers of zeros and ones over time). Not that you'd be measuring PCIe and TMDS with the scopes we're discussing of course ;-) but there are also slower and longer distance communications technologies with DC balance encoding where you might find an application for it at this level.

author: tautech
author_rank: Super Contributor
timestamp: December 16, 2016, 02:38:20 pm
content: Quote from: w2aew on December 16, 2016, 02:28:28 pmQuite correct.If part of the waveform is off-screen it does affect all auto measurements.

author: tautech
author_rank: Super Contributor
timestamp: December 16, 2016, 02:48:14 pm
content: Quote from: Howardlong on December 16, 2016, 02:35:20 pmPlease be assured Howard that any instability in the waveform IS adjusted so that it's outside the risetime graticules, not that it should make much difference to a DSO. Sanity check is measurements are what I've routinely had from my SDG1010 AWG over some years now.Just also realised I did not have the graticule brightness set to max as is needed in these Siglents to show up well on screenshots.I'll come back with a better pic in an edit soon......

author: tautech
author_rank: Super Contributor
timestamp: December 16, 2016, 03:13:12 pm
content: As already seen of Wolf's 1054 tests there are settings where there is some accuracy for both measurements but more cycles are needed on the display for Period measurements to be more accurate, conversely less cycles for Risetime measurements to be accurate.My initial results also confirm this to be so.This screenshot shows the timebase setting that's the best compromise for accuracy of both.SDS2304X Dot mode.Trace and Graticule @ 100% brightness.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 16, 2016, 03:19:41 pm
content: Since natural sciences are about experimentation...Let's mutilate my poor old 2010 model 25MHz Pico with 5ns riser from Arduino.2205 does not have true DC offset much like DS1000Z AFAIK.+-5V (1V/div), AC coupling, 4GS/s ETS, 5ns/divDC average: -402mV s.d. 2.61mVRise time: 9.06ns s.d. 104.3ps+-10V (2V/div), DC coupling, 4GS/s ETS, 5ns/divDC average: 2.096V s.d. 4.651mVRise time: 9.239ns s.d. 103.6ps+-5V (1V/div), AC coupling, 900MS/s ETS, 1us/divDC average: 3.474mV s.d. 2.043mVRise time: 9.097ns s.d. 547.3ps+-10V (2V/div), DC coupling, 900MS/s ETS, 1 us/divDC average: 2.514V s.d. 2.142mVRise time 9.248ns s.d. 540.6psNote waveform general look and placement on screen is same AC vs DC mode = controls were operated correctly.I can see lost precision (look s.d.) due to less vertical bits in "simulated DC offset mode" and DC values are seriously affected in small timebases (=zoom from large timebase on DS1000Z due to screen buffer based processing).

author: tautech
author_rank: Super Contributor
timestamp: December 16, 2016, 03:27:28 pm
content: Now you've got us chasing our tails.Aren't the tests @ 1V p-p ?

author: MrWolf
author_rank: Regular Contributor
timestamp: December 16, 2016, 03:30:42 pm
content: Quote from: tautech on December 16, 2016, 03:27:28 pmArduino is 5V DC device. Also input voltage does not affect results if signal to volts/div ratio is in same ballpark. I'm interested in Arduino because every punk can have it for couple of bucks and run the test at any location.BTW I did NOT operate controls correctlyDC trigger is at 2V, not 2.5V.New pics shortly.Edit:New pics and data in original post. Looks like DC vs AC coupling significantly affect rise measurements on "simulated DC offset" scopes.To experimentally validate "chasing tails" claim will run Arduino test on DS1000Z. Meanwhile gotta eat and get beatings from wife cause I'm "stuck at work" suspiciously long

author: tggzzz
author_rank: Super Contributor
timestamp: December 16, 2016, 05:32:45 pm
content: Quote from: MrWolf on December 16, 2016, 12:41:28 pmThus illustrating why people still swear by and pay good money for old equipment they know and trust(Lights blue touchpaper and retires)

author: nctnico
author_rank: Super Contributor
timestamp: December 16, 2016, 06:00:14 pm
content: Quote from: tautech on December 16, 2016, 03:27:28 pmA friendly word of advice: stop wasting your time on this. It is really not worth it because it is not a real issue. Tektronix already wrote a ridiculous bash-note about it comparing their scopes with Agilent's.

author: saturation
author_rank: Super Contributor
timestamp: December 16, 2016, 07:26:15 pm
content: The 1054B analyzes the input buffer but needs ~ 2 graticules peak to peak and for very slow waveforms, like 60 Hz, a time base showing as least one full period, after which very little difference occurs in automated measurements; measurements change mostly to the sampling rate and chosen memory depth.The default auto measurements are on the entire buffer, but it can be user selected to the screen or between cursor regions.There is no algorithm to mark that the sample size is insufficient for measurement, as was mentioned for many Tek DSOs.What I do is cross check an automated Vpp against a visual Vpp on the graticule. Then derived calculations such as RMS are then as expected.A threshold for when the calculations start to deviate and that the sampling or waveform size is insufficient can be seen when a previous stable value sudden varies widely or is unstable, and as an index the standard deviation abruptly rises on the new settings compared to the prior stable value.You can improve the measurement by filtering away noise and averaging the tracing.Since Wolf's test will demonstrate how this works I'll or have someone work on this and post.

author: jpb
author_rank: Super Contributor
timestamp: December 16, 2016, 08:24:17 pm
content: I don't quite know what it shows other than the Wavejet is a very straight forward scope so as the sample rate drops due to memory limitations the rise time calculation goes haywire.Anyway, attached is the results for the LeCroy Wavejet, probably not quite warmed up when I started. It does min and max but not average (you can of course measure averaged waveforms but you can't average directly measurements from non-averaged waveforms).The minimum values all seem a bit out which is an interesting quirk. The spec for the rise time (Agillent 33522A) is 8.4 nsecs. By setting 5 nsec/div, Equiv time sampling(100GS/s) and 256 point averaging I get a very smooth curve with the rise time of 8.32x nsecs where the x digit varies but the min is 8.181 and the max 8.367 but I think both of these are outliers.I attach the spreadsheet.

author: Fungus
author_rank: Super Contributor
timestamp: December 16, 2016, 08:48:41 pm
content: So a LeCroy Wavejet does it, too?This thread is now officially

author: MrWolf
author_rank: Regular Contributor
timestamp: December 16, 2016, 09:56:06 pm
content: Tested DS1000Z for AC vs DC coupling. Moving wfm up and down with vertical control do not change abs voltages or auto-readings. Did not test for movement limits. Switching between AC and DC in same vertical range and moving wfm to middle with vertical yield exactly same results. So dunno what it's doing but it do not seem to be actual analog DC offset and not old Pico style system either.If someone has full understand what it's doing or know a post about this please give ref.Just FYI that there is also weird stuff called VerticalRef.=Ground|Center under Here's little talk about it:https://www.eevblog.com/forum/testgear/rigol-ds1054z-vertical-pain-in-the-ass/Bottom line - since readings are not affected it's not important which coupling to use on DS1000Z.May vary with other scopes.Another more interesting matter. Arduino seems to kick out quite sharp edges. Measuring them with 10x probe with ground clip attached is no-go. Since output on pin ~9 and ground are nearby I managed to hook probe spring ground using some bent wires. Much less ringing, rise is 4ns, fall is 6ns according to DS1000Z. Images attached:Setup with spring hook; rise with regular ground lead; rise with spring; fall with spring.Also tested if 10ns edge could be generated with Arduino.Easy: about 300ohms in series. Stick resistor staright in. 10x probe/scope provides C.Compared to signal gen results: No difference despite 1V vs 5V.Theory that only thing that matters is signal height in bits is correct. Makes sense since test is about digital artefacts not analog front end.Also there was no difference 4ns rise vs 10ns rise starting at 200ns/div and larger timebase on DS1000Z. Again because digital artefacts overwhelm analog frontend.But just for the record gonna run the test with Arduino. Very good tool for the job.

author: saturation
author_rank: Super Contributor
timestamp: December 16, 2016, 09:59:39 pm
content: 1054B prelim dataI'll spot check the accuracy and repost if changes required

author: MrWolf
author_rank: Regular Contributor
timestamp: December 16, 2016, 10:04:27 pm
content: Quote from: jpb on December 16, 2016, 08:24:17 pmThank you for helping humanity in struggle against crap programming. I can confirm that it shows Wavejet as being honest scope andnotdoing secondary buffering. Operator can assume ballpark precision at any point based on reported sampling rateDifference with Pico is that Pico sniffs trouble and switches reading off, Wavejet just soldiers on.

author: saturation
author_rank: Super Contributor
timestamp: December 17, 2016, 12:58:29 am
content: Final ResultsNo changes except the labels marked in yellow.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 17, 2016, 09:18:15 am
content: Quote from: saturation on December 17, 2016, 12:58:29 amSeems that buffer kicks in only at 200us (for risetime), so it must be quite large. Period good on all timebases. At extreme 5ms, does it give any hint that accuracy is reduced or just displays result as usual? Overall good scope, cannot see any serious issues with it for normal operationFirst time I see that scope can do such long period (that does not fit on the screen) measurement on small timebases. So it must be processing full memory record all the time <200us timebase. Actually quite logical thing to do on DSO. Engineers must have been thinking making this one.

author: Howardlong
author_rank: Super Contributor
timestamp: December 17, 2016, 10:33:23 am
content: Quote from: nctnico on December 16, 2016, 06:00:14 pmRegrettably 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!

author: MrWolf
author_rank: Regular Contributor
timestamp: December 17, 2016, 05:39:56 pm
content: Nice move with tautech comment out of contextBut 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.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 18, 2016, 02:06:23 pm
content: 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.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 18, 2016, 02:40:59 pm
content: Since it is accepted theory that scopeReal-Time Bandwidth = Sample rate / 2.5and 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.pdf2) 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.pdf3) 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.pdfAlso 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 yourpurchasing 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.

author: saturation
author_rank: Super Contributor
timestamp: December 18, 2016, 03:20:38 pm
content: 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?

author: MrWolf
author_rank: Regular Contributor
timestamp: December 19, 2016, 09:51:25 am
content: Quote from: saturation on December 18, 2016, 03:20:38 pmAppreciate! 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.

author: Fungus
author_rank: Super Contributor
timestamp: December 19, 2016, 11:06:52 am
content: 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.

author: rf-loop
author_rank: Super Contributor
timestamp: December 19, 2016, 11:24:31 am
content: 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 isNOT 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

author: MrWolf
author_rank: Regular Contributor
timestamp: December 19, 2016, 11:47:27 am
content: Quote from: rf-loop on December 19, 2016, 11:24:31 amNo 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.

author: Fungus
author_rank: Super Contributor
timestamp: December 19, 2016, 11:58:57 am
content: Quote from: rf-loop on December 19, 2016, 11:24:31 amI don't accept it as abug. 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).

author: MrWolf
author_rank: Regular Contributor
timestamp: December 19, 2016, 12:16:03 pm
content: Quote from: Fungus on December 19, 2016, 11:58:57 amSeems simple but may fire back as pointed out byw2aew here.Did small test on it: same wavefront seen at5ns/divand1us/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.

author: rf-loop
author_rank: Super Contributor
timestamp: December 19, 2016, 04:46:38 pm
content: Quote from: Fungus on December 19, 2016, 11:58:57 amMy comment was for MrWolf...Sorry it looks like comment for you in timeline.

author: rf-loop
author_rank: Super Contributor
timestamp: December 19, 2016, 04:48:16 pm
content: ´

author: Fungus
author_rank: Super Contributor
timestamp: December 19, 2016, 05:27:20 pm
content: Quote from: rf-loop on December 19, 2016, 04:46:38 pmSo was mine.Quote from: MrWolf on December 17, 2016, 05:39:56 pmWolfie 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.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 19, 2016, 06:00:28 pm
content: We seem to have identified two quite different mindsets hereJust 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 thereI'm gonna expect these kinds of possibilites fromanyscope fromanymanufacturer. 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.Quote from: Fungus on December 19, 2016, 05:27:20 pmWe 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.

author: Fungus
author_rank: Super Contributor
timestamp: December 19, 2016, 06:19:08 pm
content: Quote from: MrWolf on December 19, 2016, 06:00:28 pma) 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 functionsQuote from: MrWolf on December 19, 2016, 06:00:28 pmThere 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.

author: Fungus
author_rank: Super Contributor
timestamp: December 19, 2016, 06:25:25 pm
content: Quote from: MrWolf on December 19, 2016, 06:00:28 pmNo 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.

author: ebastler
author_rank: Super Contributor
timestamp: December 19, 2016, 06:26:03 pm
content: Quote from: MrWolf on December 19, 2016, 06:00:28 pmYes, 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...

author: Fungus
author_rank: Super Contributor
timestamp: December 19, 2016, 06:29:56 pm
content: Quote from: ebastler on December 19, 2016, 06:26:03 pmie. We're using them to do real things, he isn't.

author: tggzzz
author_rank: Super Contributor
timestamp: December 19, 2016, 06:38:05 pm
content: 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 testeach 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. Insteadthispiece of equipment is behaving slightly unexpectedly in this circumstance.That's fine; just avoid usingthisinstrument inthisway. People shouldn't make over general statements based on this experiment.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 19, 2016, 06:55:09 pm
content: Quote from: Fungus on December 19, 2016, 06:25:25 pmHave 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.Quote from: Fungus on December 19, 2016, 06:19:08 pmBecause you fiddled with wires on your proto and some inductance kicked in?Quote from: Fungus on December 19, 2016, 06:19:08 pmThen you probably do some very basic digital stuff that does not involve motors, mechanics etc.Quote from: Fungus on December 19, 2016, 06:19:08 pm1) zoom in to check visually, take note of auto-calculated values2) zoom out to work on some more complex system, auto measurement will keep track of value to same accuracy as in zoomed in state3) there is problem4) check all auto-reading for match with point 1, if no match goto step 1, if match youre doing something wrong on more abstract levelIf your scope does not support accuracy in zoomed out state you will going to have substantially more checking to do.Quote from: Fungus on December 19, 2016, 06:29:56 pmFair 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 projectGuess 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.

author: Fungus
author_rank: Super Contributor
timestamp: December 19, 2016, 07:04:10 pm
content: 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.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 19, 2016, 07:23:07 pm
content: Quote from: Fungus on December 19, 2016, 07:04:10 pmAuto-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 beloadsof 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.Quote from: Fungus on December 19, 2016, 07:04:10 pmYes 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

author: nctnico
author_rank: Super Contributor
timestamp: December 19, 2016, 11:15:45 pm
content: Quote from: Fungus on December 19, 2016, 06:25:25 pmThe 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.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 21, 2016, 02:29:46 pm
content: 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 listedfirstin 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:Quote from: w2aew on December 15, 2016, 10:23:02 pmThink it's important to learn from industry leaders how things are doneproperly. Low cost products should just have proportionally lower, not "sneaky" specs / operating logic. It's not a fish market...

author: nctnico
author_rank: Super Contributor
timestamp: December 21, 2016, 02:40:30 pm
content: Quote from: MrWolf on December 21, 2016, 02:29:46 pmYou 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.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 21, 2016, 02:57:24 pm
content: Quote from: nctnico on December 21, 2016, 02:40:30 pmWell if Keysight measurements are in same ballpark as Teks anddo not differfrom 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 thereisa proper way of doing things.Quote from: nctnico on December 21, 2016, 02:40:30 pmThis 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 monitoredat 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...Quote from: nctnico on December 21, 2016, 02:40:30 pmHave been at the stage where I had my whole desk covered with multimeters. Moved on since.

author: TheoB
author_rank: Regular Contributor
timestamp: December 21, 2016, 05:36:42 pm
content: QuoteI 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?

author: MrWolf
author_rank: Regular Contributor
timestamp: December 21, 2016, 08:50:25 pm
content: Quote from: TheoB on December 21, 2016, 05:36:42 pmWell 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 SDG2000XStored waveform: SquareDuty66Frequency: 666.666666HzAmplitude: 1VppArb Mode: DDS (ensures 5ns rise)Math check:Period: 1.5ms+Width: 0.99ms-Width: 0.51msSanity check 1:Agilent U1272AFrequency:666.67Hz+Width:0.98ms-Width: 0.51ms+Duty:65.97%-Duty: 34.04%DC: 0.154VTrueRMS AC: 0.4695VTrueRMS AC+DC: 0.494VSanity 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.4MCalculated: Sample rate: 125kS/sCycle time:1.5mss.d0sFrequency:667Hz+Width:988uss.d.0s+Duty:65.87%s.d.0%Rise:8uss.d.0s(correct "<" in "one line" mode)Comment: "almost there" by humanitarian approach but fail compared to sample rate10 ms/div:Claimed: Sample rate: 50MS/s, Samples: 6MCalculated: Sample rate: 2.5kS/sCycle time:1.4mss.d.0sFrequency:714HzTrue RMS: 489mVAC RMS: ?DC Average: 110mV+Width:800uss.d.0%(wrong "<" in "one line" mode)+Duty:57.14%s.d.0%(wrong "<" in "one line" mode)Rise: 400uss.d.0s(correct "<" in "one line" mode)Comment: complete failure in horizontal measurementsDUT 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: 130nsSample rate: 7.682MS/sSamples: 15385Cycle time:1.5mss.d. 63.98nsFrequency:666.7Hzs.d. 28.44mHz+Width:990.1uss.d 26.38ns-Width:509.9uss.d. 62.77ns+Duty:66.01%s.d. 0.003%Rise: -Comment: Spot on.10 ms/div:Sample interval: 2.04usSample rate: 490kS/SSamples: 49020Cycle time:1.5mss.d. 62.6nsFrequency:666.6Hzs.d. 27.83mHzTrue RMS: 498.9mV s.d. 121uVAC RMS: 474.8mV s.d. 61.96uVDC Average: 153.3mV s.d. 313uV+Width:998.1uss.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.

author: MrWolf
author_rank: Regular Contributor
timestamp: December 27, 2016, 05:15:19 pm
content: New 2 channel test:Signal on CH1:6,660HzSignal on CH2:6,660Hz...13,639,680Hzin6,660*2^nstepsGeneral idea is to see how different frequencies scope can track at the same time onsingle timebase. "In the old days" this would have been solved by havingdual-timebasescope. 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.

author: MrWolf
author_rank: Regular Contributor
timestamp: January 09, 2017, 03:11:51 pm
content: 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 whereactual sample pointsare 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: "Gatingdetermines, whichsample pointsare used to calculate the measurement."60Hz = ~16.6ms/cycle.3.12MSa/s * 4ms = 12.48kS/div12.48kS/div * 16divs = 199680kS ~=200kS12.48kS/div * 15divs =187.2kS(Screen)So we see that "screen" is just convenient method for "gating" theactual 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.

author: nctnico
author_rank: Super Contributor
timestamp: January 09, 2017, 03:27:03 pm
content: 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.

author: MrWolf
author_rank: Regular Contributor
timestamp: January 09, 2017, 03:31:55 pm
content: Quote from: nctnico on January 09, 2017, 03:27:03 pmScopes 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.

author: Fungus
author_rank: Super Contributor
timestamp: January 09, 2017, 04:18:04 pm
content: Quote from: MrWolf on January 09, 2017, 03:11:51 pm'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).

author: MrWolf
author_rank: Regular Contributor
timestamp: January 09, 2017, 04:58:24 pm
content: Quote from: Fungus on January 09, 2017, 04:18:04 pmPractical horizontal resolution of 300 points (0.3kSa) for DS1000Z / DS1054Z was found byanalyzing errors with phase auto-measurements on 12/11/16. Formula for calculating "screen sampling rate" at any given timebase was determined to be1 / (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/divArduino test at 32771Hz: period is 30.515us, DS1000Z shows 30.5us at 5us/divThese tests characterizeallhorizontal 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 itis possibleon 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 datawith 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 in32768Hz test Gw Instek GDS1054Bshows 30.51...30.52us on timebases from 5ns to 2ms. Only loses little accuracy at 5ms. (out of prod)PicoScope 2205 MSO showsconstant30.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.

author: Fungus
author_rank: Super Contributor
timestamp: January 09, 2017, 06:54:06 pm
content: Quote from: MrWolf on January 09, 2017, 04:58:24 pmOK, so it looks like it is actual pixels, not half pixels.PS: Values like 30.4 and 30.6 arenot"totally off" compared to a value of 30.5.It's statements like that that make people think you're exaggerating.

author: MrWolf
author_rank: Regular Contributor
timestamp: January 09, 2017, 07:24:56 pm
content: Quote from: Fungus on January 09, 2017, 06:54:06 pmTake 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).Quote from: Fungus on January 09, 2017, 06:54:06 pmHow 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...

author: Fungus
author_rank: Super Contributor
timestamp: January 09, 2017, 08:03:15 pm
content: Quote from: MrWolf on January 09, 2017, 07:24:56 pmI'd never measure a rise time at 5ms/div, so...Quote from: MrWolf on January 09, 2017, 07:24:56 pmWhat 'others'? Have you made a comprehensive list?

author: MrWolf
author_rank: Regular Contributor
timestamp: January 09, 2017, 08:46:08 pm
content: Quote from: Fungus on January 09, 2017, 08:03:15 pmNot 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.Quote from: Fungus on January 09, 2017, 08:03:15 pm6 scopes so far here.In due time there will be combined table.

author: saturation
author_rank: Super Contributor
timestamp: February 23, 2017, 12:17:56 am
content: As promised so long ago, Rigol 1052e 2009 edition unhacked

author: MrW0lf
author_rank: Frequent Contributor
timestamp: February 23, 2017, 09:30:15 am
content: 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" PDFso 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.

author: saturation
author_rank: Super Contributor
timestamp: February 23, 2017, 02:40:42 pm
content: 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.Quote from: MrW0lf on February 23, 2017, 09:30:15 am

author: MrW0lf
author_rank: Frequent Contributor
timestamp: February 23, 2017, 02:55:56 pm
content: Quote from: saturation on February 23, 2017, 02:40:42 pmFair 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).

author: ebastler
author_rank: Super Contributor
timestamp: February 23, 2017, 03:06:38 pm
content: I may have missed something. Are "MrWolf" and "MrW0lf" the same person? What gives?

author: MrW0lf
author_rank: Frequent Contributor
timestamp: February 23, 2017, 03:26:18 pm
content: Quote from: ebastler on February 23, 2017, 03:06:38 pmCould say thing or 2 on subject but better not, might get banned againWhich would actually piss me off this time.

author: Keysight DanielBogdanoff
author_rank: Unknown
timestamp: February 24, 2017, 04:49:59 am
content: Quote from: MrWolf on December 21, 2016, 02:57:24 pmThe 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.

author: tggzzz
author_rank: Super Contributor
timestamp: February 24, 2017, 09:59:11 am
content: Quote from: Keysight_DanielBogdanoff on February 24, 2017, 04:49:59 amJust so; precisely.I can't understand people that simply takeanynumber 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, anyengineerwill 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.QuoteJust so. Both philosophies is sound, provided they are stated and understood.Personally Ireallylike to see the instrument showing mehowit calculate the magic number. For risetime that means four cursors showing the V,t of both points.Ican then decide whether it is realistic.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: February 24, 2017, 10:02:34 am
content: Quote from: Keysight_DanielBogdanoff on February 24, 2017, 04:49:59 amBy "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 importantFor multimeters you have pretty thick spec sheet for every possible measurementWhy not do it with scopes, currently just list "X different measurements"? I know, it is not donetraditionally, but there is influx of >8bit scopes that easily rival many DMMs in accuracy...

author: MrW0lf
author_rank: Frequent Contributor
timestamp: February 24, 2017, 10:24:10 am
content: Quote from: tggzzz on February 24, 2017, 09:59:11 amThis is best done while checking against spec of instrumentIt 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...Quote from: tggzzz on February 24, 2017, 09:59:11 am+1, in stats mode showing correct (!) s.d. would also help etc.

author: tggzzz
author_rank: Super Contributor
timestamp: February 24, 2017, 10:30:43 am
content: Quote from: MrW0lf on February 24, 2017, 10:24:10 amThat is a subset of what anengineerwill 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.QuoteStats are inherently difficult to verify. Great care, and very small steps are required.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: February 24, 2017, 10:45:52 am
content: Quote from: tggzzz on February 24, 2017, 10:30:43 amExactly, understanding (of staying within spec)! Engineer cannot be forced tocreatespec. Full spec for simplest instrument can be quite extensive. Following your logic there is no need for spec at all - just giveengineera "black box" and do not count on him for year until he is mapping the thingHow long it would take to create infull 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

author: Fungus
author_rank: Super Contributor
timestamp: February 24, 2017, 11:15:08 am
content: Quote from: MrW0lf on February 24, 2017, 10:45:52 amIt 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.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: February 24, 2017, 11:41:13 am
content: Quote from: Fungus on February 24, 2017, 11:15:08 amOf course it's not issue if people do not know any better. Did snail mail users complain about letters arrivingalreadyon 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.

author: tggzzz
author_rank: Super Contributor
timestamp: February 24, 2017, 11:52:15 am
content: Quote from: MrW0lf on February 24, 2017, 10:45:52 amSigh. No, your extrapolationdoes notfollow from my statement. Your extrapolation is no more than a strawman argument - and a silly one at that.QuoteDon't be silly; silly statements merely hide any validity there might be in your other statements.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: February 24, 2017, 01:28:50 pm
content: 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 formy application(while it may perfectly ok for some other application!). Why is critical for customer to go thru this lottery-like process? IMHOthisis silly to put mildly and it WILL change.

author: Fungus
author_rank: Super Contributor
timestamp: February 24, 2017, 04:11:33 pm
content: Quote from: MrW0lf on February 24, 2017, 01:28:50 pmLet's see...Quote from: MrW0lf on February 24, 2017, 01:28:50 pmThis ^

author: MrW0lf
author_rank: Frequent Contributor
timestamp: February 26, 2017, 01:26:58 pm
content: While investigating16bit Pico 5443Aspecs inother thread, developed irresistible itch to try out high-bit scope. 2408B is already on the way and I needed pattern gen anyway - soAnalog 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 did32768Hz test.Gen is Siglent SDG2000X, which hasspec of +-1ppm@25C, jitter ~150ps RMS, rise ~9ns.Calculated period 30.517578125usMeasured:Agilent U1272A: 32768HzKeysight U1282A: 32769HzSecond SDG2000X as counter: 32768.002Hz; 30.518usAD2@10us/div: 32768.569013Hz; 30.517048199usFrom 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.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: March 07, 2017, 08:45:29 pm
content: PicoScope 2408BI'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.

author: rf-loop
author_rank: Super Contributor
timestamp: May 10, 2017, 10:17:05 am
content: 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 differentSDS1202X-Eis 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.

author: rf-loop
author_rank: Super Contributor
timestamp: August 09, 2017, 01:42:37 pm
content: Here SDS1202X-E 32768Hz test result.

author: MrW0lf
author_rank: Frequent Contributor
timestamp: August 09, 2017, 02:21:47 pm
content: Well behaved little puppyFolds at 2ms vs 200ns on DS1000Z. So about 5 orders of magnitude betterNow 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.

author: rf-loop
author_rank: Super Contributor
timestamp: August 09, 2017, 05:25:20 pm
content: I do not want makew this table for this scope.But here someSignal same what was with SDS1202X-EXDS3kA do not have statistics so can not give min maxI 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.512us200us, rt <4.000us, per 30.505us100us, 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)