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

[Evi]

My result

Thanks, Evi!  Are you using USB or LAN connection?

I used USB

[marmad]

More on memory reads:

The Rigol certainly isn't a speed demon when it comes to large memory-depth reads from the DSO. As mentioned before, they seem to have taken care that transfer routines won't interfere with local operation of the scope (via the front panel). While I understand this philosophy in terms of reading display memory (or sample lengths <= 14k) which you might want to do real-time while the DSO is running, I don't really understand it when you're trying to get large captures out of the scope - which has to be stopped while you're doing it.

For example, to read 56MB out of the DSO takes between ~4.5 - 5.5 minutes via USB (depending how clever you are with timing your requests to the Rigol's buffer being filled - and LAN probably takes longer). Compare that to a 56MB save to USB stick: I just timed it with a stopwatch and it took 5 minutes 23 seconds - so they are more or less equivalent (with external transfer being slightly faster). So we can calculate, roughly, that it takes ~1 minute per 10 megabytes  to save memory either to USB or external device.

So perhaps the bottleneck is not so much of a conscious design decision as it is a limitation imposed by extracting sample data from the pathway that normally runs between acquire memory, display memory, and the LCD.

[marmad]

Some sample memory read times in seconds - from the Rigol to the PC using USB (not optimized - and I can't do 7MB or 28MB because of the current two-channel bug). You'll notice <= 14kB is always close to a tenth of a second (although this can be reduced somewhat through optimization). This is slower than reading the display memory - which probably makes sense in terms of internal memory organization:

Reading (AUTO) 70 bytes
Time = 0.0950054

Reading (AUTO) 140 bytes
Time = 0.0890051

Reading 7kB
Time = 0.0950054

Reading 14kB
Time = 0.1010058

Reading 70kB
Time = 0.3350191

Reading 140kB
Time = 0.8340477

Reading 700kB
Time = 2.7551576

Reading 1.4MB
Time = 7.2544149

Reading 14MB
Time = 72.1121246

Reading 56MB
Time = 288.5375034

[marmad]

Measuring the Trigger Output delay of the Rigol. Here it is fed back into channel 2, and it appears the delay is ~220ns:

[marmad]

Hmm... this Trigger Out delay time used to be something that manufacturers specified in the datasheets (or supplementary literature). But I can see no mention of it in either Rigol's docs - or the literature for the Agilent X-Series or the GW-Instek GDS-2000A materials. Lazy backsliding! 

[marmad]

What is the delay from External Trigger in  to Trigger Out?

A little less: ~160ns.

[marmad]

So  External trigger has different processing (more direct route, faster software routine) to display and output (trigger)
Does that say the ASIC takes 60nsec to process?
Is it different at Higher Scan rates; less samples? 
External trigger is most likely an Interrupt into the Main processor.

Would Triggering on Ext. change the update rate?

The digital trigger on CH 1 or 2 has to be derived from the samples from the ADC, so it makes sense that it takes a little longer than the External Trigger In.



The delay time does not vary based on memory depth or timebase settings - and the source of the triggering doesn't affect the update rates. But it turns out that you can make the Rigol count it's own wfrm/s fairly accurately by just feeding the Trigger Out into a single channel (the other channel is turned off), turning on the frequency counter for that channel, and then sending a 1MHz square wave to the External Trigger In. The displayed frequencies at each timebase are very close to the numbers I recorded using my Fluke counter. The image shows the 20ns timebase being counted - note the frequency:

[marmad]

I suppose One could offset the Trigger position to the left of the Screen , and still see the Trigger output step (ie. 14 x 20ns=280 nS)

Yes. And looking at the Trigger Out edge at the smallest timebase setting shows that the delay varies from 159ns to 167ns (exactly 8ns deviation).

 

[Hydrawerk]

Measuring the Trigger Output delay of the Rigol. Here it is fed back into channel 2, and it appears the delay is ~220ns:

Is 220ns a good result?

[marmad]

Did the traces always have the  250ps  spacing?  some sort of Discrete timing resolution
250ps corresponds to 4 Ghz , is that the CPU clock rate ? (different memory access delays)
Does that spacing change with different trigger input frequencies, I suspect NOT
With DPO intensities do some traces occur more often?

Always exactly 32 traces at, as you mentioned, precisely 250ps spacing (8ns total). It looks like when I vary the persistence every 4th trace (1ns / 1GHz) is less frequent.

[marmad]

If you Average 32 captures, you get a single edge with a rise time of 6.6ns. 

[marmad]

  But I do not think the Stability of the 1 Mhz trigger input signal frequency
  Maybe someone has a stable 10 MHz rubidium source  (@EV) to do this same test

I had forgotten, but this 8ns jitter was already mentioned by member pena here - so I don't think it's related to the trigger input stability. Also, EV tried already to measure the rise time, and found it was at least 1.05ns.

[marmad]

Since it's clear from EV's old posts that the slew rate is VERY fast on the Trigger Out, perhaps the jitter is due to that.

According to a Rohde & Schwarz document on triggers, "A digital trigger, on the other hand, theoretically contributes no jitter to the signal, thus meaning that all of the observed jitter would be from noise as a result of the signal slew rate."

[EV]

Jitter mearurement results:

Picture jitter-1: Trig out is connected to CH1 with 50 ohm terminator. Trigger is from CH1 (Trig out signal).

Picture jitter-2: Trig out is connected to CH1 with 50 ohm terminator. Trigger is from EXT trigger which is connected to 10 MHz Rubidium standard.

[EV]

Since it's clear from EV's old posts that the slew rate is VERY fast on the Trigger Out, perhaps the jitter is due to that.

This rise time (1.05 ns) was measured with probe P6205. I have got after that a better probe P6243 and got faster rise time (0.85 ns) for trig out. Look this thread.

Edit: Picture attached.

[Jason]

Check out what happens when I select dots.

1) Horizontally the dots are spaced 200ps / 5GHz apart.  That's significantly faster than my 1GHz sample rate.  That suggests the ADCs might support timing much finer than the sample rate, which might mean the hardware is capable of equivalent time sampling.

2) There are some very tight vertical groups.

