The best feature of ESR is that it can be turned off.
Hardly a ringing endorsement...
It has to be the best feature, if only because I have requested it.
And the reason was … see the cons in my previous posting.
I certainly don't want to dismiss the efforts of some very talented people at LeCroy, as I'm sure this 'feature' is of some use and I certainly don't know enough technically to pass judgement on it. It's the marketing angle where I'm sure the sales department was giddy with excitement being able to write "10Gsa/s blah blah". That's an area I know enough to pass judgement on, b/t/w.
I don’t know exactly how LeCroy advertise their gear, but I do know what Siglent’s strategy outside of China is.
Have a look at the international SDS6000A instruments – do you see 10 GSa/s printed on them anywhere?
Have a look at the company webpage. There it says “5 GSa/s (10 GSa/s ESR) per channel” over and over again, so clearly hinting on a genuine samplerate of 5 GSa/s. It is also clearly stated what ESR is – some form of 2x interpolation. So nobody gets fooled.
Have a look at the datasheet. It’s the same as stated above.
Sorry, I cannot see what’s wrong with the marketing. Should the ESR feature be concealed?
As for what it does, according to your explanation, it appears that without ESR the scope only performs the sinx/x interpolation on the screen display (and to adjust the trigger point on the fly) and not the whole capture? So then ESR is simply using sinx/x to generate points in between the actual captured points so that the measurements can be done in the way they normally are--not using sinx/x interpolation--on a greater number of points. OK.
ESR has nothing to do with the general post processing strategies, except that it doubles the number of data points regardless of anything else.
It is only logical that there will neither be linear interpolation “x” or a sin(x)/x reconstruction if there are already enough samples to fill the screen.
So for the display, there will be a 1:1 sample mapping at a certain timebase, e.g. 20 ns/div.
Interpolation or reconstruction is used at faster timebases – where the number of samples gets less then the horizontal screen pixels.
Decimation or agglomeration is used at slower timebases.
You seem to suggest that this is somehow awkward, suboptimal or at least unusual? Just think about it:
In an extreme situation, you use the fastest timebase, which is 100 ps/div. At a sample rate of 5 GSa/s, you only get one sample per two divisions, that is five samples total. That means the interpolation or reconstruction has to provide some 1200 additional values, i.e. multiplying the initial amount of samples by 240. So there are situation, where you need to create that many additional data. Now what does that mean for the memory consumption?
Even ESR, which only doubles the number of samples already requires twice the memory for that. You probably say, for enhancing measurements on long records we do not need to multiply the data by 240 – what do we use then? 1 ps resolution requires a 200 fold expansion of the sample data – our scope then has to have either 200 times the memory (= 200 Gpts) or we leave it as it is and can only advertise it as “2.5 Mpts memory length.”
Even if we make do with just 10 ps, then it is still a factor of 20.
So it’s easy to criticize, but you should also consider the consequences.
However, I can't quite reconcile that with the photo excerpt that I posted from LeCroy's paper. More samples means more Gibbs ears? As I commented there, I fail to see the improvement in that case, and since the screen display is already being processed by sinx/x, what are they actually doing?
Yes, I’m with you here.
As my screenshots demonstrate, there is no difference in the Y-t view – at least not for a rather benign signal with ~200 ps rise time. I do not have a 30-40 ps signal source, maybe I should get one and see what happens then (most likely nothing unexpected).
Anyway, you can be sure that you’ll hardly ever see a whitepaper with questionable screenshots, that create more questions than answers, from Siglent.