Asking for Help with Verifying Genuineness of 2465B from Ebay


Tom Lee
 

It's important to understand that the relationship between rise time and bandwidth is not as quantitatively solid as many seem to think. The oft-quoted "-3dB BW in hertz, times the 10-90% rise time in seconds = 0.35" applies to a single-pole RC system driven by a perfect (zero rise time, zero overshoot) step. For the mathophiles among you, it's (1/(2*pi))(ln(9)). If your system isn't single pole, the relationship will be different. If you're not driving it with a perfect step, the relationship will be different. Since you never have a single pole, nor a perfect step, you're actually in approximation territory in practice.

Occasionally, you will see reference made to a Gaussian response conforming to the rule of thumb above. I think I've even seen it in some Tek literature (although I may be mistaken). Strictly speaking, the constant changes from 0.35 to 1/pi, or about 0.32. But that's purely of academic interest; true Gaussian responses do not actually exist, so you're still in approximation territory.

So, you're not measuring bandwidth when you measure rise time. You are estimating it. Preserving many digits in the computation is, therefore, actually kind of silly and pointless. You may be calculating a 3-digit answer to a 1-digit question.

If you want to know the bandwidth, then measure the bandwidth.

-- Cheers,
Tom

--
Prof. Thomas H. Lee
Allen Ctr., Rm. 205
350 Jane Stanford Way
Stanford University
Stanford, CA 94305-4070
http://www-smirc.stanford.edu

On 12/21/2020 17:44, Raymond Domp Frank wrote:
On Tue, Dec 22, 2020 at 02:13 AM, Raymond Domp Frank wrote:

So ideally a 2465A should be producing a risetime measure of 1ns and I'm
getting 1.09ns.
It's incorrect to say BW can be measured by measuring rise time. It depends on the 'scope's characteristics, the exact step shape (slew rate, over/undershoot, flat). Rise time gives an indication of flatness across a certain frequency range. In practice, direct BW measurement/specification is used and an approximate derived rise time is given. The TDS3000-series comes to mind but there must be many others.
Why is that?
Observe a sine wave, with a frequency known to within a few percent, with constant level at the 'scope input, and make sure that impedances of sine wave generator and 'scope input are well matched.
Observe the amplitude on the 'scope, starting from a frequency where the 'scope has "100% amplitude" and increase the frequency while observing the decrease in amplitude on the 'screen, until the amplitude is 100% - 3 dB, or about 70.7% of the original amplitude. There's your upper BW limit. In practice, you'll almost always see some wobbling when approaching the upper frequency.
Once you've established BW, go specify the approximate rise time, using 0.35/(rise time) for 'scopes with Gaussian behavior (simple roll-off). For your digital 'scope, use 0.40 or even a bit more. That's because the filtering in these 'scopes is (and must be) steeper, partly to avoid aliasing above BW-frequency.

Raymond




Tom Gardner
 

On 22/12/20 05:37, Tom Lee wrote:
If you want to know the bandwidth, then measure the bandwidth.
And the question becomes, "why do you want to measure the bandwidth?"

Firstly a scope is a time domain instrument, and (arguably) the most important characteristic is fidelity of what is seen in the time domain. Usually that implies some variant of transient response. If there are no transients, then use a frequency domain instrument such as a spectrum analyser.

Secondly, "bandwidth" is a single number that is used as a simple proxy for the complete amplitude/phase vs frequency response.

So, work out what you measurement your system/UUT needs, and then work out to what extent the measuring instrument enables you to measure it.


Tom Lee
 

Exactly! Hence the "if" clause.

You are asking the right question. Certain metrics may be attractive because of their simplicity, but one shouldn't forget what it is that we want the instrument to do.

-- Cheers,
Tom

--
Prof. Thomas H. Lee
Allen Ctr., Rm. 205
350 Jane Stanford Way
Stanford University
Stanford, CA 94305-4070
http://www-smirc.stanford.edu

On 12/22/2020 00:16, Tom Gardner wrote:
On 22/12/20 05:37, Tom Lee wrote:
If you want to know the bandwidth, then measure the bandwidth.
And the question becomes, "why do you want to measure the bandwidth?"

Firstly a scope is a time domain instrument, and (arguably) the most important characteristic is fidelity of what is seen in the time domain. Usually that implies some variant of transient response. If there are no transients, then use a frequency domain instrument such as a spectrum analyser.

Secondly, "bandwidth" is a single number that is used as a simple proxy for the complete amplitude/phase vs frequency response.

So, work out what you measurement your system/UUT needs, and then work out to what extent the measuring instrument enables you to measure it.






Tom Gardner
 

On 22/12/20 00:46, Mr. Eric wrote:
When I take the rise time measurement, I'm using the var knob of the volts/div in order to scale the flat top and bottom of the squarewave to the 0% and 100% graticules. I then use the deltaT cursors at the intersection of the 10 and 90. I will give a thanks and shoutout to W2AEW for his videos that teach these things. I've been wondering for half my life on why I would want an uncalibrated volts/div....
With some Tek scopes, the bandwidth is noticeably reduced when the var knob is not in the "cal position".

I don't know whether that applies to the 24x5 series, but it would be worth your while checking - simply eyeball the risetime.

To get around the problem, simply have the var knob in the cal position, measure the 0% and 100% levels, calculate where the 10% and 90% occurs, and put the cursors there.


TomC
 

