-
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.901Hz
Cycle time: 30.55us, s.d. 3.64ns
Arduino Uno R3:
Frequency: 32.77kHz, s.d. 5.369Hz
Cycle time: 30.52us, s.d. 4.998ns
Note 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 it
Edit: 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.
-
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.
Both 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?
-
OK, let me tell you a little secret about DSO's............Fine adjustment of V/div. (called Var (Variable) on a CRO)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).
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:
-
OK, let me tell you a little secret about DSO's............Fine adjustment of V/div. (called Var (Variable) on a CRO)
Not every DSO has it. Test mostly low end stuff here
Edit: 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?Trigger settings, easy with a DSO......push the level knob and it autosets to a 50% level.
Well 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 not Test any way you like while respecting core idea of the test which is to measure low frequency but precisely timed signal.
-
Surely a 1054Z has that ?OK, let me tell you a little secret about DSO's............Fine adjustment of V/div. (called Var (Variable) on a CRO)
Not every DSO has it. Test mostly low end stuff here
Push the V/div knob to get to fine adjustments.
You can see from the screenshots that both mine are ~130's mV/div -
Surely a 1054Z has that ?
Look previous post (edited), do not think it will give best possible vertical resolution.
-
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.
-
...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.
I 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.
-
With the other DSO but using DC coupling:
I 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. -
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.
Quite correct.
If part of the waveform is off-screen it does affect all auto measurements. -
Please 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.With the other DSO but using DC coupling:
I 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.
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...... -
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.
-
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/div
DC average: -402mV s.d. 2.61mV
Rise time: 9.06ns s.d. 104.3ps
+-10V (2V/div), DC coupling, 4GS/s ETS, 5ns/div
DC average: 2.096V s.d. 4.651mV
Rise time: 9.239ns s.d. 103.6ps
+-5V (1V/div), AC coupling, 900MS/s ETS, 1us/div
DC average: 3.474mV s.d. 2.043mV
Rise time: 9.097ns s.d. 547.3ps
+-10V (2V/div), DC coupling, 900MS/s ETS, 1 us/div
DC average: 2.514V s.d. 2.142mV
Rise time 9.248ns s.d. 540.6ps
Note 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).
-
Now you've got us chasing our tails.
Aren't the tests @ 1V p-p ? -
Now you've got us chasing our tails.
Aren't the tests @ 1V p-p ?
Arduino 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 correctly DC 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
-
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.
Both 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?
Thus illustrating why people still swear by and pay good money for old equipment they know and trust
(Lights blue touchpaper and retires )
-
Now you've got us chasing our tails.
A friendly word of advice: stop wasting your time on this. It is really not worth it because it is not a real issue. Tektronix already wrote a ridiculous bash-note about it comparing their scopes with Agilent's. -
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.
-
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.
-
So a LeCroy Wavejet does it, too?
This thread is now officially
-
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 [Utility]
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.
-
1054B prelim data
I'll spot check the accuracy and repost if changes required
-
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.
Thank you for helping humanity in struggle against crap programming. I can confirm that it shows Wavejet as being honest scope and not doing secondary buffering. Operator can assume ballpark precision at any point based on reported sampling rate
Difference with Pico is that Pico sniffs trouble and switches reading off, Wavejet just soldiers on. -
Final Results
No changes except the labels marked in yellow.
-
Final Results
Seems 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 operation
First 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.