Does Agilent X3000 series use Linear or sin x/x interpolation?

[kg4arn]

I must be missing something obvious ...

I can't seem to find a statement about the interpolation routine used for the x3000 series scopes, for the displayed data.  The Agilent app notes I read say that, in general, Agilent uses sin x/x and that this is usually user selectable.  I can't find any such option on the scope either.

The scope tracings below look to me like the interpolation is linear.  I was expecting a pretty clean looking sine wave with the sample rate at 200 MSamples/sec, if the interpolation were sin x/x.

The input signal is a 10 MHz sine wave from the scope's WavGen.  There is a minicircuits (BLP 15+) 15 MHz, 50 ohm, low pass filter in line.  The input signal is a very clean sine wave with the 2nd harmonic at -70dBc.  Higher harmonics were undetectable on my spectrum analyzer.


My questions are:
1)  Is the interpolation linear?
2)  Why not sin x/x selectable?

[rolycat]

The scope uses sin(x)/x interpolation, and since it never incurs a performance penalty it is engaged automatically when required.

Edited from Agilent's application note 5990-9923EN:

Agilent’s 3000 X-Series oscilloscopes automatically perform sin(x)/x waveform reconstruction filtering. This occurs whenever the scope’s timebase is set to a range such that there would be less than 500 unfiltered sample points across screen.

The scopes perform sin(x)/x waveform reconstruction via DSP hardware, which is part of the scope’s MegaZoom IV ASIC technology. Waveform update rates can be as high as 1,000,000 waveforms/sec, even when the scope automatically engages the sin(x)/x waveform reconstruction filter.

[marmad]

For comparison, here is a similar signal on a Rigol using 1.4MPts @ 200MSa/s; first with interpolation on - then with it off:

[marmad]

I'm assuming the second image is the exact same sine wave sampled at 4GSa/s? Nothing else has changed? And the Agilent is automatically using a 2MPts record length, correct? If so, that is rather odd.

[kg4arn]

The scope uses sin(x)/x interpolation, and since it never incurs a performance penalty it is engaged automatically when required.

Edited from Agilent's application note 5990-9923EN:

Agilent’s 3000 X-Series oscilloscopes automatically perform sin(x)/x waveform reconstruction filtering. This occurs whenever the scope’s timebase is set to a range such that there would be less than 500 unfiltered sample points across screen.

The scopes perform sin(x)/x waveform reconstruction via DSP hardware, which is part of the scope’s MegaZoom IV ASIC technology. Waveform update rates can be as high as 1,000,000 waveforms/sec, even when the scope automatically engages the sin(x)/x waveform reconstruction filter.

Thanks, I missed that in my search.

If I understand this correctly it switches to sin x/x when there is <500 unfiltered sample points, then for:
  1 channel active (4GS/sec) the interpolation is linear on the screen until the horizontal sweep is 12.5 nsec/div or less.
 2 channels active (2GS/sec) the interpolation is linear on the screen until the horizontal sweep is 25 nsec/div or less.

So for the slow sweep rates there are many more than 500 sample points and when you zoom the trace you see the choppier linear interpolation.

[kg4arn]

I'm assuming the second image is the exact same sine wave sampled at 4GSa/s? Nothing else has changed? And the Agilent is automatically using a 2MPts record length, correct? If so, that is rather odd.

Yes, the second image is the exact same sine wave.  Only the scope horizontal sweep was changed.

The Agilent doesn't tell me how many memory points it is using.  I have the standard 2 Megapoints and there is only one channel on.  So I assume it is the full 2 Megapoints.

[rolycat]

As I understand it when displaying the waveform the scope always connects the available sample points linearly - whether they are read directly or interpolated using the sin(x)/x reconstruction filter.

[kg4arn]

Got it.  Displayed linearly but at the faster sweeps the sample points are first filtered sin x/x then displayed.

[AndyC_772]

There's an FAQ here:
http://www.home.agilent.com/upload/cmc_upload/All/2000_3000_X-Series_FAQ_2011-07-07.pdf

...which says...

18)
Can I turn off sinx/x?
No, sinx/x cannot be turned off.


I've tried your experiment on my own scope and get exactly the same results, apart from the fact that my measured waveform height is exactly what's being generated (315mV pp) which I guess is because I don't have an external filter between the wave gen output and the scope input.

