New Rigol DS1054Z oscilloscope

[David Hess]

Using averaging or high resolution acquisition mode is note going to return a proper or comparable measurement of noise.  Either will attenuate high frequency noise (and are useful for this reason); my measurements were over the full bandwidth of roughly 100 MHz.  (1) The fact that you measured 85uV RMS and 70uV RMS with high resolution and averaging indicates to me that something is very wrong; the noise should have been much much lower because of limited bandwidth.

I averaged to see if it is actually random noise. And it is not. 1024 traces averaged were all the noise is uncorrelated should bring the trace back to the vertical quantization resolution of 40uV (about 20uV rms) (1mV/40). I can clearly see a 125MHz signal. That's what I also found in the FFT result from the raw samples.

It is interesting that it was able to trigger on it as all; that 125 MHz signal must be pretty large.  Averaging is especially useful for extracting a signal below the noise level if you have an external trigger signal available.  It makes sense that a spurious signal would be 125 MHz since that is or related to the external ADC clock frequency.

If I use the raw sample data I have a bandwidth up to sample rate/2. That's 5 times oversampling for a scope bandwidth of 100MHz. I think I have shown clearly that the rigol has a lot of noise and a spur. I don't consider the scope to be defective though, it's just not the high quality that other scopes might offer.

The sample rate and aliasing have nothing to do with input bandwidth.

I wonder if the DS2000A series which Rigol advertises as "low noise" whatever that means since they does not specify it is any better.

I have a pocket sized oscilloscope tester for verifying bandwidth, transient response, and jitter but maybe I need to make something for noise testing in the field like in the video I linked.

The measurement should *not* change significantly at different sample rates or record lengths (although it may look visually different); if it does, then something is wrong and this is easy to demonstrate.

I checked, it does not change with memory depth settings.

It does go up (a lot) when I change the time base. The same test done at 50us/div displays a much wider noise band and it reports 500uV RMS noise. That should not happen. Hi RES solves that and lowers the noise back to 70uV (also single shot). And that's not averaging. With averaging the noise drops to 0-40uV (and the display is a nice noiseless line). Sample rate is 1Gs, mem depth 1.2M

I wonder what is going on then.  Noise measurements in averaging and high resolution mode are not very useful and changing the time/div should not affect RMS noise measurement.

[TheoB]

Perhaps I've had too much wine, but... I cannot find these values in the pictures you attached.
You say with NORMAL acquisition at 50ns/div you get 500 uV RMS noise, but the first attached picture shows 164 uV RMS measure.
You say in averaging the noise drops to 0-40 uV and yet the picture with AVERAGE acquisition mode, 1024 averages at 1GS/s and 1.2 point of memory shows 72.3 uV of rms noise.

What am I not understanding?

I only attached the 100ns/div pictures. This time the same but at 50us. It should be the same. but it is not. Now it actually depends on the chosen memory depth 

[Sredni]

Aha! You wrote 50 us, I read 50 ns   . And in fact the pictures you attached before were for 50 nanoseconds timebase. I see now the 50 microseconds one.
So, my wine not only works sideways, but also upside down. 

BTW, couldn't all this inconsistency be a side effect of the fact the DS1000Z compute quantities based on what is displayed on screen? This might all boil down to the algorithm that chooses which points to show on the screen. At the fastest timebases, all points are used. When you slow it down, it has to make choices, and this might be the source of all discrepancies.

Should I go back to my bottle?

[saturation]

Just FYI.

Measuring DSO noise is fairly straightforward, and is much as Hess states.  The protocol is 50 ohm termination with the scope set at maximum bandwidth and memory.

Details. 

http://cp.literature.agilent.com/litweb/pdf/5989-3020EN.pdf

Above includes how-to as well as sample noise floors for high end DSOs.

It will vary by channel input amp setting.  FWIW the old Rigol 1054e has a floor ~500uV rms at lowest setting.  GWInstek 1054B ~ 90uV rms. 

As white noise the trace will flatten out if averaging is applied to the waveform, but the rms value remains.

The purpose of GND setting on DSO is not just to center the graticule or locate the trace, but mostly importantly it removes the effect of the DSO on the DUT and shows a physical constant independent of electronics, that the input is at ground potential of the DSO which should be ~ 0.000 000V as far as the DSO is concerned and is a major point of reference; noise should also at zero too.

"Faking" a GND by setting input amps to null its inputs is very problematic as 0 V potential cannot be assured, particularly if the DSO has unknown faults or develops one later.

[TheoB]

It is interesting that it was able to trigger on it as all; that 125 MHz signal must be pretty large.  Averaging is especially useful for extracting a signal below the noise level if you have an external trigger signal available.  It makes sense that a spurious signal would be 125 MHz since that is or related to the external ADC clock frequency.

No it was not triggered. The wave shown is correlated to the internal timing of the scope. So it looks like it is triggered, but it's just free running. The 128MHz displayed is present in the sampled data and about equally sized as the noise.
Today I discovered that the 1mV scale is just the 2mV scale multiplied by two. This means the ADC resolution is the same in 2mV and in 1mV. All other vertical settings result in about 10/13 division of which you see 8 on your screen. For FFT this is important as the signal may not clip:

