Scope Wars

[rhb]

That is the affect of the window length.  The true spectrum is a series of spikes which is convolved with the window spectrum.  So each spike is replaced by a scaled version of the Fourier transform of the window.

There's a pretty good description here of a wide variety of windows:

https://en.wikipedia.org/wiki/Window_function

While many of them are very familiar, there are a number I'd never heard of.  Probably the most common window is a raised cosine at each end of a time series and then flat in between.    A depressingly common DSP programming error is the failure to apply a taper to the ends of the series and to pad it with zeros to prevent wrap around effects.  Another common error is to not remove and then replace a linear trend from the data when doing a forward and inverse transform so you can manipulate the data i the frequency domain.

If the series is not zero padded then the sidelobes of the window function wrap around to both ends.  This can be very important if you are chopping a non-stationary time series into approximately stationary segments, applying an FFT, doing some operation such as spectrum equalization, back transforming and splicing the pieces back together.

In settings where all the data has been recorded before processing begins, it is very common to flip from time to frequency and back, often several times as an FFT, multiply and inverse FFT is much faster than a long convolution.

Have Fun!
Reg

[gf]

The 2nd one was obvioulsy calculated from a lower number of points (-> lower frequency resolution),...

The 2nd trace does of course cover a shorter time interval (and thus also a lower number of original ADC samples) than the first one.

[SilverSolder]

Why does the spectrum look different when you change the time base?

The basic shape does not look so diffferent, though. The 2nd one was obvioulsy calculated from a lower number of points (-> lower frequency resolution), and was up-sampled then, in order to obtain the same number of frequency bins as in the first one.

You can basically achieve this by zero-padding the available samples to a larger number, and calculating the FFT from the zero-padded samples then.

EDIT: I presume that you did not select different window functions, did you?

Everything was exactly the same in the two,  apart from the time base.  (Hanning window)

Why does the FFT spectrum become less detailed when you zoom in on the waveform by decreasing the sweep time?  I would expect as you zoom out (increase sweep time) that you would LOSE resolution...   yes, you have more cycles of the wave on the screen, but each cycle is made of less samples...

[2N3055]

Most users don't understand the FFT at all.  As an example, window functions for the FFT.  Keysight doesn't have a triangle  (aka Bartlett) window option,  essential to get good spectral resolution, on the MSOX-3104T,  a $20K list instrument.  And the FFT is so limited as to be almost completely useless.

Sure it does have triangular window (User manual , top of page 93)... It's just you returned it before you had time to read manual  end to end .

[SilverSolder]

That is the affect of the window length.  The true spectrum is a series of spikes which is convolved with the window spectrum.  So each spike is replaced by a scaled version of the Fourier transform of the window.

I think I see...   so basically, if the scope had used a shorter window length for the faster sweep speed, the FFT would have looked the same in the two cases?

The FFT buffer is always 2048 points and fixed.  It looks like the window length is also fixed - there is no obvious way to change it, and it doesn't seem to change automatically with sweep speed.

I guess we are back to some of your earlier comments that scope FFTs don't really give the user enough control.

[rhb]

The sample rate sets the Nyquist frequency.  The number of samples sets the RBW.  The time length and shape of the window set the shape of an isolated peak.  The window sidelobes control how adjacent peaks look in between.

I suggest creating a sine wave in Octave, applying various time domain windows, doing an FFT and looking at the spectra.  Try sine waves close to DC or Nyquist with a rectangular window with and without zero padding to double the length.

Have Fun!
Reg

BTW What's the date on the MSOX3104T manual?

[gf]

That is the affect of the window length.  The true spectrum is a series of spikes which is convolved with the window spectrum.  So each spike is replaced by a scaled version of the Fourier transform of the window.

I think I see...   so basically, if the scope had used a shorter window length for the faster sweep speed, the FFT would have looked the same in the two cases?

The FFT buffer is always 2048 points and fixed.  It looks like the window length is also fixed - there is no obvious way to change it, and it doesn't seem to change automatically with sweep speed.

Using a window which is significantly shorter than the FFT size does basically imply that you discard a large fraction of the available samples (at least if the window has a finite extent like Hanning). Why would you you do that? One good reason is, when fewer samples than the FFT size are available in the first place.

[gf]

That is the affect of the window length.  The true spectrum is a series of spikes which is convolved with the window spectrum.  So each spike is replaced by a scaled version of the Fourier transform of the window.

I think I see...   so basically, if the scope had used a shorter window length for the faster sweep speed, the FFT would have looked the same in the two cases?

The FFT buffer is always 2048 points and fixed.  It looks like the window length is also fixed - there is no obvious way to change it, and it doesn't seem to change automatically with sweep speed.