In terms of the wave shape, I get exactly the same result. The waveform looks quite badly stepped and I'm sure it's joining points with straight lines. As expected, the lines each span 5ns @ 200 MSa/s.

Speed up the time base and the sine wave looks great, of course - but I tried a separate function generator anyway just in case, and it makes no difference.

It seems a shame it only uses sinx/x under certain conditions, because the scope certainly can do it and it looks much better. Below is a plot of a 150 MHz sine wave @ 1ns/div, which looks smooth despite only having 4 samples per grid square.

[kg4arn]

Thanks rolycat, marmad,and AndyC_772.

I got to thinking about why Agilent may have done it this way.  I usually work with sinusoidal signals so I like to see nice and smooth sinusoids.  But since all signals are not sinusoidal, I decided to compare a sine and a square wave. 

It looks as though Agilent's method is a good trade off, especially when you are trying to distinguish an unknown signal shape.

I compared a 5 MHz sine with a 5 MHz square wave (rise time 5 nsec) and it looks like you can distinguish the sine from the square wave pretty well at 50 MSample/sec:  right where you would expect the sample rate to be about 2X the frequency of the square wave's 3rd harmonic.  At the slower sample rates the angularity of the sine wave clues you in that you may not be able to distinguish the wave shape correctly.

I wonder what sine x/x would look like under a similar comparison?

[marmad]

I wonder what sine x/x would look like under a similar comparison?

Hi kg4arn,

I tried to make a similar comparison for you on the DS2000 at the 20M, 50M and 100MSa/s rates - but please note that the rise time of my 5MHz square wave is ~15ns, so it's slightly more trapezoidal to begin with.

[kg4arn]

Thanks marmad,

Are you able to do a 20 Meg Sample rate? 
I suspect that may be where we see a bigger difference.

The sin x/x clearly produces better looking waveforms at the 50 Meg sample rate. 
I am just wondering if you go to a lower rate, will the sin x/x start to show us more of a sine than a square wave? 

[marmad]

Are you able to do a 20 Meg Sample rate? 
I suspect that may be where we see a bigger difference.

Done. Added above to the original post.

[marmad]

The sin x/x clearly produces better looking waveforms at the 50 Meg sample rate. 
I am just wondering if you go to a lower rate, will the sin x/x start to show us more of a sine than a square wave?

Unfortunately, one annoying thing about Rigol is the lack of written information about what they're doing. They're clearly using sin(x)/x most of the time (when you have 'vectors' choosen - which is what the menu item is called) but perhaps they're using linear interpolation below a certain number of sample points per div?

[kg4arn]

Did the source for the upper trace switch from a sine to a triangle on the 20 MSample trace?
edit:  I didn't expect it to be such a perfect triangle, but I guess that it could be since it is an integer number of samples per period.

The Rigol implementation appears well done.  I like the tracings better.

On the documentation:  even with Agilent a lot of information isn't in the manual for the particular device.  You have to search for a variety of app notes and sometimes it isn't there at all.  On the plus side they do respond with answers to questions.  Rigol seems responsive also when I have called them on the phone.  email hasn't worked for me with Rigol.

[marmad]

The Rigol implementation appears well done.  I like the tracings better.

It appears they've optimized the Agilent for pure speed - although it's curious they don't offer a firmware sin(x)/x interpolation as an option (with a corresponding reduction in speed).

Did the source for the upper trace switch from a sine to a triangle on the 20 MSample trace?

No, still the sine wave. Here are the 20M and 50M sampled sine waves with the sample points visible below.

[colinbeeforth]

AndyC_772 said:
It seems a shame it only uses sinx/x under certain conditions, because the scope certainly can do it and it looks much better.

kg4arn said:
I usually work with sinusoidal signals so I like to see nice and smooth sinusoids.
Also:
The sin x/x clearly produces better looking waveforms at the 50 Meg sample rate.

Gentlemen,

Firstly, let me apologise for taking your comments a little out of context.  However, I've heard enough discussion of sinx/x interpolation to make me feel queasy, so here goes.  An oscilloscope is a tool, it should show the input signal with fidelity.   Aesthetic considerations of waveform shape seem irrelevant to me.  If an input waveform is judged as ugly, the scope should show it as ugly.  Since the scope cannot know anything about what the waveform does between sample points, any sort of artifice in interpolation should be avoided.  LInear interpolation many not make pretty waveforms, but if you have 10 or 20 samples for each cycle of the highest sine wave component, you have a reasonable basis for judging what the waveform is doing.

