Importance of Good Terminators for RF / Pulse Applications

[David Hess]

It could be doing the sin(x)/s reconstruction poorly with this few points.  If possible, perhaps try turning off interpolation or switch to dots mode to see what you're actually getting.  You could also download the raw data and examine it that way.

If I run a similar test on my 2440, then equivalent time sampling returns a 1.30 nanosecond rise time which almost exactly matches the specified 300 MHz bandwidth of the oscilloscope given the 600 picosecond rise time of my calibration source.  Without ETS and just using sin(x)/x reconstruction, the rise time drops to 2.5 nanoseconds with a variation between about 2.1 and 2.9 from aliasing and intermodulation if averaging is not used.  That matches up fairly closely with the typical DSO specification of sampling frequency/4 for real time bandwidth when sin(x)/x reconstruction is used.

The Rigol has twice the real time sample rate so with sin(x)/x reconstruction and averaging, I would expect a rise time of about 1.25 nanoseconds which is not far from the measured 1.7 nanoseconds but how can 1.7 nanoseconds make any sense with a 70 or even 100 MHz analog bandwidth?  If I limit the vertical bandwidth of my 2440 to 100 MHz and use sin(x)/x reconstruction without ETS, then the rise time is almost exactly 3.5 nanoseconds with half the sample rate of the Rigol.

I have read speculation before that Rigol's sin(x)/x reconstruction has a problem.  Apparently at high frequencies, the sample points do not match up with the reconstructed waveform.  On my 2440, I can have it display the real sample points within the sin(x)/x reconstruction and they always line up exactly despite a lower sample rate and higher bandwidth.

The discussion here gets interesting past the first page:

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

Or maybe it's just doing a bad job doing the rise/fall time calculation.  If it has measurement cursors, try to see where it's anchoring its measurements.  Or do the measurement manually if you can zoom the horizontal any further.  You've chopped off the top of the 200mV/div waveform so I can't really tell if 3.5ns is right.

The automatic measurement may be getting confused when the histogram cannot find the top of the waveform.  A cursor measurement may be needed but I have my doubts because I think the pulse should look much cleaner.

Are you doing this single shot?  Do an average, or look at the rise/fall statistics (std deviation) to see if it's all over the place.  It may also be dependent on where trigger point is occurring and where the samples land.

It is not completely clear how these Rigol's generate their trigger timing without dedicated hardware to support equivalent time sampling.  I assume their digital trigger operates after reconstruction.

[David Hess]

I re-did the Jim Williams test. Firstly, I noticed today that the SMA-BNC with integral 50 ohm resistor wasn't 50 ohms. I don't know if it was physical or electrical stress (I was pumping quite a few volts into that 0603 49.9 ohm resistor albeit for only a few ns) but it was open anyway. I think we should forget that waveform as operator error on my part for now. Anyway, I fixed he internal 50 ohm termination and have re-run the tests, this time with an inline SMA 20dB pad at all times and with a reduced coax length on the 2pF cap too of about 50cm.

Doh!  That explains the earlier waveform then.  It does look like a TDR result.

Rigol MSO1074Z-S, 500mV/div, 1X probe, 5ns/div

Rigol MSO1074Z-S, 200mV/div, 1X probe, 5ns/div. I was careful to ensure that the signal wasn't (apparently!) saturating. Note the very significant increase in rise time. You also get a relay click at the attenuator change form 500mV/div.

I am concerned about the shape which does not match what I would expect simply do to lower bandwidth.

[David Hess]

Indeed, my 475 for instance notes the rise/fall time is notably better for e.g. 2-3 div height than 6-8 div full screen.  That's for an entire analog signal path, of course, but similar reasons could very well apply for the digital scope's preamp.

Where is this noted?  I looked through the 475 documentation and did not find it.  I have seen this sort of specification before but it is insignificant on all of the oscilloscopes I have used.  Almost all analog oscilloscopes would be using 5 divisions anyway for a rise/fall time measurement.

Hmm, looking through my documents, I don't see it either...

Maybe I conflated that with something I read elsewhere, perhaps a lesser quality scope.

