Sin(x)/x interpolation and Digital Filters in Oscilloscopes

[pfm]

Digital oscilloscopes typically have Sin(x)/x interpolation. Is this interpolation done only for the display of the waveform ? or does it alter and substitue the real sampled data with interpolated data as well ? If I save the waveform then will the points in the saved waveform be already interpolated or will it interpolate only when displaying that waveform ?

And sometimes scopes have digital filters (lowpass, highpass, bandpass, bandreject). Of what use would those filters be in real life measurement scenrarios ? Can someone explain by giving some examples ? If anyone has ever used them I'd like to know in what case did you find them useful.

[saturation]

Better scopes save captured raw data, apply postprocessing to the data and you can later retrieve the original data set. 

Low priced scopes, like the Rigol 1052e, have no menu options to allow the dataset to be saved, it only saves a screen capture of the post processing.

Digital filters e.g. mixed analog signal analysis such as remove MHz carrier and view only the modulated audio signal such as in AM radio; filter away 60 Hz ripple on power supplies to get a clear picture of the DC level. 

[pfm]

Low priced scopes, like the Rigol 1052e, have no menu options to allow the dataset to be saved, it only saves a screen capture of the post processing.

I understand if you are referring to a bitmap file, but are you saying the REF and CSV formats that this oscilloscope stores is the interpolated data and not the original sampled data ?

[saturation]

Sorry if it sounds vague.  Referencing the original post:

In the Rigol with sinc on, the input dataset is altered and substituted.  If you save the waveform its the interpolated version only.

You can save Rigol images as bmp, raw data points as .csv, or even screens dump of a REF image as reference .ref file, but these all represent what's on the screen, whatever it is, interpolated or not.  You can load some of those file formats to see the image it stored, but you can't process them e.g. you can't apply sinc to it, remove the sinc on an interpolated image, or apply digital filters to it.

Low priced scopes, like the Rigol 1052e, have no menu options to allow the dataset to be saved, it only saves a screen capture of the post processing.

I understand if you are referring to a bitmap file, but are you saying the REF and CSV formats that this oscilloscope stores is the interpolated data and not the original sampled data ?

[Mechatrommer]

Better scopes save captured raw data, apply postprocessing to the data and you can later retrieve the original data set. 
Low priced scopes, like the Rigol 1052e, have no menu options to allow the dataset to be saved, it only saves a screen capture of the post processing.

rigols do provide save raw data capture to usb drive in form of csv (storage->csv) but be prepared to wait up to like 30 minutes for "long memory and maximum datadepth" setting/capture. few minutes for normal memory length. only take seconds though for "displayed datadepth setting".

the op hasnt mentioned which dso he's talking about, and where the data is saved (pc or usb front panel?) assuming it is ds1052e. sinx/x is not sinx/x, its bezier or polyline sometype, the original data points are lost. so better turned it off for the rest of your life except if you have specific need for it, for eq want to see a nicely curved shape. even if you turn OFF the sinx/x, the saved data are linear interpolated from original data (for smaller ns/div timescale, do your math, the other parm is sample rate). the original data are mixed up in these interpolated points, you need some intelligent to exract those out of csv or datapoints from usb -> pc, otherwise, diy implementation of sinx/x is near to impossible.

[chscholz]

LeCroy scopes save what's on the screen.

The examples below show a 5 ns long waveform sampled at 40 GS/s (i.e. 200 samples).
I saved the waveforms and recalled them back into memory.

The upper grid, memory trace M1, shows the waveform that was saved without interpolation (this
is the default setting in LeCroy scopes). Parameter measure P1 in the bottom left corner shows
that the waveform is 200 points long.

The middle grid, memory trace M2, shows the waveform that was saved with sin(x)/x interpolation
enabled; the number of points (as shown in parameter measure P2) is 2,000.

The bottom grid, math function F1, takes memory trace M1 and performs a sin(x)/x interpolation
in post processing. The number of points here is 1,631.

Digital oscilloscopes typically have Sin(x)/x interpolation. Is this interpolation done only for the display of the waveform ? or does it alter and substitue the real sampled data with interpolated data as well ? If I save the waveform then will the points in the saved waveform be already interpolated or will it interpolate only when displaying that waveform ?

And sometimes scopes have digital filters (lowpass, highpass, bandpass, bandreject). Of what use would those filters be in real life measurement scenrarios ? Can someone explain by giving some examples ? If anyone has ever used them I'd like to know in what case did you find them useful.

[saturation]

Thanks mecha, I hope my clarification helped.  However again another error on my part: the Rigol csv file does contain the raw datapoints but I don't know if this is purely the raw data without the sinc, even if sinc is used on the screen waveform.  I haven't really tried to plot out this data.  In the maximum mode, its 16k points.