If you use sinx/x interpolation on an undersampled waveform, it still shows a sine or sine like screen trace, but they may not be real.  With linear interpolation, the waveform becomes obviously spikey if it's undersampled.  This may be considered ugly, but it's a clear warning that there are insufficient samples to reconstruct a true representation of the incoming waveform.  In reality that's all that a DSO can ever do, construct a representation, since it truly knows nothing about what the incoming waveform does between sample points.  If the scope only uses linear interpolation, but also highlights (brightens) the actual sample points, the risk of misinterpreting a waveform as true when it may be an alias is greatly reduced.  With linear interpolation, undersampling looks ugly.  That is it's great advantage, ugly=untrustworthy.  With sinx/x interpolation, there is no visible warning that you are on dangerous ground.  Also, the theoretical basis for sinx/x requires that you filter the input with a steep low pass filter, with a corner frequency at half the sample rate.  (The minus 3dB of the input's analogue bandwidth is nowhere near sharp enough.)   Without a sharp anit-alias filter, the theoretical basis for using sinx/x is absent!

Because sample rate varies widely with timebase setting, such a filter would be quite impractical to build, and that's why DSO makers don't have an anti-alias filter button.  FFT vibration and audio analysers have far more constrained operating parameters, so anti-alias filters are common and sinx/x interpolation is appropriate.

On the philosophy of scope design, the manufacturers have a tough job.  Scopes get used in such varied applications it must be difficult to build one scope that fits all.

With regard to some of the example waveforms, it seems that many modern DSOs don't announce the fact that they have shifted acquisition mode from repeated single shot mode to Random Interleaved Sampling.  RIS allows synthesis of a sample rate perhaps 20 times faster than the max rate of the digitiser.  A scope should really flag that mode change to the user, but I've noticed that many don't.  My cynical assumption is that it makes the waveform look "nicer".   DSO makers need to trust their end users with all the information, although I won't be holding my breath until that day comes...

Cheers, Colin

[jahonen]

If you use sinx/x interpolation on an undersampled waveform, it still shows a sine or sine like screen trace, but they may not be real.  With linear interpolation, the waveform becomes obviously spikey if it's undersampled.  This may be considered ugly, but it's a clear warning that there are insufficient samples to reconstruct a true representation of the incoming waveform.

Cheers, Colin

I'd like to point out that this "spikey" warning with linear interpolation works only near the undersampling limit, but if there is very substantial undersampling (alias) of a repetitive signal, then the signal will look nice even if it is undersampled with linear interpolation. So even that is not universally infallible.

Regards,
Janne

[Wuerstchenhund]

However, I've heard enough discussion of sinx/x interpolation to make me feel queasy, so here goes.  An oscilloscope is a tool, it should show the input signal with fidelity.   Aesthetic considerations of waveform shape seem irrelevant to me.  If an input waveform is judged as ugly, the scope should show it as ugly.  Since the scope cannot know anything about what the waveform does between sample points, any sort of artifice in interpolation should be avoided. 

I fully agree. I also find the obsession with "nice" waveforms a bit strange, because as you say a scope should reproduce the actual signal as close to the truth as possible.

On the philosophy of scope design, the manufacturers have a tough job.  Scopes get used in such varied applications it must be difficult to build one scope that fits all.

Indeed. I hadn't thought about it much in the past as I usually don't buy these types of scopes (entry level) but now I have to say I find Agilents approach (Sin(x)/x interpolation can't be switched off and is only used at certain settings) pretty bad. With  my old LeCroy Waverunner, Sin(x)/x is part of the math section (aka all the other stuff that makes waveforms on screen look different from the signal that comes in) and in my opinion this is where it belongs. It should not be on by default, and most certainly the user must be able to switch it off.

With regard to some of the example waveforms, it seems that many modern DSOs don't announce the fact that they have shifted acquisition mode from repeated single shot mode to Random Interleaved Sampling.  RIS allows synthesis of a sample rate perhaps 20 times faster than the max rate of the digitiser.  A scope should really flag that mode change to the user, but I've noticed that many don't.  My cynical assumption is that it makes the waveform look "nicer".   DSO makers need to trust their end users with all the information, although I won't be holding my breath until that day comes...

I only played around with scopes like the Agilent DSO-X2k/3k or the Rigol DS4000 for a short time and didn't pay attention but again my LeCroy Waverunner does indicate clearly when it is using RIS (which also has to be enabled first). Can't remember on the scopes at work as I never used repetitive sampling modes, but I would think that they do indicate once they use repetitive sampling mode.

[AndyC_772]

Sinx/x interpolation correctly fills in the data between the sample points under the assumption that there are no components of the input signal which are higher in frequency than 1/2 the sample frequency. For a scope like an 3000X that's a pretty good approximation; the sample frequency isn't just 2x the nominal 3dB bandwidth, it's 8x for a 500 MHz model and even more than that for the lower bandwidth versions. That's why a 'brick wall' filter isn't needed.

It's certainly a much better approximation than piecewise linear interpolation, which shows a wavefowm which is completely unrepresentative of the incoming signal. It's not just aesthetically 'ugly', but also objectively wrong. You'll never recover information in the signal which is filtered out by the bandwidth limitation of the input stage, but piecewise linear interpolation is putting high frequency "information" into the reconstructed signal which has no physical justification. It's OK only provided you just use it to interpret where the dots are - and I presume this is how you're choosing to view the signal when in this mode.

[jpb]

To reconcile the apposing views, it is good to note that it appears that Agilent only performs sin(X)/(X) interpolation when the filtering represented by the input circuit of the Scope means that there will not be under-sampling.

i.e. it is used to fill in points when the sample rate is at its maximum and half the maximum sample rate is well above the 3dB bandwidth of the scope as AndyC_772 points out.

It is not used to interpolate on zooming in from a long time base which is sampled at a lower rate (if I understand  the earlier quote from the app note correctly) which is perhaps the circumstance where Sinc(x) interpolation might be misused as pointed out by colinbeeforth and others.

[AndyC_772]

Maybe that indeed is it. The 3000X uses linear interpolation because aliasing is likely when the sample rate is artificially low, because a long record length is required and the number of samples/sec has to be correspondingly reduced. If the front-end's bandwidth is high compared to the sample rate, there's no anti-alias filtering, and the sampled signal cannot be assumed to be free of aliased signal components. Sinx/x may indeed 'smooth over' a genuine problem, and it makes sense to display an 'ugly' waveform.

At higher sample rates, the sampling speed greatly exceeds the scope's analogue bandwidth, so the necessary AA filtering does exist as a natural consequence of the front-end's roll off. In this case, sinx/x is absolutely the correct thing to use.

Conclusion: Agilent actually know what they're doing. Who'd have thought it? 

[jpb]

of course at 4GS/s even at the fastest time base of 1ns/div there will be 4 measurement points per division so the difference between sinc(x) sampling and linear sampling is likely to be pretty small.  It will perhaps show more if more channels are being used and the sample rate is reduced to 2GS/s.

With 2MS (all channels) then zooming in a long way might result in well under one point per division but for the zooming case sinc(x) isn't valid.

So a cynic might say that where it is valid it isn't really needed and where there are a lot of points to fill in it isn't valid so you can't use it!

[marmad]

It is not used to interpolate on zooming in from a long time base which is sampled at a lower rate (if I understand  the earlier quote from the app note correctly) which is perhaps the circumstance where Sinc(x) interpolation might be misused as pointed out by colinbeeforth and others.

But therein lies the rub, doesn't it? As evidenced by kg4arn images, it's doing a poor job of reproducing waveforms with linear interpolation at sampling speeds which are perfectly adequate for using sin(x)/x interpolation for more precise (forget nice/ugly) reconstructions. It seems to me that the simplest way around this problem is to make the type/use of interpolation user-selectable.

So a cynic might say that where it is valid it isn't really needed and where there are a lot of points to fill in it isn't valid so you can't use it!

This is wrong - again, as clearly visible in the images.

[Wuerstchenhund]

Conclusion: Agilent actually know what they're doing. Who'd have thought it? 

Maybe. But then the question remains why you can't switch off sin(x)/x interpolation on their entry level scopes but you can on their higher end scopes which are even less likely to run into under-sampling problems.

I really like Agilent stuff, but somehow I get the feeling that if they continue this way with their entry-level scopes, the next model will only have an Auto-Set button.