I know some very old (or cheap?) oscilloscopes suffered from this.  I suspect the difference is that they used a vertical amplifier design which did indeed have low full power bandwidth do to slew rate limitations.  I think I have run across it in Tektronix oscilloscopes during calibration where the effect is suppose to be less than 1 minor division at the extremes of the CRT graticule and it was included as part of the linearity error.

[MarkL]

The Rigol has twice the real time sample rate so with sin(x)/x reconstruction and averaging, I would expect a rise time of about 1.25 nanoseconds which is not far from the measured 1.7 nanoseconds but how can 1.7 nanoseconds make any sense with a 70 or even 100 MHz analog bandwidth?  If I limit the vertical bandwidth of my 2440 to 100 MHz and use sin(x)/x reconstruction without ETS, then the rise time is almost exactly 3.5 nanoseconds with half the sample rate of the Rigol.

I have read speculation before that Rigol's sin(x)/x reconstruction has a problem.  Apparently at high frequencies, the sample points do not match up with the reconstructed waveform.  On my 2440, I can have it display the real sample points within the sin(x)/x reconstruction and they always line up exactly despite a lower sample rate and higher bandwidth.

The discussion here gets interesting past the first page:

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

That's an interesting read; thanks for the pointer.  Not sure there were any solid conclusions in that thread, though.

How the Rigol could come up with 1.7ns is exactly what I was wondering as well, hence the barrage of questions to Howardlong.  To even start to figure it out, it has to be known where the real sample points sit, and if it's consistent capture to capture.

It could be an artifact of sloppy ADC interleave clocking, but that's only a guess at this point.  It's possible the designers did not concern themselves with this level of waveform accuracy that's already well beyond the scope's BW.

[vk6zgo]

I re-did the Jim Williams test. Firstly, I noticed today that the SMA-BNC with integral 50 ohm resistor wasn't 50 ohms. I don't know if it was physical or electrical stress (I was pumping quite a few volts into that 0603 49.9 ohm resistor albeit for only a few ns) but it was open anyway. I think we should forget that waveform as operator error on my part for now. Anyway, I fixed he internal 50 ohm termination and have re-run the tests, this time with an inline SMA 20dB pad at all times and with a reduced coax length on the 2pF cap too of about 50cm.

Rigol MSO1074Z-S, 500mV/div, 1X probe, 5ns/div


Rigol MSO1074Z-S, 200mV/div, 1X probe, 5ns/div. I was careful to ensure that the signal wasn't (apparently!) saturating. Note the very significant increase in rise time. You also get a relay click at the attenuator change form 500mV/div.


Agilent 54831D, 500mV/div, 1x probe, 10ns/div


Agilent 54831D, 500mV/div, 1x probe, 1ns/div


Agilent 54831D, 500mV/div, 1x probe, 1ns/div, direct connection to scope, internal 50 ohm load


Something else I've noticed on the Rigol is that even on a single shot stopped waveform, the measured Vpp value also changes as you change the vertical scale. I tried to reproduce the anomaly regarding the 200mV to 500mV rise time measurement above with an RF signal generator terminated to 50 ohm at the scope, and couldn't, so I'm not sure what's happening with the JW as a pulse source on the Rigol in that scenario.

Is it just the readout of Vpp,or the displayed signal as well?
If you count the graticule divisions "Greybeard style" you can determine this.

[David Hess]

That's an interesting read; thanks for the pointer.  Not sure there were any solid conclusions in that thread, though.

I concluded some things based on that discussion thread and another but nothing about the sin(x)/x reconstruction.  Some of his test results in that discussion thread may be explained by aliasing during reconstruction but I have yet to see a real time DSO where that was not a limitation.

How the Rigol could come up with 1.7ns is exactly what I was wondering as well, hence the barrage of questions to Howardlong.  To even start to figure it out, it has to be known where the real sample points sit, and if it's consistent capture to capture.

It could be an artifact of sloppy ADC interleave clocking, but that's only a guess at this point.  It's possible the designers did not concern themselves with this level of waveform accuracy that's already well beyond the scope's BW.