However, you can't import the .csv data or run any postprocessing on the dataset with the Rigol, you'd have to do that with external software.

The Rigol is on vector mode by default, points are then interpolated, but if you turn it off, you get the raw sample data.  Likewise the interpolation is given added processing if you turn on sinc.  Is it really sinc?  Not sure, there is a discussion in the archives.

Better scopes save captured raw data, apply postprocessing to the data and you can later retrieve the original data set. 
Low priced scopes, like the Rigol 1052e, have no menu options to allow the dataset to be saved, it only saves a screen capture of the post processing.

rigols do provide save raw data capture to usb drive in form of csv (storage->csv) but be prepared to wait up to like 30 minutes for "long memory and maximum datadepth" setting/capture. few minutes for normal memory length. only take seconds though for "displayed datadepth setting".

the op hasnt mentioned which dso he's talking about, and where the data is saved (pc or usb front panel?) assuming it is ds1052e. sinx/x is not sinx/x, its bezier or polyline sometype, the original data points are lost. so better turned it off for the rest of your life except if you have specific need for it, for eq want to see a nicely curved shape. even if you turn OFF the sinx/x, the saved data are linear interpolated from original data (for smaller ns/div timescale, do your math, the other parm is sample rate). the original data are mixed up in these interpolated points, you need some intelligent to exract those out of csv or datapoints from usb -> pc, otherwise, diy implementation of sinx/x is near to impossible.

[Psi]

rigols do provide save raw data capture to usb drive in form of csv (storage->csv) but be prepared to wait up to like 30 minutes for "long memory and maximum datadepth" setting/capture. few minutes for normal memory length. only take seconds though for "displayed datadepth setting".

yeah, i accidentally did that last month. Clicked the wrong button and saved the entire dataset to csv on usb. It takes ages to save every sample.
I originally thought it had crashed until i saw one tiny section of the progress bar appear.

[Mechatrommer]

The Rigol is on vector mode by default

i havent any success at retrieving "original points only" at 2-5ns/div @ 500M-1GSps, vector or not vector. what we get is a fix 600 points interpolated, where 10 or to 20 points in there are original one... useless! maybe rigol have good intention for that, but.... useless, for postprocessing. i hope someone will be able to get that and report.

Is it really sinc?

absolutely not! iirc tecman or rfloop first did report this. afaik, sincx definition is retention of original data while interpolating the other points using sincx method. heck spline curve is better at doing that, rigol is not even close, they are using variant of bezier curve, which original points only act as "attractor parm" or something like that and then disappear in action, we discussed about this with posted images by rfloop. sincx is studied to be optimum at data retention/signal reconstruction at order of magnitude better than spline. so whats with bezier? bezier only very good at drawing cars!

However, you can't import the .csv data or run any postprocessing on the dataset with the Rigol, you'd have to do that with external software.

this scenario has been discussed everywhere. not just rigol.. but hantek and other china brand. maybe software engineering has not come very well into their academia, or they think the majority of the target customers (which are "hardware" guys) wont give'a'sht about it, esp standalone device like ds1052e, or they want to cut dev cost and time on less important thing (to their mind) which is this... software. worst case is crappy software on pc-based device, rendering the HW almost useless.

but i can see better implementation of this case (fft and sincx) on other china brand such as owon dso, which also reported by rfloop on another thread, i believe they are getting better. look at the bright side

[pfm]

In the Rigol there is an option to switch off the sinx/x interpolation. However the manual doesn’t clearly say if interpolation is switched off completely  –
ON – Set insert mode to sinx/s
OFF – Set insert mode to line
NOTE:  this function is used in Real Time sampling.

“Line” ? meaning linear interpolation ? or what ?

And somewhere in the manual it says under notes for Real-Time Sampling:
At the time base 50ns or faster the oscilloscopes use the sinx/x interpolation to expand the horizontal time base.
Not quite clear what that means. Can someone please explain that to me ?

In both Rigol (DS1102E) and Owon (SDS7102) there is an option called Display Type that you can be toggled between Vector and Dots. Seems like in Dots mode interpolation is not applied and it is the actual sampled points. And I suppose the saved data would reflect that as well. But based on Mechatrommer's comment that is unable to get original points looks like there is some caveat to that as well, atleast for the Rigol. Wonder if its the same way for the Owon. Where is rf-loop when you need him ? 

[saturation]

If you haven't seen this thread on the sinc issue:

https://www.eevblog.com/forum/general-chat/rigol-ds1000e-series-possible-errorfail-in-sin%28x%29x-interpolation/msg39317/

[Mechatrommer]

let me add to this, i just found the link...
http://www.emcesd.com/tt2003/tt080103.htm
conclusion: even for Agilent Infinium 54845a, Sinc is bad. if Agilent implemented to the truly definition of Sinc interpolation, then generally, Sinc is bad regardless of what DSO you are using. FWIW.