Together these suggest that the trigger-out jitter is grouped to some multiple of the ADCs' clock - probably the FPGA's clock.  Perhaps the trigger-out logic runs on a divided clock.  That's really weird though, since the trigger in seems quite accurate.

Disclaimer: I don't know WTF I'm talking about. 

Marmad, might you could give us a screen shot of the trigger pulses on dots mode at 2ns/div?

Edit: Note that this also had 500ms of persistence.

[marmad]

1) Horizontally the dots are spaced 200ps / 5GHz apart.  That's significantly faster than my 1GHz sample rate.  That suggests the ADCs might support timing much finer than the sample rate, which might mean the hardware is capable of equivalent time sampling.

I think you miscounted, Jason. You have 20 dots per div, so 5ns / 20 = 250ps (4GHz or double the max. sampling rate) - which is the same frequency as pointed out previously. I'm guessing that this is perhaps the main clock rate before it's divided.

Marmad, might you could give us a screen shot of the trigger pulses on dots mode at 2ns/div?

I get the same 250ps spacing (8 dots per div at 2ns).

[marmad]

IF one was to record 32 frames , would there be a regular pattern or random positioning of the traces within the 8 ns ?  I think a 3-D plot in ZT would be interesting.

Here you go, Len - there is a pattern, but the exact one is difficult to catch since it's happening faster than frame capture rates:

[marmad]

Yes , I was thinking about that and think that if One feeds in Only a slow square wave = 1/2 the update rate and in NORMAL trigger.
Does minimum Hold-off have an effect? (the HOLD-Off clock resolution )

Also does this 8ns occur when triggering is from Ch1 or Ch2,   not sure of EV's CH1 display.

If you feed a very slow square wave in, you can watch the pattern more clearly. But the 8ns variation always occurs - doesn't matter about the trigger source, speed, sample size, etc; if you look at the image, it shows the measurement statistics.

The Trigger Out delay falls between ~211 - 219ns (using channel triggering). But the difference (~3.6% of 219ns) is not very relevant because if you want to trigger another device, the initial triggering clock speed can't be more than ~4.5MHz max. (1/220ns)  - and if it was 211ns that would still be only ~4.7MHz. So not much difference.

The main point being that for reliably using the DSO to trigger an external device (such as an LA) using the channel triggers, the frequency of the DUT should be <= 4.43MHz.

Edit: If you're just passing the trigger through (using External Trigger In), you might be able to get to 6MHz (1/167ns).

[Hydrawerk]

Who was that on EEVBLOG that has a DS4000? 

Not sure, if he visits Eevblog, but it should be this man called Connor Wolf:

[EV]

Who was that on EEVBLOG that has a DS4000?  (Please forward)
I wonder if this variations on the Trigger output also happens on the DS4000 series?

The Chump seems to have it and maybe AndyC_772.
Look at this thread:
https://www.eevblog.com/forum/projects/software-tips-and-tricks-for-rigol-ds200040006000-ultravision-dsos/255/

[nack]

Who was that on EEVBLOG that has a DS4000? 

Not sure, if he visits Eevblog, but it should be this man called Connor Wolf:

https://www.eevblog.com/forum/index.php?action=profile;u=58374
Jup. And he has quite an interesting youtube channel as well: https://www.youtube.com/user/Fake0Name

[marmad]

I wonder if firmware would be able to set a fix delay,  say 230ns for CHs and 175ns for EXT-IN. or is it just a race
(nops , in firmware to pad timing)

I don't get your point. If you are triggering an external device, the trigger just has to get there before the data changes. As I mentioned already, the total delay sets a maximum frequency (<4.5MHz, depending on when data changes) which the DUT could be running at. The 8ns jitter is meaningless - unless you are silly enough to try to use a frequency which falls in the jitter zone i.e. between ~4.5 - 4.7MHz).

Also, none of this excludes triggering the DSO after another device - or splitting the triggering signal to go the DSO and another device simultaneously. I really think the jitter is a non-issue - although I would prefer a shorter overall delay time.

So, in order to build a MSO based on this DS2000, it sure is going to be Problematic for sync-ing.

An MSO would be all internal - it wouldn't use an external trigger out.

[Jason]

The trig-out jitter won't matter for a LA.  It needs a trigger for roughly when to capture, but for the actual analysis it'll use the bus clock for the exact timing.

It WOULD matter if I wanted to chain two DSO2000's together to watch four channels.  The slaved scope is going to get 8ns of horizontal smear.  For my use it's a non-issue but people trying to observe very fast edges will care.

A couple more observations playing with mine tonight: the jitter pattern is different between the ext trigger and the inputs; and when triggering on CH1 or CH2 the pattern changes when I adjust the vertical gain.  Crazy.

Marmad: Yes, you're right, I read it wrong.  The jitter has .25ns / 4GHz intervals, not .20ns / 5GHz.

[EV]

Here are 3 pictures more about this trig out jitter. Trigger mode is auto from CH1. Note the different trigger level on the pictures.