Sorry I meant how did I manage to measure a 800MHz signal and get such good rise time on a 70/300MHz scope.
(the screenshots have some clues
)
Doh - you even put red ellipses there.
I'm going back on holiday...
So did ya hack the VGA into 900MHz mode?
Perhaps by resetting it after the scope had already started so it went into full bandwidth mode?
You're f***ing with our heads Bud, please put us out of our misery.
I'm going to say direct injection into ADC input.
Tim
I'm going to say direct injection into ADC input.
Tim
This seems likely, should it be surprising that the firmware will happily go along with this and give measurements well outside the specs? I'm not sure what the best method for handling this would be.
This seems likely, should it be surprising that the firmware will happily go along with this and give measurements well outside the specs? I'm not sure what the best method for handling this would be.
I would leave it as is because I don't see clear benefits in "sanity check" in this case because that would decrease "hackability". This also complicates the code, needless to say firmwares are not perfect, more complications potentially would make it less stable/feature rich.
Anyway, I think most measurements functions work with curves, not with measurement points. Performing sanity checks on this is just to tricky and quite pointless, imho.
Sooo..... who's going to be the first to offer a drive-in-drive-out scope update service for this baby?
Sooo..... who's going to be the first to offer a drive-in-drive-out scope update service for this baby?
The parts won't cost much, but the labour........
This seems likely, should it be surprising that the firmware will happily go along with this and give measurements well outside the specs? I'm not sure what the best method for handling this would be.
I would leave it as is because I don't see clear benefits in "sanity check" in this case because that would decrease "hackability".
Please explain the causal connection - if there is one.
This also complicates the code, needless to say firmwares are not perfect, more complications potentially would make it less stable/feature rich.
I can make it infinitely "feature rich", provided it isn't required that the features actually
work.
Anyway, I think most measurements functions work with curves, not with measurement points.
I really don't understand what you are trying to say. A digitising scope can
only measure points. Waveforms are
only curves, until you are dealing at the level of individual photons and electrons and quantum, physics.
Performing sanity checks on this is just to tricky and quite pointless, imho.
If the manufacturers carelessly get that wrong, what else have they carelessly got wrong?
Old saying: "Fool me once, shame on you. Fool me twice, shame on me".
I really don't understand what you are trying to say. A digitising scope can only measure points. Waveforms are only curves, until you are dealing at the level of individual photons and electrons and quantum, physics.
You move cursors on a waveform, not between points. Analytic functions (or whatever they called) work on waveforms. Why should they care how and what waveform was acquired? In some cases it can be an indication that something is wrong or outside the speck. But this is not a proper self-test for this.
If the manufacturers carelessly get that wrong, what else have they carelessly got wrong?
Why do you think this is wrong? Sorry, I feel like you just falling into "this is wrong and everyone who does not share my point of view is incompetent" without any reasoning.
I really don't understand what you are trying to say. A digitising scope can only measure points. Waveforms are only curves, until you are dealing at the level of individual photons and electrons and quantum, physics.
You move cursors on a waveform, not between points. Analytic functions (or whatever they called) work on waveforms. Why should they care how and what waveform was acquired? In some cases it can be an indication that something is wrong or outside the speck. But this is not a proper self-test for this.
Ah. You mean functions that work on continuous curve
inferred by
interpolating between the sampled points. So that is going to depend on the interpolation chosen, the circumstances undet which the interpolation is and isn't valid,
and on whether the
implementation is correct.
Is there a hint there?
If the manufacturers carelessly get that wrong, what else have they carelessly got wrong?
Why do you think this is wrong? Sorry, I feel like you just falling into "this is wrong and everyone who does not share my point of view is incompetent" without any reasoning.
Please don't snip the relevant bits in order to (try to) make a point. You wrote "Performing sanity checks on this is just to tricky and quite pointless".
If an instrument doesn't pass a sanity check, should you continue to put faith in the instrument?
Old saying: "Fool me once, shame on you. Fool me twice, shame on me".
Sorry I meant how did I manage to measure a 800MHz signal and get such good rise time on a 70/300MHz scope.
(the screenshots have some clues )
Display mode in the top screen is X-Y. You're feeding in an external, slower time base on the X channel.
Okay, I think I was too strong on statements. I don't say "no check is ever needed". I say four things 1) I don't trust rigol implementing them 2) shouldn't be part of analytical functions. 3) may affect hackability 4) sanity check is very limited when analyzing unknown waveform. And here is why I think so.
1)
analytical functions != Input validation is a different thing. Checking the input range or "space between points" is fine. But...
2)
If it is too strict on checking inputs this may greatly harm hackability. How so? Imagine you removed restriction on bandwidth. But the scope "doesn't know" about this. So it can indicate a failure in this case. Or if I "overclock" it it may refuse work faster because "it checks the specs".
3)
It happened to me I'm a software developer, so I know a little bit about software. I didn't get your point about features, but I repeat my statement: more code -- more hassle to maintain it. If I knew they have good software specialists I would welcome more checks. But since it's rigol I have a fear that they don't have expertise. They can easily degrade scope performance when adding more validation. And it's not uncommon to see "software gone mad".
4) I think best check is the analysis of a signal with a known waveform. I'm not sure it is possible to catch most failures just by analyzing user input.
@AndyC:
This is the Cursor menu, X-Y is relative to the display of cursors, not the acquisition mode.
Bandwidth means -3dB at max frequency. Let's suppose your input signal amplitude is 5V, you have here 4mV, so an attenuation of more than -61dB, so clearly outside bandwidth. The sampling rate being 2Gs/s, you're still in the Nyquist ratio of 2 samples/period, so the digitalized signal is still valid.
How did I make these screenshots ?
Is there any way that you can force the scope to show just the ADC samples, without interpolation / reconstruction / post-capture filtering?
For the rise/falltime, which points are being measured? What happens when the front-end is overloaded? Is it simply measuring noise and finding a signal?
Thanks guys for participating in the discussion. I will answer in the evening when get home, i do not like typing on my mobile. For now just can say there was no fiddling with the clock frequency, these are actual shots of high frequency and low rise/fall time signals. And still there is a common clue in both screenshots that seems has not been spotted yet.
And still there is a common clue in both screenshots that seems has not been spotted yet.
My guess is you hacked the input attenuator -- removed/modified low-pass filter.
The sampling rate being 2Gs/s, you're still in the Nyquist ratio of 2 samples/period, so the digitalized signal is still valid.
I agree wit this. Removing interpolation and leaving only datapoints should show something triangle-like. Plus some input hacking imho.
@AndyC:
This is the Cursor menu, X-Y is relative to the display of cursors, not the acquisition mode.
Ah, OK, fair enough.
Perhaps it's something to do with the signal level being extremely low (I see measurements of just a few mV... not sure how exactly they're being calculated)...? Very small amplitude means the system isn't limited by slew rate, because the V/sec rate is still within limits even if the input frequency is high.
The sampling rate being 2Gs/s, you're still in the Nyquist ratio of 2 samples/period, so the digitalized signal is still valid.
I agree wit this. Removing interpolation and leaving only datapoints should show something triangle-like. Plus some input hacking imho.
Why are you choosing that specific reconstruction? Why not a zero-order hold or, better, just the impulses?
Why are you choosing that specific reconstruction? Why not a zero-order hold or, better, just the impulses?
I think I meant "just impulses" (=no reconstruction?). I'm no expert in this stuff, it's just a picture that popped into my head -- dots connected with straight lines. May be because I saw this on youtube when the guy chose "no interpolation" on the scope. Probably, it was in "the signal path blog" and with a review of a 100GHz scope.
Thanks guys for participating in the discussion. I will answer in the evening when get home, i do not like typing on my mobile. For now just can say there was no fiddling with the clock frequency, these are actual shots of high frequency and low rise/fall time signals. And still there is a common clue in both screenshots that seems has not been spotted yet.
The first screenshot has the bandwidth limit on - but is still measuring 800MHz...
Both traces look very sharp compared to the equivalent signal on my DS4k - is averaging turned on or is that typical when the scope is stopped?
Bandwidth means -3dB at max frequency. Let's suppose your input signal amplitude is 5V, you have here 4mV, so an attenuation of more than -61dB, so clearly outside bandwidth. The sampling rate being 2Gs/s, you're still in the Nyquist ratio of 2 samples/period, so the digitalized signal is still valid.
Nope, the waveform quickly becomes fuzzy after you cross the VGA set bandwidth limit.