-
Rigol DS1054z -- How to get _maximum_ Positive Slew rate?
Posted by DoubleDang on 05 May, 2016 02:00 -
Hey everyone!
I want to find the maximum positive slew rate after a trigger, not just the slew rate of the screen or within the cursor. (i.e. I want to find the maximum value of the first derivative of the line).
I tried:- The "Positive SlewRate" horizontal measure: It doesn't find the maximum, it's just an average over the area it's calculating so this isn't useful.
- The Cursor, both "Auto" and "Track". "Auto" has the same problem that the +Rate above does, and "Track" requires me to eyeball the maximum (not useful when I have to get hundreds of these measurements quickly).
- The Math "Diff" function. Ideally I would be able to find the derivative of the line and just take the maximum value, however the "Diff" function seems to be either broken or has a horribly coarse granularity.
Here's a screencap of using the Cursor Tracking, which seems to be the best but still isn't correct, and definitely is not efficient since I have to get hundreds of these readings (also, there's an annoying bug where if you "CursorAB" track, the distance between your cursors will fluctuate):
And here's a screencap of the Math Diff function. It's showing 400kV (disregard the incorrect unit, I'm not sure if you can change it), which is not only way off, but also the next step in this granularity is 800kV, so it's nowhere near precise enough for my purposes:
Is it possible to get the max positive slew, or am I slewed?
Thanks for any who read or respond!
UPDATE:QuoteYep, a Peak Slew rate measurement is missing for the menus and I'm not sure I've ever seen one.
This is the simple answer I was looking for (and hoping not to see). Too bad this function is missing from the scope, seems to me like it would be pretty useful. In a followup post I'll update more info, but I figured I would put this here for others to see.
UPDATE 2:
Comparing with a considerably more expensive Tek scope I was able to compare math Diff functions, and determined that the Rigol DS1054z's Diff function seems unusable at best. To be fair, we're talking a $400 scope vs a $40,000 (?) scope. -
Hey everyone!
Welcome to the forum.QuoteI want to find the maximum positive slew rate after a trigger, not just the slew rate of the screen or within the cursor. (i.e. I want to find the maximum value of the first derivative of the line).
Do you mean Peak Slew rate?
I think you do.QuoteI tried:
Yep, a Peak Slew rate measurement is missing for the menus and I'm not sure I've ever seen one.- The "Positive SlewRate" horizontal measure: It doesn't find the maximum, it's just an average over the area it's calculating so this isn't useful.
- The Cursor, both "Auto" and "Track". "Auto" has the same problem that the +Rate above does, and "Track" requires me to eyeball the maximum (not useful when I have to get hundreds of these measurements quickly).
- The Math "Diff" function. Ideally I would be able to find the derivative of the line and just take the maximum value, however the "Diff" function seems to be either broken or has a horribly coarse granularity.
QuoteAnd here's a screencap of the Math Diff function. It's showing 400kV (disregard the incorrect unit, I'm not sure if you can change it), which is not only way off, .....
What incorrect unit, it's showing KV/s.
Google slew rate units of measurement
https://en.wikipedia.org/wiki/Slew_rateQuoteIn electronics, slew rate is defined as the rate of change of voltage per unit of time. Expressed in SI units, the unit of measurement is Volts/second.
QuoteIs it possible to get the
Good question, try careful trigger and cursor settings, maybe with AC input coupling in order to get the waveform measurement commencing at the crossing point of trigger and cursor settings.maxpeak positive slew, or am I slewed?
Let us know how you get on.
-
What incorrect unit, it's showing KV/s.
Why incorrect - if you slew 1V in a us then you could express that as 1000kV/s, 1MV/s, 1000V/ms - they are all the same. Not necessarily equally useful but all valid as far as I can see.
I'm not clear why the Y axis is labelled in mA?
Also - stupid question I know, but does "diff" on these 'scopes mean "differentiate" or "difference"? -
Differentiate, i think, as the difference between two signals is "A - B"
-
What incorrect unit, it's showing KV/s.
Why incorrect - if you slew 1V in a us then you could express that as 1000kV/s, 1MV/s, 1000V/ms - they are all the same. Not necessarily equally useful but all valid as far as I can see.
I'm not clear why the Y axis is labelled in mA?
Also - stupid question I know, but does "diff" on these 'scopes mean "differentiate" or "difference"?
The Y axis is labelled in mA because the user has selected "A" for Amps in the Units selection in the Channel menu. Perhaps he is monitoring the Vdrop across a current viewing resistor and has also selected the appropriate "probe multiplier" setting so that the scope displays the correct Current value corresponding to the Vdrop across his CVR.
Since the Channel's Units are set to "A" (amps) in the Channel menu, one would expect this Units selection to propagate to all measurements based on the Channel's selection. For example, if Math is used to multiply a Voltage channel by an Amps channel one would like to see the Units of the result in W for Watts. So in this case the Slew Rate measurement should appear in Units of A/s not V/s. This is a bug I've noted before, and in the latest firmware it seems to be (sometimes) fixed, in that Math will at least display units of "W" for Watts when multiplying channels set to "V" and "A" units. The OP's scope doesn't seem to be running the latest firmware since there are only three pages of Horizontal Measurements available. See my screenshot below. You can see that the Units have correctly propagated to the Measurements (Math units are "W" for Watts, Slew Rate for CH2 units are kA/s).
But you seriously have to consider whether this bugfix is worth actually upgrading to the latest firmware SP2, since it introduces other bugs that may not be acceptable to the individual user.
And as you can see in the Statistics display the measurement of Slew Rate is all over the place, varying by 150 kA/S out of a max of 880 kA/S while reading the scope's calibrator output which is generally pretty stable.
"Diff" means differentiate, it is a single channel measurement. To find the difference between two signals on different channels one uses Math, A-B.
-
Incidentally.... the "Diff" Math measurement is seriously buggy. The differential of a signal should be the instantaneous slope of that signal, if I recall my calculus properly. As can be seen in the OP's screenshot the "diff" trace is unintelligible. Here are some examples from my scope. Only the last shot shows a reasonable "differential" indicating the slope of the signal.
-
Incidentally.... the "Diff" Math measurement is seriously buggy. The differential of a signal should be the instantaneous slope of that signal, if I recall my calculus properly. As can be seen in the OP's screenshot the "diff" trace is unintelligible. Here are some examples from my scope. Only the last shot shows a reasonable "differential" indicating the slope of the signal.
I wouldn't call that "buggy". I would call it "so ridiculously simplistic as to be unusable". It looks like some averaging/smoothing between samples is required.
(Having said that, everytime the word "average" is used it really ought to be accompanied by the definition of "averaging interval" (ditto "smooth"). After all, my average heart rate is infinitesimally above zero.) -
Yep, that's right, unusable.
But playing around a little more, I see that buried deep within the Math menus there is a setting called "Smooth" which changes things quite a bit. I'm still not sure if it makes the measurements actually usable but at least the qualitative display is improved.
See the scopeshots below, where I am in "normal" acquire mode, "auto" memory depth, and varying only the "Smooth" value, which gives an allowable range from 3 to 201.
(except in the last two where I've changed the vertical Math scale to 500 MV/s per div; the "Auto Scale" button doesn't seem to do anything that I can see)
The amplitude of the "Diff" waveform changes drastically depending on the "Smooth" setting. So one can apparently select whatever value one likes for this "measurement".
"What did I expect, it's only 400 dollars".....
(And.... I just had a total lockup freeze, total non-response to any controls and frozen waveform display, while trying to set the "Start" and "End" points of the Math.... have to power cycle the scope to get it working again.....
)
-
But playing around a little more, I see that buried deep within the Math menus there is a setting called "Smooth" which changes things quite a bit. I'm still not sure if it makes the measurements actually usable but at least the qualitative display is improved.
Actually the manual mentions it (page 6-16).
It mentions the "Smooth" option available for the Diff operation, and on page 6-17 there's a tip box suggesting to use the Average acquisition mode when possible, as differentiation is inherently sensitive to noise.
Actually, Smooth is only available for differentiation.
-
But playing around a little more, I see that buried deep within the Math menus there is a setting called "Smooth" which changes things quite a bit. I'm still not sure if it makes the measurements actually usable but at least the qualitative display is improved.
Actually the manual mentions it (page 6-16).
It mentions the "Smooth" option available for the Diff operation, and on page 6-17 there's a tip box suggesting to use the Average acquisition mode when possible, as differentiation is inherently sensitive to noise.
Actually, Smooth is only available for differentiation.
Thanks... I missed that in the manual, I guess. I couldn't tell any difference between "Normal" and "Average" acquire modes though, even with a large number of averages selected, so I made all the scopeshots above with "Normal" mode and "Auto" memory depth.
I noticed also that the amplitude of the Diff trace varies with timebase settings too. So how does one get a valid numerical value for the Diff measurement, if the amplitude varies according to the Smooth setting and the timebase, and isn't synched with the input channel trace at high Smooth settings?
-
Hey thanks for the welcome Tautech, and thanks for the the answers everyone! Great community you have here.
Tautech, you're right I am definitely looking for the Peak Slew Rate
, and I'm sad to hear that there's no simple function to tell me this. Oh well, I'll have to find it a different way.[...] So in this case the Slew Rate measurement should appear in Units of A/s not V/s. This is a bug I've noted before, and in the latest firmware it seems to be (sometimes) fixed, [...]
As for the units, I'm looking for current -- kA/s. I'm using a current probe, and I've changed the unit of my channel to [A]mps, but as alsetalokin4017 points out my firmware is an older version (04.03, not either of the SPs) so apparently the labeling is incorrect, however the actual measurement values are fine so it's mostly a moot point. I don't think I want to risk updating the firmware as I've read this is irreversible on the DS1054z.
Alsetalokin4017and Tggzzzpoint out that the DS1054Z's math Diff function is seriously unusable. Too bad. Thanks for the scopeshots alsetalokin4017! That has been really good to see someone else's scopeshots at a later firmware, which show the same problems I'm having with it now. It's not just me
The amplitude of the "Diff" waveform changes drastically depending on the "Smooth" setting. So one can apparently select whatever value one likes for this "measurement".
That has been my experience as well. I can get the Diff waveform to look "right" like a derivative, but the values are basically garbage as best I can tell. Nothing I can use for the actual takeaway values I need.
Super nice Tek Scope comparison!
So check it out. I got my hands on a super nice Tek scope with another current probe to see the difference. With just some basic fiddling I got exactly what I was looking for. Note "M1" which is "DIFF(Ch4)" -- the same function we're attempting on the DS1054z, and also note the circled "M1: Max" measurement -- exactly what I'm looking for!!:
That peak value on Tek's Math Diff is what I'm looking for -- peak positive slew.[...] differentiation is inherently sensitive to noise.
Totally right. On the Tek, I started with a scope screen full of noise, and had to dial down the sampling rate (among a few other tricks) to get a usable curve. So I should just be able to apply smoothing and averaging on the Rigol to get the same value, but...I noticed also that the amplitude of the Diff trace varies with timebase settings too.
I noticed this too, and this is not something that happened on the Tek scope. On the Tek there was a ton of noise, but there was still an underlying curve to the madness (sorry, wish I had a screenshot pre-averaging). Changing the timebase or averaging\smoothing did not fundamentally change the values on the Tek but did on the Rigol. This leads me to believe that the Diff function on the Rigol is beyond unusable and is simply bugged. However, I'm still all ears if there's a specific setting I'm missing!
Thanks again everyone, I'll update again if I figure out a solution for the Rigol DS1054z math Diff. -
The situation is even worse for the DS/MSO4000 series with the current firmware -- there isn't even the "smooth" function on these machines and even tests like diff(intg(ch1)) for example, which should provide a super-smooth and monotonic input to the derivative function ends up in useless output! On the other hand, the two operations reversed intg(diff(ch1)) results at least in a waveform that resembles the original shape-wise even though the amplitude doesn't stay the same.
High sample-count averaging or "high res" mode tends to help a little, but still the result isn't usable.
What really surprised me is that even at high frequency measurements and if display mode is changed to dots (i.e. you get the individual samples displayed, see attached screenshots -- btw, I didn't resample between the two shots, and just turning from vector to dots display changed the result of the derivative...), the derivative "toggles" between the individual samples from zero to one or minus one "increment" -- for what reason? There isn't any data available there. It appears the resolution of the variables used for calculating the derivative was by far not sufficient. I really would like to know what the Rigol engineers smoked before they programmed this complete and utter crap! The more time I spend with the Rigol gear, the more disappointed I get about the "details"... I hope the long time since the last firmware update from Rigol is used to seriously address these shortcomings.
Cheers,
Thomas
-
... buried deep within the ... menus ...
A standard "issue" with complex digitising scopes (and many other complex instruments).Quote... I'm still not sure if it makes the measurements actually usable but at least the qualitative display is improved.
With any instrument you have to convince yourself that you understand what it is doing; ideally it is doing what you actually want it to do.
But the prettiness of the display is an irrelevant distraction. Unfortunately too many people are distracted.Quote[with smoothing] one can apparently select whatever value one likes for this "measurement".
Just like my example of smoothing/averaging and heart rate!Quote"What did I expect, it's only 400 dollars".....
(And.... I just had a total lockup freeze, total non-response to any controls and frozen waveform display, while trying to set the "Start" and "End" points of the Math.... have to power cycle the scope to get it working again..... )
1) Whatever it claimed to do in the blurb; if X can't do Y, then X shouldn't claim Y.
2) Not lockup
-
Alsetalokin4017 and Tggzzz point out that the DS1054Z's math Diff function is seriously unusable.
Actually I didn't.
I pointed out that "taking an average" in any circumstance whatsoever provides a result - but raises new questions that are tricky to answer. -
Wow, that is really disappointing about the DS/MSO4000. In the cheapo bottom-barrel hobby scope one might expect fails like these but in the high-end product it is really just inexcusable.
Maybe the programmer who wrote the DIFF function flunked calculus, or never even was exposed to it at all.
The Tek screen is beautiful, the Diff trace passes "sanity check" in terms of location of peak and zero-crossing and its own slope etc.Quote1) Whatever it claimed to do in the blurb; if X can't do Y, then X shouldn't claim Y.
We completely agree.
2) Not lockup -
The calculus isn't faulty.
In fact, it's not even calculus!
A digital sampling oscilloscope performs discrete-time sampling operations. One can approximate differentiation or integration, but one should not be so foolish as to claim them as equivalent! This would be shame on Rigol, but everyone does it, so it's an industry-accepted error.
So what DO you actually get?
The difference. You are seeing waveform[t] - waveform[t-1].
Where continuous functions have differential equations and calculus, discrete functions have difference equations and iterated arithmetic.
If you want the derivative to be useful, the sample rate needs to be comparable to the risetime of the signal: only a few times higher, not wide open.
As shown, it seems the signal rate is so slow that the difference function looks less like a difference and more like a probability density: where bit-flips occurred in the input, more '1's occur in the difference.
Usually, you can reduce the sample rate by selecting it manually, or selecting a mode which smooths the waveform to a reasonable rate (Hi-Res mode? Averaging?).
Tim -
The calculus isn't faulty. In fact, it's not even calculus!
...
So what DO you actually get?
The difference. You are seeing waveform[t] - waveform[t-1].
waveform[t] - waveform[t-1] is the rate of change of waveform with respect to t.
And the rate of change of a variable with respect to another variable is ... what?
-
Alsetalokin4017 and Tggzzz point out that the DS1054Z's math Diff function is seriously unusable.
Actually I didn't.
I pointed out that "taking an average" in any circumstance whatsoever provides a result - but raises new questions that are tricky to answer.
Fixed, I must have misunderstood you. Indeed the use and interpretation of this Diff function is difficult to get the results I'm looking for I'll keep looking into it.
-
Works fine on GW Instek GDS-2000E, broken on Rigol DS-2000
-
The calculus isn't faulty.
In fact, it's not even calculus!
A digital sampling oscilloscope performs discrete-time sampling operations. One can approximate differentiation or integration, but one should not be so foolish as to claim them as equivalent! This would be shame on Rigol, but everyone does it, so it's an industry-accepted error.
So what DO you actually get?
The difference. You are seeing waveform[t] - waveform[t-1].
Where continuous functions have differential equations and calculus, discrete functions have difference equations and iterated arithmetic.
If you want the derivative to be useful, the sample rate needs to be comparable to the risetime of the signal: only a few times higher, not wide open.
As shown, it seems the signal rate is so slow that the difference function looks less like a difference and more like a probability density: where bit-flips occurred in the input, more '1's occur in the difference.
Usually, you can reduce the sample rate by selecting it manually, or selecting a mode which smooths the waveform to a reasonable rate (Hi-Res mode? Averaging?).
Tim
Whaaat? Even a clever tenth-grader could take the displayed graph of the input trace and calculate the slope of that trace at every displayed timeslice and plot the slopes on a new trace. How many pixels across is the screen? Heck, you could do it by inspection, manually, in under an hour. Put a FPGA to work on it and it should be up in an instant or two.
But I'll bet Rigol doesn't have any tenth-graders working for them.
Sure, a numerical solution isn't calculus, but the resulting graph (the Diff trace) should _look_ like a continuous graph of the rate of change of the differentiated function (the input trace). If it doesn't... perhaps the programmer actually had no idea what it should look like.
No, Hi-Res or Average mode didn't make much if any difference in my tests so far. Nor did memory depth. The only thing that worked to give an even halfway acceptable-looking Diff trace was that "Smooth" setting deep in a Math submenu. And the numerical value can't be trusted at all since it varies so much depending on Smooth and timebase setting. -
Works fine on GW Instek GDS-2000E, broken on Rigol DS-2000
Oh, that's embarrassing.
Earth to Rigol, are you paying attention?
-
Hmm, then it probably is buggy programming. Oh well!
Tim