[MrWolf]

Today I discovered that the 1mV scale is just the 2mV scale multiplied by two. This means the ADC resolution is the same in 2mV and in 1mV.

Found this when investigating counter input sensitivity:
https://www.eevblog.com/forum/testgear/rigol-ds1000z-series-(ds1054z-ds1074z-ds1104z-and-s-models)-bugswish-list/msg1080859/#msg1080859
Wish they would fake 2ns timebase also.

[Howardlong]

Is this not ADC interleaving together with small non-linearity and offset differences between the ADCs? I see a similar thing on my MSO1074Z-S.

Typically these can be cal'd out, but this is dependent on the cal routine and the application of any of those corrections working.

What is it you're intending to use the scope for that will cause this to be a problem for you? I'm not saying it won't be, I'm just trying to figure out the case where this internally generated noise would be a problem for you, bearing in mind that once you've got your probe in there there'll be plenty of other places for noise to come in.

By the way, I noticed that the 500uV seems to be working on my MSO1074Z now. It used to have horrendous offsets, making it unusable on some channels. It's still a digital amplification rather than in the analogue domain though. My firmware is 00.04.04.SP1, not sure if that's the latest, I installed it a couple of months ago and did do a re-cal afterwards.

[David Hess]

BTW, couldn't all this inconsistency be a side effect of the fact the DS1000Z compute quantities based on what is displayed on screen? This might all boil down to the algorithm that chooses which points to show on the screen. At the fastest timebases, all points are used. When you slow it down, it has to make choices, and this might be the source of all discrepancies.

I suspect that this is exactly the problem.  I was already suspicious that this was the case because of other reported inconsistencies with automatic measurements and decoding but hoped that a single shot RMS measurement would work correctly.

The measurement should still work if the acquisition record is transferred to another system where the RMS or standard deviation is computed.

Actually this make two problems when the 125 MHz spurious signal is included.

[TheoB]

I'm not really interested in the noise. I responded on someone asking if the noise of his scope was an issue. Gained quite some insight from all the measurements I made. About the ADC interleaving. I thought it's a 1GHz flash type ADC converter but indeed it could actually be interleaved. I'll recalibrate the scope to see if it makes a difference.

[TheoB]

This is the 1kHz square wave calibration signal, with deep FFT. The bin width is 10Hz and the span 125MHz as I used 24Msamples @ 250Ms/sec:

And zoomed in a bit:

I would say the duty cycle is not exactly 50% as the second harmonic is visible at -60dB.   

[David Hess]

It is interesting that it was able to trigger on it as all; that 125 MHz signal must be pretty large.  Averaging is especially useful for extracting a signal below the noise level if you have an external trigger signal available.  It makes sense that a spurious signal would be 125 MHz since that is or related to the external ADC clock frequency.

No it was not triggered. The wave shown is correlated to the internal timing of the scope. So it looks like it is triggered, but it's just free running. The 128MHz displayed is present in the sampled data and about equally sized as the noise.

If the acquisition is done using averaging, then how did the trigger point get synchronized with the 128MHz signal (125MHz?  128MHz?) except by triggering on it?

If it is generated during decimation or processing, that is even worse.

Does trigger holdoff have any effect on it?  I am guessing not given how triggering occurs after digitizing.

Today I discovered that the 1mV scale is just the 2mV scale multiplied by two. This means the ADC resolution is the same in 2mV and in 1mV. All other vertical settings result in about 10/13 division of which you see 8 on your screen.

This is common on cheap USB oscilloscopes.  I wish they would document it but obviously it would make them look worse so it is better to hide it.

Is this not ADC interleaving together with small non-linearity and offset differences between the ADCs? I see a similar thing on my MSO1074Z-S.

Typically these can be cal'd out, but this is dependent on the cal routine and the application of any of those corrections working.

This can happen and is a concern when an interleaved digitizer is used like on the various Rigol DSOs but the resulting sampling spurs should be lower amplitude than the noise.  My Tektronix 2440 should greatly suffer from this do to its ungainly design but is actually pretty good.

What is it you're intending to use the scope for that will cause this to be a problem for you? I'm not saying it won't be, I'm just trying to figure out the case where this internally generated noise would be a problem for you, bearing in mind that once you've got your probe in there there'll be plenty of other places for noise to come in.

Making RMS noise measurements is one of the few reasons I would upgrade from an analog oscilloscope to a DSO.  The procedure is time consuming on an analog DSO.  In this case, the Rigol fails on two counts being both noisy and not making RMS measurements correctly.

If that rogue signal is being generated after the digitizer, then that makes a third failure since it cannot be averaged out.  I regularly use averaging mode to measure power supply ripple which is below the noise floor of the power supply and oscilloscope.  I can do this on an analog oscilloscope without averaging but only at the expense of bandwidth.

[TheoB]

If the acquisition is done using averaging, then how did the trigger point get synchronized with the 128MHz signal (125MHz?  128MHz?) except by triggering on it?

