EEVblog #1146 - New Low Cost Rigol MSO5000 Oscilloscope

[offmar]

EDIT3:
The problematic calibration is lfcal.hex. Just replacing that file gives perfectly shaped squares again.

mabl, would it be possible for you to upload, or send to me, your working lfcal.hex?

[Martin72]

Hi All,

had anyone tried the "Color Grade" mode - setting is found in the display menu.
Just saw the scope on the fair in Nuremberg - and the Color Grad mode was buggy as well - just displayed a gray colored line if switch on the colr grad-  just works only once :-)
Thanks for testing!

Today I´ve checked it out:

Normal:



Colorgraded:





Looks fine with no problems...

[Martin72]

This might be easy enough to check; is the record length halved when high resolution mode is used?  What about in average mode?

Here we go,

Normal Mode



The so called Hires Mode



No changes in samplerate and record lenght.

Average Mode



Here´s a reaction, the samplerate decrease from 8 to 4GS/s and record lenght from 100 to 25Mpts - Once, independend from the number of averages.

I did the same thing with a Lecroy WS3024,

Normal:



Average:



Samplerate and record length decreases dramatically, from 2 GS/s to 2 MS/s and from 10Mpts to 1kpt

Although, in hi-res mode samplerate and record lenght remains :

Told them(rigol eu).

They thanked for this and will give it forward to the R&D.

[mabl]

EDIT3:
The problematic calibration is lfcal.hex. Just replacing that file gives perfectly shaped squares again.

mabl, would it be possible for you to upload, or send to me, your working lfcal.hex?

See attached.

I will check later to be sure, but I suspect that auto-cal does nothing... I have the overshoots on 3 channels and nothing changes when I use auto-cal. I even did it while I had input signals fed to all channels - the result didn’t change, everything looked as before, and I suppose that in that scenario the ‘scope should have lost calibration.

Cannot confirm. When using the default calibration, the spikes are less pronounced then after the autocalibration. Things do not change afterwards however.

[Commodore8888]

So fun story, the cal data in mabl's "good" file, "fixed" the whacky overshoots on my late Dec MSO5k on .02.03.

Significantly reduced overshoot, as in, essentially gone.

Also amusing is that Autocal didn't seem much fazed by putting insane signals on the inputs...  Try again in a bit.

Overshoots gonski just using the file straight. I frankly didn't expect it to work nearly this well given component/temp/etc variances.
Going to try a cal and see if that hoses it up.

I'll also be dragging said cal file off to work, and trying this on our MSO7k's. Everything I know tells me this probably won't work, but...they ARE using the same ASICs (with admittedly different front ends) so who knows. Can't really get any worse and easy enough to undo.


EDIT:Just ran self cal, and things look even better. It's as if the autocal algo (if it does much at all) tries to base itself off previous data or some bad coeffs were loaded at factory. Without having diassm'd the cal script, hard to say though.

EDIT 2: The plot thickens. My original guess about "not 100% correct" were right. Mabl's lfcal.hex did get rid of the overshoot...but turned it into a less pervasive undershoot! Weak enough it to be easily comped out by a probe, but visible on a 50Ohm terminated line out of a sig gen. Autocal as before appears to have zero effect on this part of hardware calibration.

[nctnico]

Interesting objection, test it out on monday - Scope is on work.
Although I did tests under various mem depth conditions already, but I´ll test it under auto again.
Nevertheless, I want the hi-res option selectable by 0.5 bits steps, as the lecroy and siglent models got.

This basically is the same as input signal filtering but with a variable cut-off frequency. I'd prefer the cut-off frequency to be constant over memory depth and samplerate. Do keep in mind that the signal will need a certain amount of noise for hires to actually work and not show fantasy signals. Hires isn't a replacement for having more bits from the ADC.

There is almost always plenty of noise even after the vertical attenuation stages.  The only exceptions I have seen are in some old DSOs which used flash converters where the combined ADC and vertical signal chain noise was less than 1 LSB; on these if you adjust the position/offset just right, you can get a straight line with no or very few LSB transitions which might make you think the DSO is broken.  Feed these DSOs with a clean triangle wave and average to 16 bits and you get a nice picture of the ADC's differential non-linearity as a stair-step.

