REVIEW - Rigol DS2072 - First Impressions of the DS2000 series from Rigol

[AndyC_772]

The Chump seems to have it and maybe AndyC_772.

I have a DS4054 at work, which I could probably have a play with if you like.

My own scope is an Agilent MSO-X3054A, and I couldn't resist comparing it... trigger event to trig out delay is 27.6ns, and the jitter on the trig out pulse is about 200ps peak-to-peak, though the scope isn't really able to measure such small amounts with any degree of accuracy.

[marmad]

I have a DS4054 at work, which I could probably have a play with if you like.

My own scope is an Agilent MSO-X3054A, and I couldn't resist comparing it... trigger event to trig out delay is 27.6ns, and the jitter on the trig out pulse is about 200ps peak-to-peak, though the scope isn't really able to measure such small amounts with any degree of accuracy.

Thanks, Andy.

Two quick questions: is the delay you measured from triggering on a channel input or external trigger in?

Also, I've been reading a lot about the X- Series recently - trying to figure out Agilent's specifications for the memory usage (which ain't easy). From what I understand from their specs (assuming you don't have the 2MB Mem upgrade), if you're running all 4-channels simultaneously in Auto/Normal mode - you have 250kB per channel. Is that correct? Or does the halving of memory during Normal mode affect just a channel 'pair' (i.e. 500kB)?

Have you verified actual memory amounts when stopped (since Agilent is obviously fairly cagey in this regard; i.e. no tables anywhere in all of their literature)?

[EV]

Here is trig out jitter when trigged to CH2 100 MHz sine wave. Jitter is about 2 ns. It was about 1.2 ns when trigged to CH1.

[marmad]

It was about 1.2 ns when trigged to CH1.

Isn't that when you had it triggering itself?

I see the same 8ns when triggered from Ch2 with 1MHz sine.

[AndyC_772]

Thanks Andy if you could test the DS4000, off company time

The Agilent does it faster
Was there any difference in the delay between channel triggered and External triggered,
memory depths?
Auto and Normal triggering?

Using the external trigger input, obviously I can't actually see the trigger event itself, but the mid-point of the rising edge on the trigger output is at t=32.3ns, with basically no visible jitter.

Switching between auto and normal triggering makes no difference, and nor does changing the memory depth. However, if there's no signal present, and so the scope free runs in auto mode, then there is trigger jitter - the trig pulse is anywhere from t=19.9ns to t=40.3ns, with a distribution clustered somewhere near the middle of that range.

Of course, in this case it's not triggering on anything in particular, so synchronisation to an external device isn't really an issue - but maybe it gives a clue as to what's making the decision to start a sweep in auto mode. I could convince myself that the spread is exactly 20ns, meaning the 'auto' deicision is made based on a count of a 50 MHz clock somewhere inside the scope.

[AndyC_772]

Two quick questions: is the delay you measured from triggering on a channel input or external trigger in?

See above; channel trigger looks to be a fraction faster. (Interestingly, I've just measured it again and it's come out at 30.2ns - maybe I have a little channel-to-channel skew to calibrate out, or I'm just tired at the end of a busy day and my experimental technique isn't at its sharpest. Apologies).

Also, I've been reading a lot about the X- Series recently - trying to figure out Agilent's specifications for the memory usage (which ain't easy). From what I understand from their specs (assuming you don't have the 2MB Mem upgrade), if you're running all 4-channels simultaneously in Auto/Normal mode - you have 250kB per channel. Is that correct? Or does the halving of memory during Normal mode affect just a channel 'pair' (i.e. 500kB)?

Have you verified actual memory amounts when stopped (since Agilent is obviously fairly cagey in this regard; i.e. no tables anywhere in all of their literature)?

I have the 4M memory upgrade. With just ch1 enabled, I can capture 500us worth of data @ 4Gsa/s before the sample rate starts dropping (2M points), and with ch1 and 3 enabled I can capture the same (ie. total of 4M points split across the two channels).

If I enable 1 & 2 (only), then I get 500us @ 2Gsa/s for a total of 1M points per channel (total 2M points). It can't sample any faster, and the other bank of RAM cannot be used.

So, it looks as though ch1 & 2 share a digitiser which is capable of 4Gsa/s, and they share a common block of 2M points of sample memory. Ch 3 & 4 appear to be separate, and share their own digitiser and RAM.

[EV]

It was about 1.2 ns when trigged to CH1.

Isn't that when you had it triggering itself?

I see the same 8ns when triggered from Ch2 with 1MHz sine.

Yes, it was triggered to itself, but it is also same, if it is auto triggred and the trigger level is outside the trace. I get 8 ns only with external trigger.

[marmad]