[Marco]

sincx is studied to be optimum at data retention/signal reconstruction at order of magnitude better than spline.

Meh, you never know if the ringing sincx has was in the original signal, in the band limited version of the original signal or just an interaction of the aliasing with the interpolation. Sincx is nice for audio and that's about it.

IMO Catmull-Rom splines should be the default. Trivial to compute, prettier than linear, purely interpolating (preserves the original points) and doesn't generate much spurious detail.

[Gall]

sinc is the interpolation that is algebraically exact for a bandwidth-limited signal. That's why it's used. It is important that the sampling frequency should be at least two times higher than the highest frequency in the signal's spectrum in order for sinc to work correctly.

The real signal may easily exceed the theoretical limit and cause interpolation artifacts. That's what usually happens if sinc is abused.

Spline interpolation never works good for FFT but may be reasonably well for waveform display. It is inexact but who cares if it's used just to get smooth line at the screen.

[Mechatrommer]

The real signal may easily exceed the theoretical limit and cause interpolation artifacts. That's what usually happens if sinc is abused.

for digitized signal, i saw somewhere we can FFT it, zero any higher than 2.5X freq components, and inverse FFT to get a signal that is clean. my dilemma is why Mr Shannon choosed Sinc and claim it as "optimum" interpolator if the function does not retain original data? there are few spline algorithms that is better at that, we can find the best parameter to tune it close enough to Sinc function? i'm not sure. i'm yet to see example how Sinc do the interpolation and the interpolated data overlayed with original data on a graph to see the difference. otoh if anyone know the computer code to do Sinc i will be grateful, my head cannot cope with the mathematic right now.

[Gall]

You cannot correctly digitize anything that is above 1/2f_sampling. Consider there is some bandwidth limit on analog side (maybe filter or maybe just ampifier and cable limit). Now you can digitize the signal and interpolate it.

It is hard to do FFT of a continuous signal without artifacts between frames. sinc interpolation is algebraically exactly the same but is much easier to do by usual sliding window-like approach. Both FFT and sinc may and will show serious problems if the Nyquist–Shannon sampling theorem interferes.

[amspire]

You cannot correctly digitize anything that is above 1/2f_sampling. Consider there is some bandwidth limit on analog side (maybe filter or maybe just ampifier and cable limit). Now you can digitize the signal and interpolate it.

It is hard to do FFT of a continuous signal without artifacts between frames. sinc interpolation is algebraically exactly the same but is much easier to do by usual sliding window-like approach. Both FFT and sinc may and will show serious problems if the Nyquist–Shannon sampling theorem interferes.

You are correct for real time capture, but if you use the sampling mode, you can accurately see waveforms that are much higher in frequency then the sampling rate as long as the analog bandwidth is sufficient, and the sample and hold of the A/D has a small enough time aperture.

If you look at one of HP early DSOs - the HP54100A - it had 1GHz analog bandwidth and 40 meg samples/sec. Obviously the best they could do back then with their A/D converters. They had a sample and hold that was less then 100ps, but a 50ns A/D following it. It was lousy for real time use, but very useful in sampling mode with a repetitive waveform. I seem to remember the A/D was only 6 bit, but luckily it was an extremely clean 6 bit, and they used averaging methods to interpolate for 8 bit resolution.

At one time, I had to debug problems in a mosfet switching inverter, and there were not many really fast diodes in the 80s. We had to do a lot of analysis of diode switch on and switch off characteristics down at the nanosecond level, and the scope did the job perfectly. We also had a problem where the mosfet driver was allowing the mosfet to switch on for a few nanoseconds again as the voltage across the mosfet was rising that was wasting some unnecessary energy. The scope let us see that with no problems (with the right kind of fast current transformer).

Today, we might think is was a bit of a joke, but back when it was released, it was a very useful tool.

In a modern DSO where the maximum sampling rate may be 10 times the analog bandwidth, sampling mode is not nearly as useful. If you look at, say, an Analog Devices AD9054A, it can sample at 200MS/S, but the aperture time is something like 0.5ns and the input analog bandwidth is 350MHz. So although the sampling rate is 5 times faster then the HP54100A digitizer, it is five times worse for sampling mode.

The equivalent sampling speed of the HP54100A was something like 10ps even though it only had a 50ns A/D.

[Mechatrommer]

You cannot correctly digitize anything that is above 1/2f_sampling.

if i understand you correctly you are talking about analog->digital conversion stage. then i agree with you, real continuous analog signal will almost always contains higher elements than 2.5X sampling rate, hence, the real signal will never being captured accurately at this stage. hence any filtering or interpolation afterward is just garbage (GIGO) not worth of discussion.