This is a correlated signal, so regardless of the trigger moment is always "sees" the same signal.
With postprocessing the 128MHz can be removed from the spectrum (just removing that one bin). For noise measurement this should not matter a lot. But the displayed RMS value is not correct of course. A self calibration routine should be able to do that (it can measure the complete FFT bins and compensate the error in each bin to make it zero).
Scope is warmed up, I'll start the calibration (half an hour or so...)

[Fungus]

Making RMS noise measurements is one of the few reasons I would upgrade from an analog oscilloscope to a DSO.  The procedure is time consuming on an analog DSO.  In this case, the Rigol fails on two counts being both noisy and not making RMS measurements correctly.

There's some sort of bug when measuring RMS on multiple channels simultaneously but RMS on a single channel works perfectly.

nb. If the signal is periodic then "RMS" is the wrong measurement. You should use PerRMS for that, and it works just fine on mutliepl channels, etc.

[David Hess]

I'm not really interested in the noise. I responded on someone asking if the noise of his scope was an issue. Gained quite some insight from all the measurements I made. About the ADC interleaving. I thought it's a 1GHz flash type ADC converter but indeed it could actually be interleaved. I'll recalibrate the scope to see if it makes a difference.

Subranging or pipelined ADCs replaced flash ADCs a long time ago.  The Rigol DS1000Z series uses the Hittite HMCAD1511 which has four separate 250 MS/s subranging ADCs which are interleaved to reach 1 GS/s or two channels of 500 MS/s.  Each subranging ADC has a pipeline delay of 32 clock cycles.

The datasheet actually implies that each 250 MS/s ADC is made up of a pair of 125 MS/s ADCs which is backed up by 8 fine gain controls.

[coppice]

Subranging or pipelined ADCs replaced flash ADCs a long time ago.

Commercial pipelined ADCs (1970s) predate flash ADCs (1980s), so its interesting that flash ADCs for more than 4 or 5 bits ever appeared.

[marksail]

Hi all, I got a 1054z and DG1022z in early last week.
I'm new to any test equipment beyond a good multi-meter, but learning them has been going fairly well.
Lot's of EEVblog tutorials, and searching around the good info in this thread. THX!

After being able to put a wave file into the signal generator using Ultra Station / Sigma, I figured all systems are an eventual go,
so I decided it's time to go ahead and do the 1054z hack.


But I get 'invalid license' no matter how I go about it.
Whether I input the key from the o'scope Editor, using SCPI commands via telnet (PuTTY) or Sigma....always the same...'invalid license'.
Can't be an issue of confusing B for 8, S for 5, etc...

I've generated DSER several times from http://gotroot.ca/rigol/riglol/, always get the same key.
Tried with a key generated for just Record...it was invalid too.

Serial # on screen matches the one on the unit which matches cal certificate.

Checked firmware via upgrade routine..says same as already installed ...00.04.03.SP2

Sorry to ask for help here, given how often this topic has come up...I've really tried to figure this out...
But I'm stuck...

[marksail]

Problem solved. 
In case other newbs have problems with the code they get from http://gotroot.ca/rigol/riglol/....

I got a different code, one that worked, from the Win app in the 'source code archive', linked at the bottom of the page.
Thanks to a little help today getting the app to work... https://www.eevblog.com/forum/testgear/rigol-'unlock'-source-code-archive/msg1085955/#msg1085955,
and having found out about the app from deep in this thread...

[OE2WHP]

Afaik, the win source uses the same algorithms like the web app.

[marksail]

Afaik, the win source uses the same algorithms like the web app.

Hi OE2WHP ,

do you mean the web app in the source files zip, or the web app at the link http://gotroot.ca/rigol/riglol/       ?

The win app gave me a different code than what the link gave; the win app code worked and the link code didn't.  I'm positive correct ser # was used, etc.
I tried the web app in the source files zip, but it didn't return anything...

[jgilbert]

I'm also having some trouble with the unlock codes. Its a brand new MSO1104Z running 00.04.04.SP1, board revision 6.1.1. I've tried both the command-line tool and the web site, which both generate the same code. Both show up as invalid. Did Rigol change something recently? Or does the code not work on the MSO series?

I've tried the DSAB, DSAC and DSER codes to no avail.

Any hints would be helpful. I've been double-checking every letter twice.

[metrologist]

I didn't think the MSO could be hacked with a simple code?

[Fungus]

I'm also having some trouble with the unlock codes. Its a brand new MSO1104Z

Any hints would be helpful. I've been double-checking every letter twice.

It doesn't work with the MSO.

[Howardlong]

You need to open up the MSO1000Z series (and the ds1000z plus), and get amemory dump with a JTAG emulator. Also there's a special rigup version.

There's vid here on how to do it, but it's also been documented to death on the forum. Recently there have been reports of it not working reliably, I don't know how much of that is user error and how much is a change in scope in the manufacturing process. All I know is it's definitely worked in the past.

[alex27riva]

Hi, how can i remove the hook from the probe (Rigol PVP2150) ?

[David Hess]

Hi, how can i remove the hook from the probe (Rigol PVP2150) ?

It is just a friction fit so pulls straight off.