Using a window which is significantly shorter than the FFT size does basically imply that you discard a large fraction of the available samples (at least if the window has a finite extent like Hanning). Why would you you do that? One good reason is, when fewer samples than the FFT size are available in the first place.

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?

[rhb]

Fundamentally it's a botched implementation.  However it is implemented, the programmer should have recognized that the frequencies are not in the GHz range. That such should appear under the Agilent name is truly sad.

Reg

[2N3055]

Reg,

there is a lot of misunderstanding (by you) about how scopes are conceptually made, it seems.
The way FFT is usually done on scopes is that scope works in "scope mode", where sampling parameters are governed by scope settings (timebase, input atten etc etc).
To implement FFT in "spectrum mode", you would have to control sampling in a way that is optimal for FFT calculations for a SA use. That includes overlapped FFT, averaging etc, etc. All those things you correctly mention.. One scope that does that is Picoscope, which in Spectrum mode takes over control of sampling completely. But in this mode you cannot have time and frequency domain at the same time. GW instek MDO does something similar, and Tektronix MDOs in their way

All of that is not because Keysight (or Siglent or Rigol or LeCroy) are stupid and don't know how to do it.
It is actually deliberate design decision.  Scope does what scope does, and then in math channel you get to massage buffer of sampled data with many functions, including FFT. It is by definition math applied as an afterthought.
FFT on those scopes is not making them mixed domain scopes.

Don't get me wrong, if somebody would make inexpensive  mixed domain scope that would work properly in a manner you describe,  I  would buy it right away. There is a scope that does things as you describe, new Keysight MXR..And some LeCroys do it right too..
But those are very high end...

We have very basic misunderstanding here, it seems. I'm not saying your math is wrong, and you know about DSP more than many of us here. No argue there. And certainly there is nothing wrong with wishing things were better.

I'm sayin your expectations are unrealistics, for a lowest end scopes you can buy. Or even for mid range scopes today. We would need serious hardware upgrades to support independent simultaneous synchronous scope and realtime SA mode to standard scope architecture.

Best regards,
Sinisa

[SilverSolder]

That is the affect of the window length.  The true spectrum is a series of spikes which is convolved with the window spectrum.  So each spike is replaced by a scaled version of the Fourier transform of the window.

I think I see...   so basically, if the scope had used a shorter window length for the faster sweep speed, the FFT would have looked the same in the two cases?

The FFT buffer is always 2048 points and fixed.  It looks like the window length is also fixed - there is no obvious way to change it, and it doesn't seem to change automatically with sweep speed.

Using a window which is significantly shorter than the FFT size does basically imply that you discard a large fraction of the available samples (at least if the window has a finite extent like Hanning). Why would you you do that? One good reason is, when fewer samples than the FFT size are available in the first place.

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?

Yes, indeed there does.  Source is 10MHz square wave from the 8012A pulse generator as before (pulse shape not exactly the same as the settings are analog on this device)

Timebase:  1uS/div


Here, the Span actually matches what the scope is specced for (100MHz BW,  200Msamples/sec) and cannot be made any wider.


As an aside:  I actually found a good use for the FFT function here - it makes it very easy to set up a clean pulse train from the pulse generator, tweaking the slopes and timings on the generator to minimize the even harmonics!  Before, I was doing it by visual inspection of the waveform, but FFT is far easier and more accurate.

[Fungus]

What I'm seeing in the comments above and my tests is pretty appalling.

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.

I'm fairly sure the people who design these things know the math.

I suspect the problem is that there's not enough processing power to do a proper decimation when every pixel on screen has dozens of samples in it.

[nctnico]

What I'm seeing in the comments above and my tests is pretty appalling.

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.

I'm fairly sure the people who design these things know the math.

Not just that, they also know what is useful or not. You can make a DSO show all kinds of fun signals if you push it but oddly enough you never run into these during normal use.

[gf]

An FFT example from my low-cost USB scope, when interpolation is in effect.
The FFT is clearly calculated from the interpolated (upsampled) points.
Signal is 10 MHz square wave (AWG is not that fast), 1GS/s ADC sampling rate,
timebase 20ns/div (-> so interpolation needed for display).
Reported FFT sampling rate is also higher than ADC sampling rate.
Specified FFT size is 1024.

If I select "step" interpolation, then the FFT clearly shows the 1GHz interpolation steps (as they show up in the time domain display), their harmonics at N*1GHz, as well as their IM with the baseband:


Sin(x)/x interpolation still shows an (unexpected) peak @1GHz, but its harmonics are almost gone. Obviously the scope's sin(x)/x interpolation filter is not a perfect boxcar (in frequency domain).


Linear interpolation gives the cleanest FFT result for this signal:


Isn't that great? The scope's FFT assists assessing the scope's interpolation algorithms 

[rhb]

Sinisa,

I've started working on code to do the SA function properly.  I'm still doing the requirements analysis and don't expect to start writing code for several weeks.  There are many nuances to getting this right.  I have a long standing rule:  I never write code until I've run out of excuses for not writing it.

This morning I was examining heterodyning a narrow span and doing the FFT on the lower sideband.  In an FPGA heterodyning is basically a single multiplier and and a sine table in block RAM.  I'm sure there is some stuff I've overlooked, but that's not a lot of resources and it allows downsampling by summing samples to increase the dynamic  range.  So probably 2 DSP and 2 RAM blocks in a Zynq.  If you want to look at a filter response over a 500 kHz BW with 10 Hz RBW it's a 100 kSa FFT on data sampled at 1 Msa/s.  If the ADC is sampling at 1 GSa/s there is 60 dB increase in dynamic range over the 42 dB range of the 8 bit data coming out of the ADC.  So now we have a 102 dB dynamic range.  The screen can't be updated faster than 60 fps or so.  As a consequence there is loads of time to do the processing.

This is not particularly difficult and does not require changing the data acquisition.  The UI needs to be sensible,  frequency & span, RBW, VBW, etc.  Not the "center frequency, Hz/div and very limited selection of sample length imposed by current DSOs which provide no meaningful control over the FFT.

It just has to be done properly.  Relative to the code for a 10 TB input imaging job that takes 20,000 cores 7-10 days to complete it's very easy.  A code for that is 1-2 years work full time by a top rate scientist/programmer.  A first rate SA app for a DSO is a few weeks work at most to do the numerical stuff.  I don't do UIs.

Have Fun!
Reg

[tautech]

This is not particularly difficult and does not require changing the data acquisition.  The UI needs to be sensible,  frequency & span, RBW, VBW, etc.  Not the "center frequency, Hz/div and very limited selection of sample length imposed by current DSOs which provide no meaningful control over the FFT.

Already you have control over RBW/VBW with the timebase setting used for FFT.
Span is set via Hz/div and CF.
It's just a different way at arriving at the same result as a fully fledged SA.


When I've finished my pulser that hopefully will get into the few 100ps range I'll show some examples.

[rhb]

An FFT example from my low-cost USB scope, when interpolation is in effect.
The FFT is clearly calculated from the interpolated (upsampled) points.
Signal is 10 MHz square wave (AWG is not that fast), 1GS/s ADC sampling rate,
timebase 20ns/div (-> so interpolation needed for display).
Reported FFT sampling rate is also higher than ADC sampling rate.
Specified FFT size is 1024.

If I select "step" interpolation, then the FFT clearly shows the 1GHz interpolation steps (as they show up in the time domain display), their harmonics at N*1GHz, as well as their IM with the baseband:
(Attachment Link)

Sin(x)/x interpolation still shows an (unexpected) peak @1GHz, but its harmonics are almost gone. Obviously the scope's sin(x)/x interpolation filter is not a perfect boxcar (in frequency domain).
(Attachment Link)

Linear interpolation gives the cleanest FFT result for this signal:
(Attachment Link)

Isn't that great? The scope's FFT assists assessing the scope's interpolation algorithms 

Why do you have the 20 MHz BW filter turned on for this? 

A 1024 point FFT with a 1 ns sample interval has a 500 MHz Nyquist and 977 kHz RBW.  With a 1024 pixel wide screen *every* sample can be shown.   There is no interpolation needed.

Reg

[rhb]

Already you have control over RBW/VBW with the timebase setting used for FFT.
Span is set via Hz/div and CF.
It's just a different way at arriving at the same result as a fully fledged SA.


When I've finished my pulser that hopefully will get into the few 100ps range I'll show some examples.

I'm sorry, but that is pure BS.  To provide the functionality of a proper SA you need much more control over the FFT.  Setting the timebase determines the time display.  It should not have any influence on a spectral display.  If it does, as is commonly the case, it is *wrong*!.

This is why we see stupid stuff like 50 GSa/S on the DS1202Z-E at 2 ns/div.  Programming by idiots.

Reg

[gf]

Why do you have the 20 MHz BW filter turned on for this? 

Sorry, the AWG isn't faster

A 1024 point FFT with a 1 ns sample interval has a 500 MHz Nyquist and 977 kHz RBW.  With a 1024 pixel wide screen *every* sample can be shown. There is no interpolation needed.

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.

[SilverSolder]

[...] This is why we see stupid stuff like 50 GSa/S on the DS1202Z-E at 2 ns/div.  [...]

Like having a speedometer in a Trabant that goes to 100,000 miles per hour? 