but let us just assume the digitized signal is "correct" representation of the real signal, ie when the ADC reads, it reads the "exact analog value" (to get that, we may leave to ADC designer to handle it). and the real signal does not contain much high frequency elements at greater magnitude so to render digitization process is invalid. with these 2 rules, we can narrow our scope of discussion to "interpolation in the digital stage". at this stage, to remove higher component frequencies is easy using zero'ed FFT output, this is a "soft" brick wall, and then by using inverse FFT, we will get a cleaned up (filtered) signal, the intention is to get more accurate interpolation in the next stage (hopefully), because if we leave the unwanted frequencies in, they will weigh the interpolation process farther out of the way from the expected real signal.

front-end BW attenuation respond also can be handled/corrected by using another method before doing the interpolation part, if we have more accurate BW respond data of the scope, we can "de-attenuate" the digitized signal in FFT. lets assume that is taken care of, our signal is "flat" now.

now let us further narrow our discussion to make it more managable, our input (digital) data "does not contain higher components", they are "clean" and "flat", except... "sampled at limited rate". now the "interpolation" comes in to solve. for "optimum" interpolation method, the captured (digitized) data "must" be considered to be laid exactly on the interpolated data, or at least "weighed heavily" during interpolation calculation, otherwise they will be just a "toy interpolation". this is what confused me. If Sin(x)/x interpolation does not retain original data, then why it is choosen as the "optimum interpolation"? either Mr Shannon screwed up during his research (but i doubt it since Mr Shannon was so good we all choosed to believe that way) or Agilent did not implement the algorithm correctly. i still have no access to "practical implementation of Sin(x)/x interpolation" to make the claim who actually got "screwed up", Mr Shannon or the rest?

algebraically exactly

english please! i'm having trouble understanding this term.

but if you use the sampling mode, you can accurately see waveforms that are much higher in frequency then the sampling rate as long as the analog bandwidth is sufficient

only for "similarly repetetive signals" during each trigger/capture. any "jittering" at each signal capture will render a spurious display of a signal by using sampling mode. am i correct?

[amspire]

only for "similarly repetetive signals" during each trigger/capture. any "jittering" at each signal capture will render a spurious display of a signal by using sampling mode. am i correct?

Yes, you are correct. If each cycle is not identical, sampling is fairly useless.

But this is a limitation engineers had to work with until the last few decades. If you do not have fast enough real time digitizing, you have to work around it.

[Gall]

Yes, you are correct. If each cycle is not identical, sampling is fairly useless.

That's what actually happens if measuring analog signal.

if i understand you correctly you are talking about analog->digital conversion stage. then i agree with you, real continuous analog signal will almost always contains higher elements than 2.5X sampling rate, hence, the real signal will never being captured accurately at this stage. hence any filtering or interpolation afterward is just garbage (GIGO) not worth of discussion.

Yes. One may make the sampling rate fairly high, 1GHz or so by using multiple sample-and-hold ADCs in parallel. One may use low sampling frequency in a strobo mode provided that the input signal is periodic but it never really is. It isn't exactly GIGO, it's just additional source of noise at input which changes its look and feel during digital processing (changes its frequency, turning amplitude noise into frequency noise or back and so on).

[Mechatrommer]

the idea of interpolation and sampling generally, and "digital interpolation and sampling" specifically, is not to consider that kind imperfection, it is out of domain.

[robrenz]

What?

[amspire]

Yes, you are correct. If each cycle is not identical, sampling is fairly useless.

That's what actually happens if measuring analog signal.

If you have a digital scope with very fast sampling, you can capture a random analog signal, a random digital waveform or a modulate RF and you know it is correct. Dead easy.

If you have to use sampling, you have to identify the property you want to check and find a way to check that property with a repetitive signal. This often means much more work, but it is exactly what designers had to do for decades.

Engineers working at high GHz frequencies still have to use sampling, no matter how big their budget is.

[Marco]

It would be nice if the Chinese DSO manufacturers made sampling accessories ... the 10s of GHz sampling ADCs are too expensive for their target market, but a high frequency sampling head doesn't really need to be that expensive.

Of course they can't even be bothered designing active probes, so fat chance.

[Mechatrommer]

What?

we have two domains. 1) capturing mechanism. 2) interpolation theory. capture mechanism makes mistake and send the data to interpolator, we should not blame the interpolator section. this thread is about interpolation fault. if we include the capture fault, then we have doubly cascaded fault. i see (1) and (2) as separate departments, what do you think?

edit: or maybe i've re-started the discussion in the wrong thread. i have few candidates threads last night, i guess it should be here...
https://www.eevblog.com/forum/chat/rigol-ds1000e-series-possible-errorfail-in-sin(x)x-interpolation/