It is not beyond the oscilloscope's bandwidth.  With averaging it should be able to make measurements up to its bandwidth limit.  Intermodulation distortion from the ADC *can* cause artifacts which make the rise time look faster than it should be but the effect is relatively small if annoying and averaging should take it out.

Looking carefully at the two photos again and reading Howardlong's description, they are of the same saved data but with the vertical scale changed.  To me that implies that the measurements are made on the display record and not the waveform record because the former changes when you alter the scale but the later does not.  Maybe Rigol does not even maintain a separate waveform record.  That explains why the various volt measurements change a little bit.  The rise time measurement is just broken but it is not clear how because the top and base measurements are not out of line.

Wasn't there an issue with protocol decoding where only what is on the display can be decoded?  That might fit with this.

So it is not really displaying or making a 1.7 nanosecond rise time signal.  It is just measuring it wrong somehow.  It seems like it would be significant that the false rise time measurement is exactly 1/2 of the real measurement but then why do the fall time measurements vary by a different factor?

Maybe the measurement algorithm Rigol uses is just poor.  My 2440 makes exactly the same measurement without problems using half as many sample points, no ETS, with or without averaging, and worse digitizer performance.

[Howardlong]

A couple of clarifications...

Looking carefully at the two photos again and reading Howardlong's description, they are of the same saved data but with the vertical scale changed.

If you're referring to the two following two screenshots, then they were two different single shot acquisitions, each taken at the displayed vertical resolution. There is a relay click between the 200mV and 500mV setting (with 1X probe), I was suggesting that a different signal path at the front end has different filtering characteristics. I tried other vertical resolutions that didn't click any relays and the rise time wasn't significantly affected.

It is true, however, that on captured acquisitions, changing the vertical resolution after the capture also shows aberrations, although the difference is nowhere near as much.

Wasn't there an issue with protocol decoding where only what is on the display can be decoded?  That might fit with this.

I think that is probably a red herring: the problem with serial decoding is that (a) the scope will only decode what's on the screen (not in memory) and (b) as you slow timebase in real time, or equally zoom out on a capture, the underlying sample rate used to decode also decreases to such an extent that it will no longer properly decode, and although the decoder's sample rate is shown, it doesn't appear to be changeable by the user.

There appears to be a "feature" on the firmware I'm using: I cannot turn off sin(x)/x unless I have at least three channels running (weird!).

FWIW, with sin(x)/x on, with the 3dB points with a 1Vpp signal when using an RF signal generator, terminated at the scope:
1Ch 109MHz (1GSa/s)
2Ch 105MHz (500MSa/s)
3Ch 106MHz (250MSa/s, using averaging [128] due to aliasing artifacts)
4Ch 106MHz (250MSa/s, using averaging [128] due to aliasing artifacts)

With sin(x)/x on:

3Ch 64MHz (250MSa/s)
4Ch 64MHz (250MSa/s)

[David Hess]

A couple of clarifications...

Looking carefully at the two photos again and reading Howardlong's description, they are of the same saved data but with the vertical scale changed.

If you're referring to the two following two screenshots, then they were two different single shot acquisitions, each taken at the displayed vertical resolution. There is a relay click between the 200mV and 500mV setting (with 1X probe), I was suggesting that a different signal path at the front end has different filtering characteristics. I tried other vertical resolutions that didn't click any relays and the rise time wasn't significantly affected.

The images did not come through but I get the idea.  That explains the voltage measurement changes but not the rise and fall time measurement changes.  Changing the input attenuation might slow down the input but there is no way it should speed it up that much.  If it did, then the 200mV setting should be the fast one and the 500mV setting the slow one and your results show the opposite.

Dave's reverse engineering shows that the front end includes a switchable x50 high impedance attenuator.  The only odd thing about it is that it only has an adjustment for compensation and none for input capacitance but maybe it is there and got missed or the design is so consistent that it is not required.  He has a link to the schematics he made here:

https://www.eevblog.com/forum/blog/eevblog-675-how-to-reverse-engineer-a-rigol-ds1054z/

Looking at I now, I also do not see any adjustments for medium frequency compensation on the DC path.  Maybe Rigol handled some of the front end frequency response calibration through DSP.