[Tomorokoshi]

[...] This is why we see stupid stuff like 50 GSa/S on the DS1202Z-E at 2 ns/div.  [...]

Like having a speedometer in a Trabant that goes to 100,000 miles per hour? 

That would be about right. If one accounts for the Earth's orbital velocity around the Sun.

[rhb]

Why do you have the 20 MHz BW filter turned on for this? 

Sorry, the AWG isn't faster

A 1024 point FFT with a 1 ns sample interval has a 500 MHz Nyquist and 977 kHz RBW.  With a 1024 pixel wide screen *every* sample can be shown. There is no interpolation needed.

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.

Reg

[rhb]

A side note.

If I'm not wrong at least once or twice a day I'm clearly not trying hard enough.  There is *no* shame in being wrong.  The only shame is in failing to admit the error.

Have Fun!
Reg

[2N3055]

Sinisa,

I've started working on code to do the SA function properly.  I'm still doing the requirements analysis and don't expect to start writing code for several weeks.  There are many nuances to getting this right.  I have a long standing rule:  I never write code until I've run out of excuses for not writing it.

This morning I was examining heterodyning a narrow span and doing the FFT on the lower sideband.  In an FPGA heterodyning is basically a single multiplier and and a sine table in block RAM.  I'm sure there is some stuff I've overlooked, but that's not a lot of resources and it allows downsampling by summing samples to increase the dynamic  range.  So probably 2 DSP and 2 RAM blocks in a Zynq.  If you want to look at a filter response over a 500 kHz BW with 10 Hz RBW it's a 100 kSa FFT on data sampled at 1 Msa/s.  If the ADC is sampling at 1 GSa/s there is 60 dB increase in dynamic range over the 42 dB range of the 8 bit data coming out of the ADC.  So now we have a 102 dB dynamic range.  The screen can't be updated faster than 60 fps or so.  As a consequence there is loads of time to do the processing.

This is not particularly difficult and does not require changing the data acquisition.  The UI needs to be sensible,  frequency & span, RBW, VBW, etc.  Not the "center frequency, Hz/div and very limited selection of sample length imposed by current DSOs which provide no meaningful control over the FFT.

It just has to be done properly.  Relative to the code for a 10 TB input imaging job that takes 20,000 cores 7-10 days to complete it's very easy.  A code for that is 1-2 years work full time by a top rate scientist/programmer.  A first rate SA app for a DSO is a few weeks work at most to do the numerical stuff.  I don't do UIs.

Have Fun!
Reg

Reg,
thanks for discussion.

FFT crunching alone is not a problem. Feeding it, is, and also showing results.
A/D feeding display engine is 5GB/s datapump. Scope deals with it in realtime. Sure there are pauses in there, but even with those, a lot of data gets moved around.
And also, there is a problem of display. That would need combining FFT results, math results, decode results, measurement results.. Each by itself not a problem, but combining and orchestrating them gets complicated too.

And FFT can use data from normal acquisitions. Sometimes. This is how it works now.  Problem is that sample memory length/timebase/sampling ratios are governed by scope settings for time domain. So somewhere in the middle of timebase range, where we are still operating at full sample speed, but already have long memory depth, we can use scope's capture. In that case we have data that can be decimated, downsampled etc. And there is enough of it to have your bins nicely filled to length you need.

But what to do when I'm looking at signal at slow timebase (that scope is sampling at 100 Mpoints/s) , and would like to use FFT to see if some spikes I see in there are 868 MHz bursts from telemetry receiver... That would need me to have scope sampling at 2GS/s or more at the same time it samples for my time domain display at 100 MS/s.
Answer is to either have separate A/D converter (Tek MDO series), have A/D always sample at full speed and decimate and distribute data to separate and parallel datapaths, or have scope always have time domain priority (and have FFT have whatever data is available, useful or not), or have scope have FFT priority, and start changing sampling to always cater to FFT needs and not show time domain data if not available.

First two options are expensive.  As for second two options, since we are not talking about SA with auxiliary time domain display, but about scopes with auxiliary FFT (frequency domain display), those scopes prioritize sampling to cater to scopes time domain needs primarily and FFT gets what it does. Simple as that.

Do i think that option with having paralel datapaths for scope and FFT is possible? Absolutely, in Zynq definitely.  But it is not a classic architecture, and would need to be developed.
Funny thing, Rigol's new chipset is used in both their new scopes and SAs, and it possibly could be used to make mixed signal scope that would be able to do what are you talking here...

Take care

[Fungus]

Not just that, they also know what is useful or not. You can make a DSO show all kinds of fun signals if you push it but oddly enough you never run into these during normal use.

Yep.

Weird, that...