Rigol DS1000E series: Possible error/fail in Sin(x)/x interpolation?

[rf-loop]

Hello!

I have look "Rigol DS1102E Bandwidth problem" video (InstrumentVu)
( )

After this video I start some inspection.

In this video I see littlebit bad BW problem.
First I think that it is natural becouse Rigol use in lon memory mode 500Ms/s splitted to two channel (in two channel mode) So it is 250Ms/s CH1 + 250Ms/s CH2.

But something is still wrong... I think and look it many times.. also I start test with my own. (before my own BW test was really good. But I did not test Sinx and two channel in long-mem mode)

Oscilloscope is "100MHz". Of course it is good to carefully read machine specifications and also understand these before thinking what it can do and what not. Sad that Rigol have write specs where manufacturer do not tell this clearly in specs table. In specs table read that 500Ms/s (but not tell that it is splitted with two channel in LongMem mode).

On this video I see BW problem and I can easy see that something is wrong now becouse there is Sin(x)/x interpolation. Clearly it can not be so bad if all is ok. I remember Agilent related old article. This is not what I can expect with my experience with scopes. Also I know that analog channel in this scope is enough good. (I have tested it very carefully, freq response and risetime) This BW problem looks strange. Thinking...Nyquist..

I make some inspection with my scope in my lab. Oh what I see. Now my opinion is that Rigol have made something wrong! They need very fast do firmware update if problem is there.

With well made analoque channels and all other parts freq response and filtering this sample rate and right Sin(x)/x interpolation must give better BW.
(please read this article: http://i.cmpnet.com/planetanalog/2009/02/Sin(x)x_Agilent.pdf
Sin(x)/x Interpolation: An Important Aspect of Proper Oscilloscope Measurements
By Chris Rehorn, Agilent Technologies)

Here is pictures from my test and from this article.

http://www.box.net/shared/7ucvts853u

This picture is combined pic: inputs 100MHz.
Oscilloscope in LongMem mode, realtime. Lines: Sinx OFF, curves: Sinx ON and this made for just same captured signal.

Compare this with picture inside article:

http://www.box.net/shared/ng11pyctka