On 12/21/2020 9:37 PM, Tom Lee wrote:
It's important to understand that the relationship between rise time and bandwidth is not as quantitatively solid as many seem to think. The oft-quoted "-3dB BW in hertz, times the 10-90% rise time in seconds = 0.35" applies to a single-pole RC system driven by a perfect (zero rise time, zero overshoot) step. For the mathophiles among you, it's (1/(2*pi))(ln(9)). If your system isn't single pole, the relationship will be different. If you're not driving it with a perfect step, the relationship will be different. Since you never have a single pole, nor a perfect step, you're actually in approximation territory in practice.
Occasionally, you will see reference made to a Gaussian response conforming to the rule of thumb above. I think I've even seen it in some Tek literature (although I may be mistaken). Strictly speaking, the constant changes from 0.35 to 1/pi, or about 0.32. But that's purely of academic interest; true Gaussian responses do not actually exist, so you're still in approximation territory.
So, you're not measuring bandwidth when you measure rise time. You are estimating it. Preserving many digits in the computation is, therefore, actually kind of silly and pointless. You may be calculating a 3-digit answer to a 1-digit question.
If you want to know the bandwidth, then measure the bandwidth.
-- Cheers,
Tom


Mr. Eric
 

Tom,

I loved the idea, I hadn't thought about leaving it calibrated although that's what I would have done on my DSO or what I would have done even just a year ago on an analog scope. Unfortunately I tried it and the result was exactly the same, 1.09ns. So I realize that this BW approximation technique is not the end all be all. But it is a very interesting experiment in and of itself that allows me to learn a lot more. So in that aspect, I think it's absolutely awesome. So I can't thank everyone enough for their help, ideas, and knowledge!!!! I'm a Computer Engineer by trade and degree, which means my skill lies somewhere between a bad EE and a bad Software Developer. But these are all the little aspects that contribute to my growth =)


Tom Lee
 

Thanks for that—the second reference has exactly the error that I was recalling. The implication that a single-pole system has a Gaussian response is one of the rare mistakes Tek allowed in print.

Cheers
Tom

Sent from my iThing, so please forgive brevity and typos

On Dec 22, 2020, at 20:11, Mr. Eric <engr.eric@gmail.com> wrote:

Tom,

I loved the idea, I hadn't thought about leaving it calibrated although that's what I would have done on my DSO or what I would have done even just a year ago on an analog scope. Unfortunately I tried it and the result was exactly the same, 1.09ns. So I realize that this BW approximation technique is not the end all be all. But it is a very interesting experiment in and of itself that allows me to learn a lot more. So in that aspect, I think it's absolutely awesome. So I can't thank everyone enough for their help, ideas, and knowledge!!!! I'm a Computer Engineer by trade and degree, which means my skill lies somewhere between a bad EE and a bad Software Developer. But these are all the little aspects that contribute to my growth =)





Brian Cockburn
 

Chuck et al,

Perhaps this list of what's what in various models (2445, 2445A, 2445B, 2465, 2465A, and 2465B) could be made into a document stored here in groups.io and in the tekwiki. It would have textual descriptions of the salient differences, a set of pictures of the parts that vary so that identifying what is in front of you on the bench becomes a 'look and match' experience. This issue of scopes sold as things they are not has been raised before and will no doubt be again. Maybe a google docs shared spreadsheet would be a suitable starting point?

Cheers, Brian.


Chuck Harris <cfharris@...>
 

Fundamentally, the problem with making such documents is the
people that might need them, don't know to look for them. It
doesn't fit the usual expected mode of behavior for a group.
(eg. Ask question, expect answer...)

I have written extensively about the 2465 family, but only those
that remember those writings bother to reference them. Those that
don't know, don't search.

The tekwiki is a better layout for such reference material.

-Chuck Harris

Brian Cockburn wrote:

Chuck et al,

Perhaps this list of what's what in various models (2445, 2445A, 2445B, 2465, 2465A, and 2465B) could be made into a document stored here in groups.io and in the tekwiki. It would have textual descriptions of the salient differences, a set of pictures of the parts that vary so that identifying what is in front of you on the bench becomes a 'look and match' experience. This issue of scopes sold as things they are not has been raised before and will no doubt be again. Maybe a google docs shared spreadsheet would be a suitable starting point?

Cheers, Brian.






ka7hqp@...
 

ebay feedback in no way represents actual feedback as I have left feedback
for a seller that was misrepresenting a small fan that did not have an
oscillating feature yet the description mentioned that it did. I purchased
the fan and no refund was given and ebay removed my feedback and the same
item is still available with the same description. ebay at first denied the
act of removing the feedback saying that they could not, then admitted that
they did remove it.

So what good is feedback if you can't rely on it...

Once they make their decision, there is no one to elevate it to, so I had
to take the loss and purchase another fan with the feature I desired.

Dennis

On Tue, Dec 22, 2020 at 8:22 PM Tom Lee <tomlee@ee.stanford.edu> wrote:

Thanks for that—the second reference has exactly the error that I was
recalling. The implication that a single-pole system has a Gaussian
response is one of the rare mistakes Tek allowed in print.

Cheers
Tom

Sent from my iThing, so please forgive brevity and typos

On Dec 22, 2020, at 20:11, Mr. Eric <engr.eric@gmail.com> wrote:

Tom,

I loved the idea, I hadn't thought about leaving it calibrated although
that's what I would have done on my DSO or what I would have done even just
a year ago on an analog scope. Unfortunately I tried it and the result was
exactly the same, 1.09ns. So I realize that this BW approximation technique
is not the end all be all. But it is a very interesting experiment in and
of itself that allows me to learn a lot more. So in that aspect, I think
it's absolutely awesome. So I can't thank everyone enough for their help,
ideas, and knowledge!!!! I'm a Computer Engineer by trade and degree, which
means my skill lies somewhere between a bad EE and a bad Software
Developer. But these are all the little aspects that contribute to my
growth =)