The odd waveform could be caused by the very fast high amplitude edge coupling through to the high impedance buffer causing it to overload.  If that is the case, then the shape of the waveform will change between 200mV/div and 500mV/div where the input attenuation changes.  The shape will also change if the signal level changes via external attenuation or DC level shift which would be a better test to avoid differences caused by switching the x50 input attenuator in and out.  Adjusting the vertical position control might change it as well.

Since only one input attenuator stage is used, the input circuits have to operate over a very wide input signal range which makes effects of overload at 200mV/div even more likely.  Oscilloscope input buffers usually operate over an input range considerably smaller than the 1.6 volts the Rigol design has to handle.  I checked a couple of older oscilloscope designs and found input ranges from 40 to 400 millivolts.

It is true, however, that on captured acquisitions, changing the vertical resolution after the capture also shows aberrations, although the difference is nowhere near as much.

I do not know what to make of this if the changes are significant.

Wasn't there an issue with protocol decoding where only what is on the display can be decoded?  That might fit with this.

I think that is probably a red herring: the problem with serial decoding is that (a) the scope will only decode what's on the screen (not in memory) and (b) as you slow timebase in real time, or equally zoom out on a capture, the underlying sample rate used to decode also decreases to such an extent that it will no longer properly decode, and although the decoder's sample rate is shown, it doesn't appear to be changeable by the user.

Given the above I agree.  I was thinking they could be related if measurements are only made on the display record.

There appears to be a "feature" on the firmware I'm using: I cannot turn off sin(x)/x unless I have at least three channels running (weird!).

This behavior was discussed in another EEVBlog thread.  I do not think we reached any consensus about why sin(x)/x is forced on at higher sample rates.

FWIW, with sin(x)/x on, with the 3dB points with a 1Vpp signal when using an RF signal generator, terminated at the scope:
1Ch 109MHz (1GSa/s)
2Ch 105MHz (500MSa/s)
3Ch 106MHz (250MSa/s, using averaging [128] due to aliasing artifacts)
4Ch 106MHz (250MSa/s, using averaging [128] due to aliasing artifacts)

With sin(x)/x on:

3Ch 64MHz (250MSa/s)
4Ch 64MHz (250MSa/s)

I actually meant bandwidth as measured by rise time.  Your last two results however are consistent with sin(x)/x reconstruction limiting bandwidth to the sample rate divided by 4 which is common in other DSOs when real time sampling is used.  250MSa/s divided by 4 equals 62.5 MHz.

[miguelvp]

FWIW a couple of days ago I did some comparisons of a few probe options against an Agilent 54831D 600MHz/4GSa/s scope and an unmodified Rigol MSO1074Z-S 70MHz/1GSa/s scope. Apart from the homebrew 21:1 probe, I used stock probes supplied with each instrument, namely the Agilent 1165A 600MHz passive probe and the Rigol RP2200 150MHz passive probe respectively. Both scopes were running a single channel only at their respective full sample rates.

Cheers, Howard

Measuring 125 MHz, why are you surprised by the results?

4 times the sampling rate, 8 and a half higher bandwidth specs and 4.8 times probe bandwidth vs less than half the probe bandwidth.

Am I missing something obvious that the Rigol claims?

[David Hess]

Measuring 125 MHz, why are you surprised by the results?

4 times the sampling rate, 8 and a half higher bandwidth specs and 4.8 times probe bandwidth vs less than half the probe bandwidth.

Am I missing something obvious that the Rigol claims?

The Rigol results are not consistent with an oscilloscope which only has a lower bandwidth and/or sample rate.  The pulse shape is distorted beyond what can be explained by those two things.  Nothing explains the Rigol returning a 1.7 nanosecond rise time measurement.

Measuring a similar pulse edge, my generator is about half as fast but much cleaner, with half of the sample rate the Rigol is using and the same bandwidth, my own DSO has no problem.  With a much higher bandwidth it still has no problem.

It is possible that the pulse is getting distorted by the test setup however.  As much as possible need to be kept the same when making the measurement with two different DSOs.  The same external 50 ohm feedthrough termination and cable need to be used.  That might explain everything except the 1.7 nanosecond measurement.