Yes, it was triggered to itself, but it is also same, if it is auto triggred and the trigger level is outside the trace. I get 8 ns only with external trigger.

I get 8ns in Normal mode with either channel or external trigger - which is the way I generally use the DSO.

[marmad]

I have the 4M memory upgrade. With just ch1 enabled, I can capture 500us worth of data @ 4Gsa/s before the sample rate starts dropping (2M points), and with ch1 and 3 enabled I can capture the same (ie. total of 4M points split across the two channels).

Hmm... but this doesn't match with Agilent's documents. If you can access a maximum of 2MB per channel-pair, that means when you are running in Normal mode with a single-channel enabled, according to Agilent, you would have a 1MB record length:

"When running (versus taking a single acquisition), the memory is divided in half. This lets the acquisition system acquire one record while processing the previous acquisition, dramatically improving the number of waveforms per second processed by the oscilloscope."

EDIT:  Ahh, I just remembered our discussion over in the "Waveform Update Rate" thread! Perhaps the 3000 X is using 1MB until the final acquire = swapping 1MB banks for speed until you press STOP, and then fills the entire 2MB.

[EV]

I get 8ns in Normal mode with either channel or external trigger - which is the way I generally use the DSO.

I use usually auto mode and I think these jitter values are almost all trigged with auto mode. I try tomorrow normal mode and check if the results change.

[EV]

I tested this jitter with normal sweep. No change when triggered from CH2, jitter is still about 2 ns. When triggered from CH1 (Trig out signal itself), there is no trace with normal sweep. Jitter with auto sweep is about 1.2 ns.

[EV]

  I can  see that If Trigger out is connected to Ch 1, and in Normal trigger there would NOT be a trace, But what if you pressed the "Force" button to get the feedback going??

Pressing the force button when using normal sweep gives one trace but no jitter.

[EV]

Hi All - Rigol are looking at another firmware release in about 2 weeks. This will fix the measurement ,and hopefully other , bugs.

Any news about the fix yet?

[marmad]

Any news about the fix yet?

I know they're working on a new version - I did some testing and delivered a bug report (with software for showing transfer bug) to drieg to pass onto Rigol at the end of last month.

[ve7xen]

After some experimenting last night I can confirm a few things about the bandwidth limit on these scopes.

• The lasered chip in the frontend is definitely a LMH6518 PGA (or pin-compatible clone)
• It is the only analog bandwidth limit in the scope, and is used both for the 20MHz filter and 100MHz limiting
• DS2072 and DS2102 are presumably identical except for the 2ns timebase, given the tested -3dB response of the DS2072 and the fact that only the 100MHz PGA filter is engaged for bandwidth limiting
• -3dB bandwidth of the frontend is somewhere around 300MHz, so the 200MHz filter is likely used in the DS2202

This suggests to me that a software upgrade is definitely feasible for Rigol to offer. I'd expect to see one coming.

[marmad]

This suggests to me that a software upgrade is definitely feasible for Rigol to offer. I'd expect to see one coming.

Interesting stuff, ve7xen - thanks for that. Your conclusions correspond with the section listing 'Option Type' and 'Option Name' inside the firmware, which has the following:
Option Type    =  BANDWIDTH
Option Name  =  100M Bandwidth
                           200M Bandwidth

[Salas]

Did anybody who open the case mark down the type and brand of the cooling fan?

[marmad]

Did anybody who open the case mark down the type and brand of the cooling fan?

In Dave's teardown video, you can't see any markings on the side that's exposed - so I'm guessing you might actually have to unscrew it from the inner shielding in order to see the brand name, etc.

[Hydrawerk]

The fan is quite small.

[marmad]

The fan is quite small.

Compared to what??

[Hydrawerk]

Compared to DSOX2000, Tek DPO2000 or even Rigol DS4000. Well not a big issue.

[marmad]

Compared to DSOX2000, Tek DPO2000 or even Rigol DS4000. Well not a big issue.

No, it certainly isn't. Quit being a troll.

[Pinkus]

DS2072 and DS2102 are presumably identical except for the 2ns timebase, given the tested -3dB response of the DS2072 and the fact that only the 100MHz PGA filter is engaged for bandwidth limiting

?? I thought, the DS2102 does not have the 2ns timebase - or am I wrong?
Peter

[marmad]

?? I thought, the DS2102 does not have the 2ns timebase - or am I wrong?
Peter

No, you're right. As far as we know, there might be no difference between the DS2072 and DS2102 besides the front panel sticker (and the model number in firmware). I haven't read anything that would indicate otherwise yet.

[Wim13]

That they are the same , you can also find it back in the bandwidth graph,
here is the graph of my 2072, measured with a signal generator and a measuring head on the entry of the 2072.
The measuring head is  compensating every loss from generator to the entry of the DSO