Many modern DSOs have very low noise ADCs which produce almost a flat line especially with the 20MHz bandwidth on.

This might be easy enough to check; is the record length halved when high resolution mode is used?  What about in average mode?

That doesn't have to be true. Hi-res can also be done as a post-processing step when the signal is displayed. For example: on the R&S RTM3004 the memory depth doesn't half when hi-res is selected.

[offmar]

So fun story, ...

Indeed, I checked which files are changed after the auto-cal is ran, then did a backup and replaced them with the files from the /rigol/default directory. With these "default" files, I got the overshoot on all four channels (before that, I had overshot of 1,2,4 channels and channel 3 was perfect) even after re-running auto-cal. In that sense, maybe it's not 100% correct, but that auto-cal does generally nothing. I still haven't tried mabl's file, but I suppose the overshoot would be gone.

In any case, manually tweaking these files, doesn't make me certain that my unit is calibrated... Event if I see that 1kHz compensation signal to be perfect, I personally can't be sure what happens at 1MHz, 50MHz, or with different signal shapes, etc., but I suppose this is what you get for 1000$...

[Fungus]

Auto-cal probably does nothing for 'overshoot', it's only interested in voltage levels.

The 'compensation' file might be installed at the factory. It would be interesting to find out how many variants there are of them, or even if every device has a unique file (ie. factory calibration for each 'scope)

[tcottle]

Interesting.  I just upgraded to 00.01.01.04.04 this morning.  My scope always showed a slight overshoot on all 4 channels.  With the update the amount of noise on each channel was dramatically reduced but the overshoot was still there.  I tried to re-compensate the 10x probes but could not improve the waveform.  Ran the self-cal and I now can compensate a 10x perfectly on all 4 channels!  The overshoot is still present when viewed in 1x

[David Hess]

This might be easy enough to check; is the record length halved when high resolution mode is used?  What about in average mode?

Here we go,

Normal Mode

The so called Hires Mode

No changes in sample rate and record length.

That makes sense if the digitizer always produces 8 bit samples after decimation which seems to be common at least for Rigol.

Average Mode

Here´s a reaction, the samplerate decrease from 8 to 4GS/s and record lenght from 100 to 25Mpts - Once, independend from the number of averages.

This may make sense.  If the memory has to be split to allow room for processing, then the bandwidth might be divided also.

I did the same thing with a Lecroy WS3024,

Samplerate and record length decreases dramatically, from 2 GS/s to 2 MS/s and from 10Mpts to 1kpt

Although, in hi-res mode samplerate and record lenght remains :

LeCroy does their own thing and tends to rely on high performance processing rather than real time decimation.  They may be reporting the decimated sample rate instead of the digitizer sample rate.

[David Hess]

Many modern DSOs have very low noise ADCs which produce almost a flat line especially with the 20MHz bandwidth on.

Marketing loves the term "low noise"; it is nice and ambiguous when they do not give an actual number in the specifications which can be confirmed by the user.  None of the modern "low noise" DSOs I have tested had less noise than old analog or digital oscilloscopes although I am sure some exist.  This might be attributed to integrated CMOS amplifiers which can have truly horrible input noise but interleaving and pipelining the ADCs does not help.

If they did have low noise, then averaging a clean triangle wave as I described should return the stair-step pattern of the ADCs differential non-linearity and this is one way to measure it.

This might be easy enough to check; is the record length halved when high resolution mode is used?  What about in average mode?

That doesn't have to be true. Hi-res can also be done as a post-processing step when the signal is displayed. For example: on the R&S RTM3004 the memory depth doesn't half when hi-res is selected.

If high resolution processing is done during decimation, then the processing record takes twice as much memory if 16 bit values are returned.  The record length may or may not be halved depending on if it is based on 8 bit or 16 bit samples.

This is a marketing issue.  Which is the better of three DSOs with the same *amount* (cost) of sample memory when one always has the full (8 bit) record length, one has half the record length when high resolution or averaging mode is used, and one always has half the record length because it always processes 16 bit samples?

If high resolution processing is done after decimation in the same way, then the resulting record will be a fraction of its original length depending on the decimation ratio.  Maybe your R&S RTM3004 is applying a complete FIR filter and not decimating?  That is usually not feasible during decimation which is why boxcar averaging is used instead.  Boxcar averaging is of course a (poor) FIR filter but a very simple to implement one which only requires adds and optional shifts.

[nctnico]

All hi-res modes I've seen have a cut-off frequency depending on the samplerate which implies hi-res is always done after decimation. I'm quite sure the memory length getting halved on some oscilloscopes has to do with the hardware architecture and not what is the best point to do the hi-res filtering.

A lot of the low end scopes based on Analog devices (formerly Hittite) all in one front-ends have really low noise levels.

[David Hess]

All hi-res modes I've seen have a cut-off frequency depending on the samplerate which implies hi-res is always done after decimation.

What?

For boxcar averaging, which produces a sin(x)/x frequency response, the cutoff frequency depends *only* on integration time which is the product of the sample rate and number of samples which depends on the decimation ratio.

Newer DSOs might be doing something else like an FIR after decimation but all of the older DSOs did boxcar averaging as part of decimation which is why the record length did not change in high resolution mode.  Or the record length might be halved to handle 16 bit samples as I described earlier.

[Martin72]

That makes sense if the digitizer always produces 8 bit samples after decimation which seems to be common at least for Rigol.

When you see in hi-res nothing "cleaner" as in normal, what make the hi-res mode any sense at all...
Even the low cost siglent (the pictures I posted) could do this.
If rigol couldn´t handle this for what reasons ever, they should leave it.
And not disclaim a hi-res mode which doesen´t have any remarkable effect.

[orion242]

Just wondering if anyone else has had issues capturing the HDMI output of the MSO5000?

My Magwell capture device absolutely would not recognize the output from the scope.  No problem hooking it up to a HDMI TV or monitor, just a no go when trying to capture it.

Guessing they have HDCP enabled for whatever reason??  Had to get an HDMI splitter that doesn't pass that flag thru to finally get something I could capture.

[nctnico]

That makes sense if the digitizer always produces 8 bit samples after decimation which seems to be common at least for Rigol.

When you see in hi-res nothing "cleaner" as in normal, what make the hi-res mode any sense at all...
Even the low cost siglent (the pictures I posted) could do this.
If rigol couldn´t handle this for what reasons ever, they should leave it.
And not disclaim a hi-res mode which doesen´t have any remarkable effect.

Well, Rigol wouldn't be the first manufacturer from China to leave features out which are in the datasheet. Hi-res probably hasn't been implemented yet.

[David Hess]

That makes sense if the digitizer always produces 8 bit samples after decimation which seems to be common at least for Rigol.

When you see in hi-res nothing "cleaner" as in normal, what make the hi-res mode any sense at all...

It does lower the noise on single shot acquisitions.  If resolution is defined from signal to noise ratio, then it does improve resolution.

I would make the same complaint about averaging 8 bit data to produce 8 bit data but again, it does reduce noise.

Even the low cost siglent (the pictures I posted) could do this.
If rigol couldn´t handle this for what reasons ever, they should leave it.
And not disclaim a hi-res mode which doesen´t have any remarkable effect.

Marketing is greater than engineering.  If you are not in sales, then you are overhead.

My preference would be for Rigol to use 16 bit processing of samples and a separate display record but it comes at a hardware and performance cost.  I would prefer this even at the expense of performance.

[Bax]

Have you seen this HDMI interface

https://rigol.desk.com/customer/en/portal/articles/2966908-remote-interface-with-performance-instruments

[rsjsouza]

That makes sense if the digitizer always produces 8 bit samples after decimation which seems to be common at least for Rigol.

When you see in hi-res nothing "cleaner" as in normal, what make the hi-res mode any sense at all...
Even the low cost siglent (the pictures I posted) could do this.
If rigol couldn´t handle this for what reasons ever, they should leave it.
And not disclaim a hi-res mode which doesen´t have any remarkable effect.

Well, Rigol wouldn't be the first manufacturer from China to leave features out which are in the datasheet. Hi-res probably hasn't been implemented yet.

Perhaps not on the DS5000, but on the DS4000 it is there. Proof that it may be simply a matter of time for Rigol to add this.

Normal mode:


Hi-res mode:


(as you can tell, sample rate and sampling memory were not reduced)

[seronday]

It appears that the low pass filter part of the Hi-Res mode has been implemented to some extent.
However it is necessary to manually select the sample memory size to obtain the result that you want.

The attached table shows the 6dB down roll off frequencies for a few combinations of mem size and horizontal settings that I have quickly tested.

As rsjsouza mentioned, Rigol have successfully implemented Hi-Res mode in the DS4000 series. ( and also the DS2000 series).
So possibly they have now forgotten how to do it, or they have some new inexperienced software developers.

Regards.

[Fungus]

However it is necessary to manually select the sample memory size to obtain the result that you want.

Does it work in "auto" mode?

As rsjsouza mentioned, Rigol have successfully implemented Hi-Res mode in the DS4000 series. ( and also the DS2000 series).
So possibly they have now forgotten how to do it, or they have some new inexperienced software developers.

Or maybe this one has so much memory and sample rate that it's quite difficult to "downsample" it to single screen pixels, that only a narrow range of memory sizes can be done with the available processing power.

[David Hess]

Perhaps not on the DS5000, but on the DS4000 it is there. Proof that it may be simply a matter of time for Rigol to add this.

As rsjsouza mentioned, Rigol have successfully implemented Hi-Res mode in the DS4000 series. ( and also the DS2000 series).
So possibly they have now forgotten how to do it, or they have some new inexperienced software developers.

If the high resolution mode is implemented during decimation like older DSOs where the full record length is available at the highest sampling rate, then it requires hardware support between the ADC and sample memory.  It is not as simple as reprogramming the processor; it requires a change to or support from the FPGA if used.

The same applies to a feature like peak detection which also occurs during decimation.  If the processor does it, then it becomes envelope detection despite what Rigol continues to say in their misleading documentation.  Does anybody not think Rigol deliberately confused the two for a marketing advantage?  The same could be happening here by confusing high resolution mode with a FIR low pass filter implemented by the processor.

So far the tests indicate that high resolution mode if it exists is broken.

[nctnico]

You mean the MSO5000 doesn't have real peak detection? Perhaps an MSO5000 owner can do a test with narrow pulses. The trick is to have a pulse which is narrower than the sample period (both in normal and roll-mode).

[Martin72]

Here my wishlist for further firmware upgrades ( will be send to rigol too):

- A useable hi-res mode, like keysight, lecroy and even siglent have it

- All math functions could be displayed "stand alone" and/or:

- Split screen modes, for every channel, for every math function - This would be a real benefit - None provide it in this priceclass an wide above. ( so it will be a wish I guess)

- Free choosable colours for all traces - Math got one colour only, unfortunately "dark violet", what makes no sense in aspect to the dark screen.

- A free adjustable measure gate, "free" moveable on the screen ( you define a gate and could this one scroll to the whole screen- it measures only whats in the gate, known from older lecroy waverunner scopes)

- Bode plot function, makes really sense when you already got a build in wavegenerator (will come)

- Brighter Display (will come)

[el_man]

Here my wishlist for further firmware upgrades ( will be send to rigol too):

- A useable hi-res mode, like keysight, lecroy and even siglent have it

- All math functions could be displayed "stand alone" and/or:

- Split screen modes, for every channel, for every math function - This would be a real benefit - None provide it in this priceclass an wide above. ( so it will be a wish I guess)

- Free choosable colours for all traces - Math got one colour only, unfortunately "dark violet", what makes no sense in aspect to the dark screen.

- A free adjustable measure gate, "free" moveable on the screen ( you define a gate and could this one scroll to the whole screen- it measures only whats in the gate, known from older lecroy waverunner scopes)

- Bode plot function, makes really sense when you already got a build in wavegenerator (will come)

- Brighter Display (will come)

Nice post Martin72

and if it is possible some more from me (arranged by priority)

1. Adjustable transparency to the floating windows - in some modes, like power analyzes, they almost cover the entire screen

2. In FFT mode the grid scale instead of time can show the frequency scale related to FFT diagram

3. A more reliable XY-mode with ability to show the waveforms along with diagram (as at DS1054Z) and option to choose which channels are involved, now it is fixed to ch1 and ch2