(I'm sorry I can not insert pics directly forum)


after this work I make my own opinion: Rigol have make mistake in Sin(x)/x handling. (I hope it can solve with new firmware. More bad it is if this stupid error is not in firmware. (I do not know how this is processed inside machine) This kind of error must not be in production so that customers need find it. This work need do inside Rigol test lab before as in prototype period! 
This problem can only littlebit avoit if use (slow) averaging and/or Equ-Time sampling mode.

I think Rigol need to take receive "consultation".  They need ask apologize from customers and very fast correct this issue if they want keep they faces.

[jahonen]

Sin x/x has trade-offs in implementation. Closer the Nyquist you want to go, more samples you'll need to do the interpolation, and the step response becomes more ringy. 100 MHz is quite close to the 125 MHz Nyquist (ratio of 0.8). Strictly speaking, the sampling theorem deals only with stationary signals. Transients are considerably more difficult to deal with, and that is unfortunately the primary usage what we use oscilloscopes for.

CD players reproduce 20 kHz sine with only 44.1 kHz sampling rate quite nicely (ratio of .91), but in expense of relatively long latency. Of course that does not matter for that particular application.

Of course this drop in effective bandwidth should be mentioned in the manual.

Regards,
Janne

[rf-loop]

But Rigol do this mathematics wrong. There is error in softw. It is very easy to find if look these pictures and result with open mind and tightly also remember and undertand what is basics for sinx. Agilent paper it is right, Rigol solution is wrong!

[jahonen]

I see that interpolated curve does not match the sampling points. It is just due to choice of cut-off-frequency in lowpass-filter to do the sin x/x. Sin x/x is the impulse response function for ideal low-pass filter. However, sin x/x is not time-bounded function and thus to exactly calculate the result, one would need infinite number of samples to reconstruct the waveform. Thus in practice, one must truncate the function and the result is not exactly the input waveform. Another thing is that it is not feasible to calculate the interpolation directly in real time other than using the FIR-filter version (at least with this kind of sampling rate and price).

I'd say based on that evidence that the filter function is correct but cutoff of the interpolation function (e.g. FIR-filter) is just on the low side. For my Agilent MSO6034, specification says that sin x/x cutoff is sample rate/4 or analog bandwidth whichever is less, thus the theoretical maximum. Can you measure what is the cutoff exactly, i.e. when the interpolated waveform approximately match the sampling points?

Regards,
Janne

[rf-loop]

Hello!

I have tell that Rigol manual have wrong information. Yes, in my manual but, something have also happend...

Rigol have now new datasheet: DS1000E Series Datasheet 2010-03-02

and in this datasheet is corrected samplerates as you can see in this partial copy:

http://www.box.net/shared/g1iq9n4d6f

Also new user manual (jul 2009) have this right info.
(I have read old versions what I have)

Can find Rigol "better" internet sides: (not ...rigolna!) These sides have also FW updates to download.
http://www.rigol.com/templates/T_Support_en/download.aspx?nodeid=637&pagesize=6&pagenum=10

back to topic. Later  as I have time I try some more look  for this sinx/x cutoff

[rf-loop]

Another thing is that it is not feasible to calculate the interpolation directly in real time other than using the FIR-filter version (at least with this kind of sampling rate and price).

I'd say based on that evidence that the filter function is correct but cutoff of the interpolation function (e.g. FIR-filter) is just on the low side.

jahonen: After more testing, I think about the same.
-----------------------------

Here is picture: http://www.box.net/shared/ufsr6rq45r  (download it and look with original size! )

Picture tell maybe enough. Exactly cutoff freq I do not still know. (or there is not )
In picture there is several measurements with different frequencies with same level input signal.
1 to 100MHz.



Also some risetime test. Input 50 ohm terminated and source HP8161A pulse generator. HP risetime around <1,3ns. Pulse period now 100ns and width 50ns. Amplitude 350mV. Scope 50mV/div. Scope 2ns/div  250Ms/s.
Sinx ON long time average risetime ~6,4ns.
Sinx OFF long time average risetime ~5,25ns

After this if I can "only thinking with eyes":  My opinion is that 1102 is maximum "~50MHz scope" if use 2 channel and LongMemory mode.

[Mark_O]

Another thing is that it is not feasible to calculate the interpolation directly in real time other than using the FIR-filter version (at least with this kind of sampling rate and price).

I'd say based on that evidence that the filter function is correct but cutoff of the interpolation function (e.g. FIR-filter) is just on the low side.

jahonen: After more testing, I think about the same.

Here is picture: http://www.box.net/shared/ufsr6rq45r  (download it and look with original size! )

rf-loop,

your first signal captures looked pretty bad, and seemed to exhibit a failure to fit.  However, the problem there was that due to randomness, the instantaneous high-excursion samples you captured were not the same samples that the sin(x)/x interpolated.

This was confirmed by your excellent mosaic series.  In each case, the instaneous single captures fell within the envelopes of the sin(x) on the persistent traces.  Also, the Agilent article you referenced by Chris indicated waveform reconstruction could be successful with as few as 2.5 samples per cycle.  And at 250 MSa, it just barely meets that criteria.  Of course, to be most effective, you need very good filters for that, which the Rigol probably suffers a bit on.  But I do think it still qualifies as more than a 50 MHz scope, as you suggested.

Lastly, if there was anything actually wrong with the sin(x)/x implementation, I'm doubtful that Rigol could do much about it.  Most likely, this function is calculated by the DSP chip (a 400 MHz Analog Devices BlackFin ADSP-BF351 chip).  You can read more about them at Analog Device's site.

- Mark

[rf-loop]

Mark_O

Pictures.

I have first run scope with Sinx OFF. Persist infinite. (so that can look all area what ADC samples have make)
After enough "persist" I have STOP scope. Then I store picture where you see lines between sample points and see all this "persist".  Then I switch Sinx ON. (scope remais STOP) And now Sinx curve is on same perist what is on upper picture. So, lines and Sinx are produced exactly from same ADC data points! These all pictures upper and lower are made with same rules.

"Sinx" curve do not hit any real sample point as it need do if sinx function is well made.

You can test it yourself.

Run scope with example 50 ...100MHz sine signal.... mode line... persist infinite.... long mem 2 channel (so this can see more clear becouse samplerate 250Ms/s)

After you see display as my upper pictures... press STOP

On the STOP state switch Sinx ON -- OFF -- ON .........

After this you maybe give opinion if something is wrong or not?  You can take pictures and look them as transparent...you can see where Sinx curve hit lines or most important... TRUE sample points. Sinx can not forget real samples... just as Agilent teach us.

I have see hundreds of oscilloscopes. Some of these are digital scopes and some of these have also Sin(x)/x.
Never I have see this kind of "sinx"what Rigol now show. (this is not big problem and most of things I am very satisfied specially in this price class)
 Some tell me that it is expensive and take time to make sinx ok.
I can ask... how my one Tektronix from 80's can do it without problems. Yes it is digital scope, CRT (vector)monitor, tiny old microprocessor... it do not lost any real sample points as it do some kind of Sinx and it do not need long capture of data as it do it. It do it more fast what my eyes never can separate. (model is TEK2440 workhorse) And just same with many Agilent/HP old workhorses. Now we speak about machines in y2k what have digital processing capacity just with different decades of handling power

Now we have machine with Blackfin processor, Altera, 10 * 100MHz (independent what is ADI code) ADC's and this machine can not do  better Sinx... really this sinx func button name is wrong. This scope have never see Sinx. This is not problem for me but... take example EEVblog one video... BW problem... yes it is not only Sinx but it makes it more worse becouse it works wrong (and sometimes I think that before make some public...maybe it is better first inspect and think and then do it also with data and not only with shaking all things like....).
For me it is like cosmetic problem becouse I do not need Sinx at all. (becouse this kind of construction can not do it right, it brokes all rules...)

But with this small detail I hope Rigol make better work. Overall this is good equipment in its class.

So maybe I want littlebit "adjust" this FW and change this function name in menu...
(but I do not want flash in new FW becouse I can not know how to take back if something goes wrong)

[armandas]

I tried this with a 125MHz signal (see attached pictures). With the settings I used to measure, the sin(x)/x seems to be working.
I used only one channel, long memory - with two channels enabled, my waveform was jumping around like crazy. While it was jumping, I thought I'd set the acquisition mode to average, and the sin(x)/x seemed not to work in this case. This may be firmware bug or something, I don't know.

[rf-loop]

Yes it  "works" just like your nice pictures.  

Yes it "looks like" Sin(x)/x BUT it override every single true sample points! True digitized sample points are only "true" what are meaningfull and Rigol loose all them with this kind of bad "sinx".

[armandas]

Yeah, I see your point now.

[colinbeeforth]

From what the video shows, no fault needed to explain what is observed.  the scope is workin gfine, it is an alias, plain and simple.

Hit the scope with 100MHz, and sample at what?  The timebase setting is 2 nanoseconds per division or displaying a total time, screen left to right of (menus on) 20 nanoseconds.  With a single channel running, the digitiser is sampling at 1 gigasample per second, you have got only 20 actual valid samples to show two complete sine waves - marginal.  When you switch to two channels, there are only 10 samples as the digitiser is shared between the two channels.  To reconstruct a rough representation of a sine wave you need at least 10 samples per sine wave.  Alias.  Nothing special, no errors, just undersampling.  The loss of amplitude demonstration is also no fault.  Sinx/x interpolation is the worst most stupid concept ever invented, and it has caused huge amounts of grief.  I sold high end DSOs for a few years, and saw heaps of side by side shoot outs, and quizzical customers.  Sinx/x interpolation tells lies (I'm not exaggerating) by drawing nice sine waves through miserably undersampled waveforms - they look pretty, but bear little resemblance to what might actually be there.  Don't use sinx/x ever, is my recommendation, it just tricks the brain into thinking "It looks good, maybe it's true."   It is downright dangerous.  LeCroy knew this and never had sinx/x interpolation on any of their earlier high powered scopes - but I have not looked at their range for 5 years, so I don't know what they do know.  Why it is a good idea to ony have linear interpolation? - if you under sample, the waveform looks like the Italian Alps and it is so distinctive, you know immediately to not trust the results as it is undersampled.  Many people seem to get it into their heads that 1 nanosecond sampling time is slow - it's blingingly fast, and we can't go a lot further without some serious money or new physics.  A light beam travels only 0.3 metres in that time for heaven's sake!  For the price, Rigol's 1 nanosecond is quite amazing.

There is a real problem in all of these small DSOs though.  And it is every bit as serious, maybe worse, it's display alias.  Assume 2 channels, say 1millisecond/division, a single shot sweep captures 240k points at 20 megasamples per second - which is an impressive amount of data.  Say there is a glitch in there, with just one data point 3 times higher than a long series of TTL pulses.  Will you see it?  It's highly unlikely.  The actual acquisition memory will be filled to 240k, but only about 112,500 of these points are displayed, or are they?  Since the waveform display area, with menus off, is only about 280 pixels wide.  How are the 112,500 data points reduced to be shown on the 280 horizontal pixels of the display???  There is your problem, the data is decimated, chopped out and reduced to only showing approx 0.28% of the total data points.  How on earth can you expect to see a glitch or spike with that???  Your chances of seeing it are very very slim.  That is a far more important issue than the screen update rate.  Who cares if it updates at 1000s per second, I can't see 24 frames per second with any reliability, and LCDs are slower to respond than that.  This makes the DSO is almost totally blind to spikes, and all that amazing acquisition memory is effectively rendered useless.

So, what is that you're saying?  Switch on that annoyingly slow Peak Detect mode?  Why should I do that?  I didn't see anything wrong.  Use zoom, and wind the knob through 112 thousand data points?  That is tedious as hell, and I didn't see anything that would make me the slightest bit suspicious that it was necessary.  Unless someone can explain how the DSO gets around this problem, I think we have a deal breaker for cheap DSOs.

Granted, if my primary work was unravelling the nightmare of USB or serial eeprom comunications, I could pretty much ignore glitch display, as I'd be using zoom all the time, to grind my way along the serial data stream and work out what was happening.  By comparison, an analogue scope scans the screen for for 50% or more of the time (the invisible retrace is quick).  Between the slow response of the human eye and the phospor, I'd see a flicker that would make me suspicious.

I have an older LeCroy 9310M.  If set to its max 50k acquisition length, then display a waveform 50k long with one single point at 15 volts over the top of a 0-5V pulse stream, and you will see that point on the screen without fail and without having to invoke any capture systems or take any other activity.  It it's there, it'll show you.  That is what all DSOs need to do, to be as useful as an analogue scopes..  I dearly hope that someone can explain why the Rigol 1052E will show this in it's display,  I would buy one - getting parts for the LeCroy is a nightmare and I know I won't be able to keep it going for ever, but I don't want to only have a 1 in 400 (0.25%) chance of seeing something that turns up, and sure as eggs, it's the thing you don't see that will bite you on the rear...

Cheers, Colin

[rf-loop]

May be you can explain what is wrong in this Chris Rehorn article:

http://i.cmpnet.com/planetanalog/2009/02/Sin(x)x_Agilent.pdf

As long as we do not violate Nyquist... and this is VERY important point to remember!
(example, some peoples may be think that more wide analog bandwith is good... no... it is not! (and it is very important also if we think aliasing... (I have not see cheap oscilloscope where is (very expensive) analog front end and analog adjustable filter and parameters are adjusted with samplerate)

I think also that Sin(x)/x function in many scopes are just as you tell... only lie.
Example this Rigol (and many nearly equal scopes) there is NOT true Sin(x)/x iterpreter.
There are many things what goes wrong and then we can se these "nice curves" what are only more lie than linear (or even better, only points.)

It totally different case if we do good sin(x)/x.

Two leaders in they own class: Agilent (or more better in history: Hewlett-Packard) and Tektronix have done quite good work.
If LeCroy tell that no need and it is only bad... of course they tell it if they can not do it.

But, for this Sin(x)/x case I hope you can tell what errors are in this Chris Rehorn (Agilent) pdf.

So what is exactly wrong.

Then if we talk about this kind of "fake" sinx/x what is in Rigol (and many others), then we can say that it is really as you tell:
" Sinx/x interpolation tells lies (I'm not exaggerating) by drawing nice sine waves through miserably undersampled waveforms - they look pretty, but bear little resemblance to what might actually be there.  Don't use sinx/x ever, is my recommendation, it just tricks the brain into thinking "It looks good, maybe it's true."   It is downright dangerous.  LeCroy knew this..."  If LeCroy do not understand theory it is very fun. (maybe reason is littlebit different... maybe they can not)

Of course Sin(x)/x give very bad things if (and many times it is) scope analog part is not designed with very tight rules for this and then whole sinx/x is done with very cheap way... only some kind of "smooth" function.  (real Sinx/x it works only if Nyquist rules are not violated in any point...from input connector to A/D conversion and all these parameters are also with calcualtion.)

Most bad thing in Rigol solution is that it put to garbage all real sampled values (maybe it use these but... to the screen they do not come. On the screen we see onlu total lie.  This can not do. If you see this happend you know that something is very bad... so we make just lie Sinx/x and then we can see just what we see on Rigol display and also many others... only "nice" curve... but totally lie. Nearly all points on the curve are out of true. Sinx/x must follow TRUE sample points just as we see Chris Rehorn paper. Of course we can not do this in practice if we violate all rules in all points of system. (nyquist is very highly violated in system and then some kind of filterin what make look like Sinx/x.) So also I can recommend, do NOT use it if you are measuring something. If you like look only "nice curves" you can use it... but this is only for some fun... not for serious working.

Yes I know that with this price it is nearly impossible to make this kind of analog front end what is need for good oscilloscope with "true" Sinx/x.

As I before tell my one very old Tektronix have Sinx/x and curve go exactly so that curve hit all real sample points.  Looks just same as Chris Rehorn paper. How they do it? With very old microprocessor? Some try tell me that it is very heavy calculation and so they in Rigol use some kind of (DSP) FIR filter. I am littlebit surpriced how these new fast processors can not do this. (more I think that this chinese boy who have desingn part of this scope ( set some parameters and test) have forget his middle scool books to home...).  As long as we forget every real sample point we are just "Deep in the swamp" and all what we see in display is just nice looking garbage. (line between sample points "may be" garbage if want think so ... but ...now we have loose every true sample points...only true thing what we have before this Sinx/x fake interpreter.

[rf-loop]

I want add this as explanation and clarify my message before:


http://staff.science.uva.nl/~rein/multimedia/sampling-interpolation.pdf

"3.2 Sampling

How many samples from a signal are needed? I.e. how large (few samples) or how small (many
samples) should we take ¢t. Here we will consider the more precise question:
How many samples are needed such that the original signal can be perfectly reconstructed
from the samples?


The answer to this question has been answered by Nyquist and Shannon and it therefore is called
the Nyquist-Shannon sampling theorem.

Theorem 1 (Nyquist-Shannon Sampling Theorem) A periodic signal can be reconstructed
from its samples in case the sample frequency is larger then 2 times the maximal frequency in
the signal.


This boils down to the fact that we need more then 2 samples per period of the sine/cosine
wave of the highest frequency in the signal.
A signal obtained using a measuring device is band-limited. Physically it is impossible to
measure in¯nite high frequency signals. The highest frequency that occurs in the signal might
nonetheless be much higher then the frequencies one is interested in. A characteristic example is a
sound wave. In case it is our ¯nal goal to reproduce the sound for humans to listen to, then there
is no need to record all frequencies that are present in the sound. The human hearing system
cannot hear sounds with a frequency higher then 22000 Hz. Therefore the sample frequency for
sounds can be set at something higher then 44000 Hz.

But what happens when we sample a sound signal at 44000 Hz containing frequencies larger
then 22000 Hz. These high frequencies do not just disappear from the recording; they will
introduce frequencies lower then 22000 Hz in the recorded signal. This efect is called aliasing.
To prevent aliasing we need to remove all frequencies in the signal larger then 22000 Hz before
sampling at 44000 Hz."

I think it is easy to think what it means in oscilloscope.

As long as Nyquits-Shannon is highly violated in Rigol (and many others) we can not see good Sinx and we have lot of aliasing problems. And this can not solve good as long as analog bandwith characters before A/D is bad or very bad (for this purpose).
Oscilloscope is only compromice and what we see is sum of many errors.

[jahonen]

Sinx/x interpolation tells lies (I'm not exaggerating) by drawing nice sine waves through miserably undersampled waveforms - they look pretty, but bear little resemblance to what might actually be there.  Don't use sinx/x ever, is my recommendation, it just tricks the brain into thinking "It looks good, maybe it's true."   It is downright dangerous. 

Actually wrong. Linear interpolation is very much more wrong, if the Nyquist criteria is satisfied. The theory behind that is proven to be correct. The best reconstruction function for bandwidth limited sampled signal is the sin x/x. If you get wrong results from sin x/x, then you'll have inadequate bandwidth equipment for your measurement. Alias actually does not happen until some frequency component of incoming signal does not exceed fs/2. When that happens, both linear and sin x/x will result equally wrong results (try it out if you don't believe me!).

A comment on "computationally heavy" sin x/x. Exact sin x/x reconstruction even for single point of time is not possible since it requires knowledge of the time samples from minus infinity to positive infinity. That obviously takes too long time and uses too much memory. So what is usually done, is that the sin x/x is truncated in time, or "windowed". The tradeoff of this truncation is that response transition band becomes non-zero, there is some ripple on the response and stopband attenuation is not infinite. But then it can be computed with reasonable effort, using the FIR-structure. Longer you'll make the window, more ideal the result, but it takes longer to process the samples and your screen update rate will go down. Yes it is perfectly possible to this with a 8-bit µP (or even with analog bucket-brigade delay line and some amplifiers!) but I don't think you'll get very fast waveform screen update rate. Old digital scopes are not that responsive on the UI or waveform update rate side But that is not an issue when taking single sweeps. Rigol implementation is wrong in sense that it seems to have less than ideal cutoff. Don't know why, as it doesn't make the implementation any more complicated than it already is.

I don't know how they do it in the Agilent 6000-series (or on older HP models), but I have never seen a problem with a sin x/x interpolation on it. Even on slow time base settings where sampling rate drops (see the next link for actual screenshots for severe undersamplings). Or any kind of alias problems, like Tektronix 3000-series seems to have plenty.

Regards,
Janne

[rf-loop]

Actually wrong. Linear interpolation is very much more wrong, if the Nyquist criteria is satisfied.

Actually wrong (as long as we have Sinx/x interpreter what forget true samples. After this we have less truth)

Linear interpolation is nearly wrong. Lines between real sample points are wrong. But real sample points are not wrong and these are displayed in all turn points in "curve". So linear interpolation include all truth what we have but of course only in these true sample points. Good practice is also higlight true points or posibility to do it.

But what have this kind of  "Rigol (+*/-^)sinfun(x)/x" what is in Rigol (and many other quite cheap scopes). We have some curve but after this "interpreter" we have lost all these true points, we do not know where they are and also curve what we see do not really hit any true points (try half day if you can find any screen where even one true point is randomly hit this "curve". Of course with eyes it is difficult to see lower frequencies becouse scope resolution is low). Test with 100MHz and 250Ms/s and you see it... small problem but it tell very clear that this function fails in its basics)  

Only truth what we have is lost and user see only curve without any true sample points. It simple flush to garbage this only truth what we have after A/D. Please look agen this Chris Rehorn pdf and picture. What ever this intrepreter do,   but most important is care that displayed curve fits true sample points - this only true what we have. If we put true sample points to garbage we have nearly nothing. Maybe we can see near right frequency but vertical information accuracy is bad and very extremely bad after we are going more close to Nyquist frequency. 100MHz sine to input and 250Ms/s give result where signal with Sinx function is attenuated more 10dB if compare result with Equaltime samples averaged (same 100MHz point). Averaged linear in same point and samplerate give less than 5dB attenuation. Well done Sinx/x must give better result than averaged linear. This high attenuation of course rescue Rigol and it do not display so much aliasing what is possible becouse analog channel is not good for sinx/x. (it is very bad for do good sinx/x)

With low frequencies it is clear that this fail can not see and it do not make any harm becouse scope resolution comes and hide this problem. It (maybe) also work only (in special case 10ns/div) 5 and 2 ns/div.

Overall it is not at all big problem  if know it, nearly as no problem. But Sin(x)/x name is wrong or minimum, it must give high alarm to user that this RigolSinx/x loose and forget all reality. More bad is that it goes on as default. Default it need be off.. and if someone want shut it on... it need give "red" alarm to user that all truth is loosed after you turn it on. With scope we need inspect something... nice pictures macines are different and for different use. If want sinx/x it must be working one. This sinx/x do not work at all if I give my opinion.

[jahonen]

I made some examples with Matlab to illustrate the effect of reducing the sin x/x bandwidth as it probably is with Rigol. First, the optimal sin x/x-interpolation (cutoff exactly at Nyquist). Here are the indvidual samples made visual, or each sample's contribution to the final output. The green circles on top of the main lobe of sin x/x-function are the sample points of the actual signal. The signal here is a  100 MHz + 110 MHz signal with 250 MHz sampling, so we are quite near the Nyquist limit.



As you'll see, each other samples contribution is zero at each sample point. That is why the sin x/x interpolated curve should match the sample points exactly. There is no "intersymbol interference" between samples.

and here is the reconstructed signal:



Linear interpolation is also shown for comparison. It "cuts short" and is no way more accurate representation of the original signal.

Now, what happens if we reduce the sin x/x signal bandwidth by 80% of Nyquist (100 MHz cutoff). This is what results:



Other sample points are no longer zero at each sample points, so we have some kind of filtering effect. Note that the sample points are still at the top of the sin x/x main lobe peak. Let's see the reconstructed signal with this kind of suboptimal choice of sin x/x bandwidth:



The reconstructed signal has now attenuated and other frequency component has disappeared altogether due to bandwidth loss. This kind of effect is probably what happens with the Rigol.

Regards,
Janne

[armandas]

Impressive stuff, Janne! Would you mind sharing the matlab file?

[rf-loop]

Thank you jahonen.
But this is not what Rigol do. (Fig 4.)

You can easy test it and you see. Put scope to 2ch, real, longmem, 2ns/div. Sinx off. (connect dots line) Persistence infinite.
Input 100MHz sine CH1. Run scope some seconds. (you collect more data to displlay)
Stop scope. Now you see shadow yellow area what imagine all samples with dot connected line and inside this yellow you see this last sampled as highlighted lines with last real data points.
Keep scope stopped.
Push sinx on. Notice how it draw highlighted curve (just with these last shot samples). Push sinx on-off-on... maybe you then have idea what is going on.


We need remember what is this equipment. It is measuring equipment. For measure things. Measurements we do becouse we want get data.

In digital scope only data is sampled points. We know value Y (we know something about this value accuracy and keep in mind this also) We also know value X as long as we can trust also timing. (timing is also with errors and this we need also remember)

After this Rigol (and many others) Sin(x)/x joke we have not eguipment for make measurements (it can shut off...).

We have only equipment to do some nice pictures. I think it is better to use oscilloscope as measuring equipment what give some data out from DUT and then for nice pictures put some nice art picture on the wall if we want also look nice art pictures. Measurement equipment need keep as tightly in truth as we can.

Simple rule: for mesuring equipment: Do not flush truth (or as good "truth" what we have) to garbage.

Any "true" data must not put to garbage. If we forget data and change it with some other what we "like" more we have nothing to do with test and measurements area in house - it is better to put this kind of person to do some useful things in other part of house. Now if equipment do this... we keep it in test area, becouse it looks like test eguipment. Be careful, with this kind of sinx interpreter turned on it is not equipment for measurements. It is machine for draw art pictures. These do not need in test lab. If data is not nice and we forget it or change it with some "data" what we like more we need go to other hobby, just paint art pictures or do something else more or less abstract fun. With sinx on this rigol can put to "art and fun machines" class.

What ever we draw between real datapoints we need keep these datapoints (becousae this is only real data) we can do it as long as we also know truth (this truth what we have). Curve must fit real datapoints. And also more good if real datapoints can highlight on the display.

If it can not do: So simple. Scope manufacturer only need tell that we have not Sinx,  or better, they can lie to customers that we have not becouse sinx is not useful function.  It is useful if it is well done with tight rules. First rule is: Do not change original true datapoints to lie data.

 In some other life area we can do it but not in equipment what is made for get data from real world.

[jahonen]

Impressive stuff, Janne! Would you mind sharing the matlab file?

Of course. I considered to attach that last time but thought that nobody would be interested enough. Feel free to experiment with it (especially with more complex input signal) and post the results if you find anything interesting.

I added black circles to indicate the real data points, otherwise the plot is same as above. I think that with reducing the sin x/x interpolation bandwidth reproduces the observed effect - interpolated curve no longer matches any real data points (marked here with black circles) (sorry, the graph is messy but didn't figure out how to make much better one):



Regards,
Janne

[rf-loop]

Remember, these matlab pics are nothing what Rigol do.

There is big and very important difference.

Rigol do it like this: (dark color points on the lines are true points. For clarify I also make light color points to "sinx" curve.)  From exactly same true samplepoints Rigol make Sinx/x just as in picture.



How to make this with Matlab from these datapoints. If someone find, I am very interest. After then we maybe know something about how Rigol make this fail.

[jahonen]

I think this is pretty close (Rigol emulated with matlab ):



It satisfies the required property that the interpolated signal (blue curve) does not match real data points (black circles). Original data points are destroyed in the result. We can make this correct by increasing the sin x/x function bandwidth to Nyquist:



Both plots are taken from "mid section" of data to suppress the truncation artifacts.

Regards,
Janne

[rf-loop]

Fig 1 is lot of better than Rigol. As you can see in real picture directly from Rigol. Can not at all use any measurements near Nyquist. Oh..maybe it can solve frequency of input sinewave if do long averaging.
There is one question left. Why do this kind of sinxfake?

Fig 2 looks nearly like my one very old Tektronix. (2440) This equipment can use for measurements also with Sinx on and nearly Nyquist.

[colinbeeforth]

Janne,

You have replied with lots of sampling theory, which may be useful for some people considering a DSO purchase.  My comments were intended for those with a less mathematical bent.

I could easily make a long and tedious reply, but it's not worth the effort.  So let me clarify just a few things:

My knowledge of DSOs comes from practical experience.  I spent years answering customer questions about DSO usage and onsite training of new users. That doesn't make me an expert, but I have a broad knowledge of the daily problems that many DSO users encounter.  Unless you had that same experience, you would only know about what you have personally discovered with DSOs.   That may account for the fact that you seem to be interested in the mathematics of undersampled signal reconstruction where my attitude is "undersampled = not fascinating, just useless, because it doesn't get my job done"

You have confirmed what I said.  Linear interpolation makes awful reconstructions of the waveform.  You say that's why it shouldn't be used.  I say that's <why> it's better.  With adequate samples, there is very little difference between sinx/x and linear, especially when displayed on a 320x240 LCD screen, which is what most users have.  If you undersample, linear interpolation looks awful and alerts even a DSO beginner that the resulting waveform record is not real.  Show a beginner undersampled sinx/x, it looks pretty, plausible at a glance, but it is still undersampled and no use as a record of the real waveform.  My attitude is, it's better to look at a slightly less "pretty" waveform, and not be gulled into accepting nonsense as real.

Your comment about needing better bandwidth equipment was glib.  If you see an alias, do you run out and spend $30,000+ for a new oscilloscope that has better bandwidth?  So why tell other people that?  It is not helpful.  Most people cannot afford to buy a DSO that costs more than their car.  Consequently we are always pushing the limits of the test equipment we can afford, so that's why I think being identifying undersampling is so important.

I maintain that alias occur all the time, although much of the time they are not gross and do not prevent the user from getting his job done.  That is why many users say they have never seen an alias - they've seen plenty, but not identified it.  Gross alias can easily occur even with audio signals if you are not alert.  Why do I see undersampling on my DSO regularly, and you don't?  Do you work with a wide variety of signals every day?  I do repair work on all sorts of RF, scientific and industrial equipment, so my daily DSO use is incredibly varied.  I'm constantly looking at all sorts of different signals.  Some days, I wish I had 1Meg of acquisition memory when I deal with serial eeproms. *sighs*  But 50k is far better than many DSOs on the market, and I cannot afford any better.

The information in my previous post is irrelevant to an experienced and thoughtful user.  I set the tone of my comments to my perception that many pf the posters to this group were not highly experienced with DSOs and were discussing buying choices.  I thought sharing my experience might be of use to them.  I respectfully suggest that my comments are irrelevant to you and your experience - it might be best if you ignore them in future.  My best wishes to you in your mathematical ruminations, it is interesting, but largely irrelevant to my daily work.

Cheers, Colin

[rf-loop]

I maintain that alias occur all the time, although much of the time they are not gross and do not prevent the user from getting his job done.  That is why many users say they have never seen an alias - they've seen plenty, but not identified it.  Gross alias can easily occur even with audio signals if you are not alert.  Why do I see undersampling on my DSO regularly, and you don't?  Do you work with a wide variety of signals every day?  I do repair work on all sorts of RF, scientific and industrial equipment, so my daily DSO use is incredibly varied.  I'm constantly looking at all sorts of different signals.  Some days, I wish I had 1Meg of acquisition memory when I deal with serial eeproms. *sighs*  But 50k is far better than many DSOs on the market, and I cannot afford any better.


Cheers, Colin

There is reason why I still have also good analog scope(s). Of course one reason is becouse I do not want spend one house price for High-End digital scope.

With my tens of years experience (and now also with quite cheap digital scopes like Rigol) I can not give out my analog scopes. They are very very useful specially with unknown signal situation in repair work. I have made my choice, I use both, digital and analog. Priority is, in practice, I use analog as nro 1. and digital I use only IF really need. Specially this Rigol is now also becouse sometimes need fast take some picture to computer and my old some digital scope(s) have not this feature. They have some but I do not want play with these heavy HP-IB or GP-IB connections with PC.

My point for start this topic was just this Sinx/x issue what Rigol have - first I think it is only some small cosmetic issue. Very fast and finally now I know that it fails totally. I am not so interest what we can do with matlab and theory, this is not Rigol. This Rigol breaks all rules in theory.. .. we can exactly see also - it do not work at all. It (sinx/x interpreter) is very bad. It is not this kind of Sinx/x what is sometimes maybe useful. This sinx/x what Rigol do can only make things more bad. I repeat, this is equipment for measurements - for data. Not for nice pictures or nice voices..  Sinx/x in this scope put to garbage all real data. Only acceptable Sinx/x in oscilloscope is solution where true datapoints are visble after Sinx/x. Good real Sinx/x for measuring equipments do NOT put any real data to garbage! Entertainment machines may do it... maybe.

This is Rigol made "Sinx/x" what really put all theory and good practices with test equipments to garbage... If I can hope something - Rigol simple take off this feature as long as they can not keep real data. (and same for other manufacturers)  This try be test/measuring equipment, not MP3 player - rules are also different.