-
Timebase is 20ns/div => ~1000 pixel = 200 ns, plus some headroom for zoom-in after stopping the capture. In the time domain display of the first image (-> step interpolation) you can see that the 1ns samples from the ADC are more than one pixel wide.
I'm pretty confident that the reported 12.5Gs/s FFT sampling rate is indeed the (upsampled) display buffer sampling rate for the selected timebase. Particularly in the first image, the spectrum beyond 1GHz matches the expected spectrum of the step-interpolation as shown in the time-domain trace.
Please put a 50 ohm thru termination on it and repost. A BNC tee with a 50 ohm terminator is "good enough". I'll address the rest later. Interpolation does *not* imply greater BW. Common knowledge if you resample via Fourier transform as I usually do.
A 50 Ohm feed-through was already in place (but the AWG signal does not have steep edges anyway, so it does not make much difference).
I fully agree, that perfect sinc interpolation is not supposed to increase BW by "producing" new frequencies. And if the sinc up-sampling is done via zero-insertion + boxcar filtering via FFT, then it becomes clear that it cannot, since the freqeuncy band beyond the the original Nyquist is explicitly cleared before ifft.
Other interpolators (e.g. nearest neibhgor, polynomial, etc.) can well introduce "new" frequencies, though, since they approximate just time domain w/o caring about Fourier stuff and frequency domain. A sinc interpolation kernel, on the other hand, is in fact an implicit boxcar filter in the frequency domain. Convolution with a truncated sinc does no longer give a perfect boxcar frequency response either, so zero-insertion + filtering with only a truncated sinc does not necessarily eliminate all frequences which where introduced by the zero insertion.
Btw, with "display buffer" I do not mean 1:1 the screen pixels, but intermediate data prepared for screen display. Mapping to the actual screen pixels still requires an additional resampling step. Eventually there seem to be 3 steps
1) Sampled data (at ADC sampling rate)
2) Interpolated/upsampled data (at a higher sampling rate, which depends on the selected timebase)
3) resampling to actual screen pixels (yet a different sampling rate, depending on current screen-window size, zoom)
FFT (and other math functions) seem to operate on (2), at least on my scope.
-
So, are there any "rules of thumb" for getting the best FFT performance out of a scope, given that it is a secondary function to the time domain?
Is the best performance going to be when the FFT sample rate matches the scope's sample rate? -
The way a DSO *should* work when showing a time and/or frequency display:
ADC *always* samples at full speed. There is one ADC data stream which is fed to 2 DSP pipelines.
Data for time domain display is downsampled to sample rate appropriate to timebase setting using a folded LP filter
Data for frequency domain display is heterodyned and downsampled appropriate to SA settings using a multiplier and folded LP filter
Time domain display interpolation is by means of a minimum phase interpolator which combines the passband of the anti-alias filter and the downsampling LP filter on the time domain data stream. The coefficients of that filter are optimized to minimize errors. A similar process is applied to interpolating the frequency domain data.
None of the above requires a lot of resources. If it does, it's being done wrong. I suggest reading:
VLSI Digital Signal Processing Systems: Design and Implementation
K.K. Parhi
Wiley 1999
for the details on how to implement the above in hardware with minimum resources. Because of the screen update rate limitation the FFT can be done in the NEON cores of a Zynq.
Claims that you need to sample the input data with a 2nd ADC are the sort of reason that current DSOs are so bad. Not doing it in the manner outlined above is either a failure to perform the correct mathematical operations or a failure to implement them efficiently.
The above is not speculative, It is the product of a considerable amount of work over the last 2 years. I already knew DSP on a general purpose computer. I did not know the details of how to implement it on an FPGA. I shall explain why I would do such in a few months.
Have Fun!
Reg
-
So, are there any "rules of thumb" for getting the best FFT performance out of a scope, given that it is a secondary function to the time domain?
Is the best performance going to be when the FFT sample rate matches the scope's sample rate?
Best I can offer is try all the knobs and make sure you didn't miss part of the FFT menu structure. I *always* find it difficult to get what I want using anything other than the Instek SA app.
And use a test signal for which you know what the spectrum should look like to set it up. I find it extremely annoying and frustrating.
Reg -
Alternatively I still consider the possibility that the FFT was not calculated from the raw ADC samples @100 MSPS, but from the (interpolated) screen buffer samples, so that the reported 1GSPS and 4GSPS do indeed reflect the sampling rate for the FFT calculation.
2048 points @4GSPS leads to frequency bins with a width of ~1.9MHz, while 2048 points @1GSPS gives you a 4x higher resolution of ~0.49MHz/bin. Note, when you select a span of 200 MHz, you don't increase this resolution - the span selection does just a zoom-in into the spectrum, interpolating between the lower-resolution bins.
[ Note, even with this different consideration it still bails down to fewer original ADC samples being included in the FFT, since the majority of the 1GSPS or 4GSPS samples are just interpolated. ]
Does actualy exist any (slower) timebase, where the reported FFT sampling rate and the ADC sampling rate are the same?
The screen display is just the screen display. That sampling has *nothing* to do with the frequency range of the data being displayed. The DS1202Z-E set at 2 ns/div reports 2.5 GHz/div 50 GSa/s. That's complete nonsense. That's a crap programming job done by someone who didn't bother to look at the results and recognize it was pure nonsense.
Reg -
I did not know the details of how to implement it on an FPGA.
I think this is the problem.
FPGAs have a limited number of gates and multiply-accumulate units need a lot of them. It doesn't matter how simple your algorithm is on paper, if there's not enough gates then it can't be done.
-
Alternatively I still consider the possibility that the FFT was not calculated from the raw ADC samples @100 MSPS, but from the (interpolated) screen buffer samples, so that the reported 1GSPS and 4GSPS do indeed reflect the sampling rate for the FFT calculation.
2048 points @4GSPS leads to frequency bins with a width of ~1.9MHz, while 2048 points @1GSPS gives you a 4x higher resolution of ~0.49MHz/bin. Note, when you select a span of 200 MHz, you don't increase this resolution - the span selection does just a zoom-in into the spectrum, interpolating between the lower-resolution bins.
[ Note, even with this different consideration it still bails down to fewer original ADC samples being included in the FFT, since the majority of the 1GSPS or 4GSPS samples are just interpolated. ]
Does actualy exist any (slower) timebase, where the reported FFT sampling rate and the ADC sampling rate are the same?
The screen display is just the screen display. That sampling has *nothing* to do with the frequency range of the data being displayed. The DS1202Z-E set at 2 ns/div reports 2.5 GHz/div 50 GSa/s. That's complete nonsense. That's a crap programming job done by someone who didn't bother to look at the results and recognize it was pure nonsense.
Reg
It looks like the "complete nonsense" approach was started by the A brands back in the day - and now many/most of the B brands are doing the same thing, trying to look just as good as an A brand, as @rf-loop pointed out earlier in this thread.
Dismissing crazy numbers like a 100GHz FFT span on a 100MHz scope is not "beginner level", as we can see in this thread so far!
If you are going to make a simplified display of complex information to non-expert users (which is really what FFT on an entry level scope is), one of the first rules of GUI design is - never allow the user to enter settings that ends up displaying nonsense results. That is something that could have been done without even altering the underlying hardware or code.
-
Isn't that great? The scope's FFT assists assessing the scope's interpolation algorithms
Maybe they started implementing it to do something like that and, then, decided to make it public (without any further validations).
-
The screen display is just the screen display. That sampling has *nothing* to do with the frequency range of the data being displayed. The DS1202Z-E set at 2 ns/div reports 2.5 GHz/div 50 GSa/s. That's complete nonsense. That's a crap programming job done by someone who didn't bother to look at the results and recognize it was pure nonsense.
Seems to me that that the scope has a notion of a "desired number of points/div" (say 100, which happens to result in a desired sampling rate of 50 Gsa/s then, at 2ns/div), and the captured data are generally converted to this desired rate. If the desired sampling rate is higher than the max. ADC sampling rate, then the data are up-samped/interpolated to the desired rate before further processing, ensuring a particular minimum number of points/div.
If a buffer containing 50 GSa/s samples was passed to the FFT engine as input, why should it not report 50 GSa/s? Likely the FFT engine does not even know about the origin of the data (i.e. real vs. up-sampled), and it also does not care.
I do not deny that up-sampling the data before calulating the FFT is not really helpful. On the contrary, it reduces the frequency resolution if the number of FFT points is fixed.
For other math-functions like e.g. RMS, it can indeed make sense, though, to calculate them from up-sampled/interpolated data instead of using just a few sparse original ADC samples per period for the calculation, which won't be accurate then. Obvioulsy, FFT is classified as "math function", too, so I guess it is fed with the same data as other math functions.
-
The DSP in DSOs is a major fail even from the A list. It's not even good enough to get a passing grade as a DSP 101 homework exercise. The first chapter of any DSP text explains aliasing and why you cannot decimate data by throwing away samples. You *have* to low pass filter the data. That's not hard to do and doesn't require a lot of resources, so I'm agog that DSOs are decimating data by discarding samples. The results of my tests with a 5 ns pulse at 1 s intervals showed that "peak detection" is necessary to offset the absolute bodge of downsampling by decimation.
That illustrates the difference between theory and reality. There are good reasons that digital storage oscilloscopes work the way they do. As pointed out above, if you want a digitizer, than buy a digitizer, or an older DSO from LeCroy who initially based their DSOs on digitizers.
On the practical side, for a majority of time DSOs simply could not do more than the simplest processing during decimation short of a heroic effort and price. Indeed, they could not even store the undecimated acquisition because memory was not long and fast enough. The best which could be done is to discard samples, or the very simplest processing like boxcar averaging (high resolution mode) or peak detection. See below about implementing a filter based on decimation ratio or sweep speed.
Later when real time processing became feasible with custom logic, the DPO (digital phosphor oscilloscope) was invented. It has no need of decimation because it produces a histogram of the input in real time and every sample contributes to the acquisition record at any sweep speed.The way a DSO *should* work when showing a time and/or frequency display:
ADC *always* samples at full speed. There is one ADC data stream which is fed to 2 DSP pipelines.
Data for time domain display is downsampled to sample rate appropriate to timebase setting using a folded LP filter
Time domain display interpolation is by means of a minimum phase interpolator which combines the passband of the anti-alias filter and the downsampling LP filter on the time domain data stream. The coefficients of that filter are optimized to minimize errors. A similar process is applied to interpolating the frequency domain data.
The problem with what you describe is that it results in a bandwidth which depends on decimated sample rate which depends on sweep speed. That is not the case for analog oscilloscopes where transition time does not depend on sweep speed.
It is also why I keep repeating that DSOs do not implement anti-aliasing filters, at least as commonly understood. If they did, then their bandwidth would vary with the time/div setting. You certainly could implement such now but why? The display will be no different except for two factors:
1. Signal envelopes will be wrong as higher frequencies are attenuated. Of course with aliasing it may not be apparent that a signal even has an envelope like in the example photograph that I posted which shows a fine envelope despite potential aliasing because peak detection was used.
2. The histogram for the signal will be corrupted. All of the characteristics and measurements which depend on the histogram will now vary with sweep speed; won't that be fun! Of course those who are used to Rigol's automatic measurements will not notice a difference because Rigol already does this by making measurements on the display record which has a corrupted histogram from the processing required to create it. This suggests that no uncontrolled processing which alters the histogram should be performed between acquisition and measurement.
To give a concrete example of the above, the DSOs I use can measure RMS and peak-to-peak noise easily and accurately within the limits of their fixed input bandwidth. But if decimation was done as you describe, then noise measurements would vary with sweep speed and be essentially useless. Changing the sweep speed should not alter the input bandwidth.
Another example is transition time would vary with sweep speed. Now you might think from using modern DSOs that this would not be a big issue but how did old DSOs handle it? They could not report the correct transition time if too few samples were taken at an edge and the designers knew this! Instead, they return the questionable measurement and include a warning that the decimated sample rate is insufficient. Many modern DSOs just lie. Those old DSOs also adjusted their returned number of significant digits to account for measurement precision.
-
[...] Changing the sweep speed should not alter the input bandwidth. [...]
Not sure I follow... (happens a lot, sadly)
If the ADC is running at full tilt all the time, why would the bandwidth alter with the sweep speed? Presumably it would have a filter in front of it that is tuned to its sample rate (Nyquist) and that never changes?
Are you saying it would be a bad idea for the scope to apply another, second filter that depends on the maximum frequency that the display is able to show at the selected sweep speed?
-
I think David Hess is referring to the situation where the samplerate has to drop because the memory is too short to capture a full screen at the maximum samplerate.
[...] Changing the sweep speed should not alter the input bandwidth. [...]
Not sure I follow... (happens a lot, sadly)
If the ADC is running at full tilt all the time, why would the bandwidth alter with the sweep speed? Presumably it would have a filter in front of it that is tuned to its sample rate (Nyquist) and that never changes?
Are you saying it would be a bad idea for the scope to apply another, second filter that depends on the maximum frequency that the display is able to show at the selected sweep speed?
I also think David Hess has an interesting point about a DSO not changing it's bandwidth depending on the samplerate because it would make peak-detect not working. OTOH I wonder what good peak-detect does on the FFT operation anyway; do you want to have both enabled at the same time? Also doing FFT on a seperate processing path as rhb suggested would make it impossible to change the part of a signal FFT is performed on (scroll left/right). I think the bottom line is that FFT is a useful tool on a DSO but there are trade-offs and every manufacturer implements it differently (decimated data / non decimated data, full record length / partial record length, etc).
-
[...] Changing the sweep speed should not alter the input bandwidth. [...]
Not sure I follow... (happens a lot, sadly)
If the ADC is running at full tilt all the time, why would the bandwidth alter with the sweep speed? Presumably it would have a filter in front of it that is tuned to its sample rate (Nyquist) and that never changes?
Are you saying it would be a bad idea for the scope to apply another, second filter that depends on the maximum frequency that the display is able to show at the selected sweep speed?
Let's take simple signal Dave likes so much: AM modulated carrier. You take say, 20 MHz carrier, AM modulate it with 100 Hz.
If you were to do decimation by a folded LP filter (as suggested), you would end up with carrier filtered out... simple as that. Scope screen wouldn't show what it should. That is also a reason to have Peak detect mode, so we can detect pulses that are faster than what sampling would show on slower sampling rates. That is not proper sampling for DSP. That is proper sampling to show signal shape on screen. That is what scopes are used for. To look at signal shape on screen. All other math and measurements are just utilities thrown in for better value. Including FFT.
I wanted scope that has FFT done better than other scopes. So I bought two Picoscopes. One is 16Bit low noise 5MHz bandwidth. They are also great for decoding. My other scope is MSOX 3104T. I use it as a scope.
And it's FFT works great, you can set it as on SA, with center frequency and span, or start - stop frequency. You can set averaging, peak, min max mode, search for peaks, measure it with cursors etc etc. But timebase still governs sampling, so sometimes you need to set timebase differently so you get data needed to do FFT at settings you want to set. It works great, actually, except it is limited to only 64K points. Which means you will have limited resolution bandwidth... When you compare it with Picos 2 Mpoints (for 1 M bins) you see the difference.
There is also one thing: Keysight claims they are using Chirp-Z Transform (CZT) in 3000T (and guess more of the lines) instead of vanilla FFT, because it is more flexible.. -
My other scope is MSOX 3104T. I use it as a scope.
This ^, something Reg called out as BS.
And it's FFT works great, you can set it as on SA, with center frequency and span, or start - stop frequency. You can set averaging, peak, min max mode, search for peaks, measure it with cursors etc etc. But timebase still governs sampling, so sometimes you need to set timebase differently so you get data needed to do FFT at settings you want to set. It works great, actually, except it is limited to only 64K points. Which means you will have limited resolution bandwidth... When you compare it with Picos 2 Mpoints (for 1 M bins) you see the difference.
-
Exactly, because he thinks doing realtime DSP on 10 GB/s worth of data is trivial, together with sophisticated triggering, zone trigger, digital phosphor emulation, decoding, segmenting, history, search, measurements, math, parametric filtering. All of those things are not problem by itself. Doing all that at the same time, not so trivial.My other scope is MSOX 3104T. I use it as a scope.
This ^, something Reg called out as BS.
And it's FFT works great, you can set it as on SA, with center frequency and span, or start - stop frequency. You can set averaging, peak, min max mode, search for peaks, measure it with cursors etc etc. But timebase still governs sampling, so sometimes you need to set timebase differently so you get data needed to do FFT at settings you want to set. It works great, actually, except it is limited to only 64K points. Which means you will have limited resolution bandwidth... When you compare it with Picos 2 Mpoints (for 1 M bins) you see the difference.
I already said, there are high end scopes from Keysight, LeCroy, R&S that are doing it better. But those are out of reach of us mortals.
Also there is some stuff scopes don't do usually. His idea of decimation by LP filtering to gain more resolution at slower time bases sounds nice.. But wait, isn't that Hires mode (or 10 Bit mode on SDS200X+)?? I guess scopes ARE doing it. Except you don't want it all the time. Like David said well, slow timebase doesn't mean low bandwidth.
He does have nice ideas, and he is right about math part. And I would like if Siglent and Rigol would make lower price MDO scope with correlated time/frequency domain. With frequency mask trigger please.. But how realistic is that, really ?? -
My first 2 scopes were analog and those just start drawing from the left side of the screen after a trigger.
Then I got into digital scopes, and they all default to triggering in the center of the screen, which I find quite annoying.
For repetitive signals it's moot of course, but for all one-off signals the left half of the screen just has no useful information at all, because the "interesting" stuff happens after the trigger.
My best analog scope had a delay line (10+m of coax wound around it's tube) and with that I could see just a little bit before the trigger, which is perfect.
I would prefer my digital scope to default the trigger position to one division from the left side of the screen, so you can see a little bit of "before" the trigger, and still use almost the whole screen for the rest of the signal.
You can of course manually move the trigger location horizontally, but that messes up with zooming in and out on a digital scope. -
He does have nice ideas, and he is right about math part. And I would like if Siglent and Rigol would make lower price MDO scope with correlated time/frequency domain. With frequency mask trigger please.. But how realistic is that, really ??
Technically it is possible but their oscilloscopes would cost the same as buying one from an A-brand. -
Exactly, because he thinks doing realtime DSP on 10 GB/s worth of data is trivial, together with sophisticated triggering, zone trigger, digital phosphor emulation, decoding, segmenting, history, search, measurements, math, parametric filtering. All of those things are not problem by itself. Doing all that at the same time, not so trivial.My other scope is MSOX 3104T. I use it as a scope.
This ^, something Reg called out as BS.
And it's FFT works great, you can set it as on SA, with center frequency and span, or start - stop frequency. You can set averaging, peak, min max mode, search for peaks, measure it with cursors etc etc. But timebase still governs sampling, so sometimes you need to set timebase differently so you get data needed to do FFT at settings you want to set. It works great, actually, except it is limited to only 64K points. Which means you will have limited resolution bandwidth... When you compare it with Picos 2 Mpoints (for 1 M bins) you see the difference.
I already said, there are high end scopes from Keysight, LeCroy, R&S that are doing it better. But those are out of reach of us mortals.
Also there is some stuff scopes don't do usually. His idea of decimation by LP filtering to gain more resolution at slower time bases sounds nice.. But wait, isn't that Hires mode (or 10 Bit mode on SDS200X+)?? I guess scopes ARE doing it. Except you don't want it all the time. Like David said well, slow timebase doesn't mean low bandwidth.
QuoteHe does have nice ideas, and he is right about math part.
I highly respect Reg and the amazing seismic exploratory work he has done and analysis of TB's of data acquired over weeks however scopes work in realtime or thereabouts and the data stream is managed so to not have results that are slow as pouring molasses to arrive at the display.
Scopes don't have the luxury of providing information sometime after all calculations are completed.
-
Exactly.He does have nice ideas, and he is right about math part. And I would like if Siglent and Rigol would make lower price MDO scope with correlated time/frequency domain. With frequency mask trigger please.. But how realistic is that, really ??
Technically it is possible but their oscilloscopes would cost the same as buying one from an A-brand. -
My first 2 scopes were analog and those just start drawing from the left side of the screen after a trigger.
Then I got into digital scopes, and they all default to triggering in the center of the screen, which I find quite annoying.
For repetitive signals it's moot of course, but for all one-off signals the left half of the screen just has no useful information at all, because the "interesting" stuff happens after the trigger.
My best analog scope had a delay line (10+m of coax wound around it's tube) and with that I could see just a little bit before the trigger, which is perfect.
I would prefer my digital scope to default the trigger position to one division from the left side of the screen, so you can see a little bit of "before" the trigger, and still use almost the whole screen for the rest of the signal.
You can of course manually move the trigger location horizontally, but that messes up with zooming in and out on a digital scope.
The 56422D gives you the choice of where to put the trigger location: right, center, left. I would have thought all digital scopes offers that choice?
-
[...] Changing the sweep speed should not alter the input bandwidth. [...]
Not sure I follow... (happens a lot, sadly)
If the ADC is running at full tilt all the time, why would the bandwidth alter with the sweep speed? Presumably it would have a filter in front of it that is tuned to its sample rate (Nyquist) and that never changes?
Are you saying it would be a bad idea for the scope to apply another, second filter that depends on the maximum frequency that the display is able to show at the selected sweep speed?
Let's take simple signal Dave likes so much: AM modulated carrier. You take say, 20 MHz carrier, AM modulate it with 100 Hz.
If you were to do decimation by a folded LP filter (as suggested), you would end up with carrier filtered out... simple as that. Scope screen wouldn't show what it should. That is also a reason to have Peak detect mode, so we can detect pulses that are faster than what sampling would show on slower sampling rates. That is not proper sampling for DSP. That is proper sampling to show signal shape on screen. That is what scopes are used for. To look at signal shape on screen. All other math and measurements are just utilities thrown in for better value. Including FFT.
I wanted scope that has FFT done better than other scopes. So I bought two Picoscopes. One is 16Bit low noise 5MHz bandwidth. They are also great for decoding. My other scope is MSOX 3104T. I use it as a scope.
And it's FFT works great, you can set it as on SA, with center frequency and span, or start - stop frequency. You can set averaging, peak, min max mode, search for peaks, measure it with cursors etc etc. But timebase still governs sampling, so sometimes you need to set timebase differently so you get data needed to do FFT at settings you want to set. It works great, actually, except it is limited to only 64K points. Which means you will have limited resolution bandwidth... When you compare it with Picos 2 Mpoints (for 1 M bins) you see the difference.
There is also one thing: Keysight claims they are using Chirp-Z Transform (CZT) in 3000T (and guess more of the lines) instead of vanilla FFT, because it is more flexible..
I think I see what you are saying. On a traditional analog scope, if you view a high frequency signal at a slow sweep speed, the line just get fatter... but you know there is a signal there, even if you don't know exactly what it is and even though it is not accurately represented (apart from amplitude... so analog scopes do peak detect naturally, in reality!)
So I agree that filtering the signal depending on sweep speed is not desirable in all circumstances. It could be a cool option, though, to eliminate aliasing in some circumstances?
-
Yes you got it. That is exactly the point.
-
A few points, there's too much pure silliness to bother about all of it.
The discrete Fourier transform of a band limited impulse is a constant value. If I remove half of the values from the middle of the transform, so instead of 10,000 at 1 ns I have 5000 and I back transform I will have a band limited impulse at a 2 ns sample rate. It doesn't matter what the new sample rate is. It will always be a spike. I have used this method to do band limited resampling for 35 years including converting sampling between fractional meters and feet and made the results *exact* to the limits of the input BW with *no* phase errors. That last bit was a *very* painful 2 weeks of having my nose rubbed in the definition of the discrete Fourier transform.
If a signal is an impulse at the fastest sampling rate it is an impulse at *all* slower sampling rates and it is *always* there.
If you properly downsample with low pass filtering rather than decimating by throwing away samples you will *always* have a band limited spike. It will *not* disappear. However, it *will* make "peak detection" moot.
I've been counting DSP and logic blocks in FPGAs in the context of a DSO for a couple of years now. If the clock rate of the FPGA is not fast enough to process the data stream in a serial pipeline, one uses a parallel interleaved filter, c.f. Parhi for the details. In a 1 GHz clocked FPGA a 10 GSa/s data stream will need a 10x interleaved parallel filter. Dealing with Vivado/Vitis is more difficult than the actual topology for the implementation.
As it is clear that few understand what a "folded" filter is, it's a single adder-multiplier which accepts data at one clock rate and outputs it at a lower clock rate after performing multiple filter tap operations. It is the hardware equivalent of a loop.
In the case of an analog scope, on a high BW scope at slow sweep speeds, a fast impulse will likely not be visible at all unless the intensity is set very high.
I made a long list of tests to perform today. I'll start doing some of those over the next few days. Jitter is probably next as I'm curious about the apparent sample dithering.
Have Fun!
Reg
-
So, I sat down in front of the scope and tried the 100Hz modulation of a 20MHz signal - nothing like a real example, right?
It seems to me that the digital scope behaves pretty much like an analog scope in this case. The slow sweep speed does not seem to detract from the ability to display an outline of the 20MHz signal (even without Peak Detection enabled).
Obviously, filtering out the 20MHz would destroy the information as displayed here.
(note: normal mode, not peak detect)
-
A few more points:
The purpose of the thread is to document what is wrong with DSOs on the market.
I am not interested in teaching DSP 101.
I am not willing to spend the time to address every misunderstanding of DSP someone has.
I appreciate having someone point out an error I make.
If you are not willing to take the time to demonstrate an alleged error on my part, I shall ignore you unless it is stated such that it is immediately obvious.
Please do not raise issues which are amply addressed by references I provide. If you are not willing to read the references, I'm not willing to explain it to you.
I'm sorry, but I'm not a "nice" guy. I am not willing to indulge adults who still behave like children.
Have Fun!
Reg