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

[Mark_O]

What does  "it takes 171S to change from 00.03 to 00.02 and  237S to change from 00.02 to 00.03  bigger file" mean?  Is that a file that is resident on the scope? 

Rick, it just means that it takes about 3 minutes to load the old v2 firmware, if you decide to revert back from v3, after trying it.  And more like 4 minutes to move ahead again to v3, due to the larger size of the image.

I.e., neither difficult nor time-consuming to try both, and decide which you prefer.

[Wim13]

hello
I wanted to learn about the lithium battery (cr2032) in (ds2072)
it is only responsible for the RTC belt ?? or remove it if it does not affect the calibration data???
in some multimeter Rigol which battery is installed to preserve the memory of calibration constants....
important question of who can know?

It is only for the RTC,  as far as i know there is no alternative for a RTC, you need some battery.

[Fagear]

Some photos of my DS2072A from inside.


I feel some problem here...

I think I'll resolder those clips later.

Some interesting stuff with front panel:


I can see covered hole for signal generator button (to the left on photo) and... hole for "logic analyzer" button to the right?


And some buttons ripped off from membrane:


Encoders are some "LJV":


And waveform playback control is from ALPS:


Full album here (Russian langauge).

[WVL_KsZeN]

Here's a weird bug in the average function :

-hook up channel one to the 1khz test signal
-hit auto button
-change timebase to 50ms

now your signal just looks like a wide band, like you'd expect on a graded display. OK.

-turn on averaging in the acquire menu, 2x will do nicely.
-> wtf! what happened to our signal? the wide band just turned into a small ribbon
-it gets even weirder when turning on anti-aliasing, now the ribbon is waving over the screen

What is happening here? The scope is fetching 14Mpts, so there shouldnt be any weird aliasing things happening, but still it's there.

It looks normal again when you go to 20ms timebase.

[miguelvp]

I got the same result, it's very weird!



But at 20ms timebase I see artifacts that shouldn't be there either.

Edit: adjusting the trigger affects the shape, tried also AC coupling and same deal.

[edavid]

Here's a weird bug in the average function :

-hook up channel one to the 1khz test signal
-hit auto button
-change timebase to 50ms

now your signal just looks like a wide band, like you'd expect on a graded display. OK.

-turn on averaging in the acquire menu, 2x will do nicely.
-> wtf! what happened to our signal? the wide band just turned into a small ribbon
-it gets even weirder when turning on anti-aliasing, now the ribbon is waving over the screen

What is happening here? The scope is fetching 14Mpts, so there shouldnt be any weird aliasing things happening, but still it's there.

It looks normal again when you go to 20ms timebase.

Did you try setting the trigger to normal instead of auto?

[miguelvp]

Did you try setting the trigger to normal instead of auto?

normal sweep has the same behavior.

[Teneyes]

Here's a weird bug in the average function :
-turn on averaging in the acquire menu, 2x will do nicely.

Oh it's an Undocumented feature by Rigol. 
I think some sort of Beat freq. with the way Averaging is calculated, combined with Intensity grading and Bug #18 noted in the 3rd post of this blog
Here's some more displays:
   at slightly off frequencies (999.8, 999.9, 1000.05, 1000.1, 1000.2 Hz)
   at off duty cycle  50.7%
and scanning at 49.80ms/div . 
   
Note to Newbies:  I used Marmad's RUU software to capture and post here in 30 sec/pix (no stick 4 me)

[miguelvp]

Note to Newbies:  I used Marmad's RUU software to capture and post here in 30 sec/pix (no stick 4 me)

Been meaning to install that software, specially for the cool plots in time. Thanks for the remainder (who am I kidding I probably wait another 4 months to do it).

[WVL_KsZeN]

Here's a weird bug in the average function :
-turn on averaging in the acquire menu, 2x will do nicely.

Oh it's an Undocumented feature by Rigol. 
I think some sort of Beat freq. with the way Averaging is calculated, combined with Intensity grading and Bug #18 noted in the 3rd post of this blog
Here's some more disppays:
   at slightly off frequencies (999.8, 999.9, 1000.05, 1000.1, 1000.2 Hz)
   at off duty cycle  50.7%
and scanning at 49.80ms/div . 
   
Note to Newbies:  I used Marmad's RUU software to capture and post here in 30 sec/pix (no stick 4 me)

What I don't get is that the signal is always completely messed up while triggering is functioning properly. You'd expect Rigol to do either of 2 things :

- calc average from screen data (but surely they can't, since you can still zoom in afterwards)
- calc running average from all the captured data (this is what they must be doing, since averaging also works when capturing 56Mptoints and there is simply no more memory)

But that last one is also not what is going on, we can see that. The signal is properly triggered, so the data should be the same for each captured waveform and at 50ms/division, we're getting about 50*12ms = 600ms of data, showing 600 periods of the 1kHz signal. So we have 14Mpts/600=23.333points available per period and should not expect any weird aliasing stuff..

Somehow Rigol must not be calculating the average from all the points from each waveform. It gives me the feeling that Rigol is using points from waveform 1 at time offset x and points from waveform 2 at time offset y to speed up the calculation. Or some other way to sneakily do it, giving these weird results.

[Teneyes]

Hello All
   I just received  new FW 00.03.00.01.03
   Has anyone got this version???
   It seems to fix bugs I had found, more testing to do.
   See Pic for new Acquire Menu , room for Logic speed setting???
 Get It Here

[EV]

Maybe this is official version because the last numbers are not zeroes any more. 

...
   I just received  new FW 00.03.00.01.03

[Teneyes]

New FW:
   Good Decoding of 57600 and 115200 data and up to 900000,
   (New function to copy Trigger baudrate to Decode)
   No DSO freezing on Math lg() function
   No Decoded Data Shift when set on 1.4MPts memory depth
   Long recording of RS232 Decoded data at 115200
       (1600 byte blocks * 508 Frames = 814,800 Bytes)
   When Counter set on EXT Trigger is in Green colour now
   The Sin(x)/X is better for two channels

  Has anyone seen the Offcial list of modifications?
  Get It Here

[Wim13]

The new FW did not salve the grading problem at 100 Mhz , version 01.01 still is the best.( see pictures below)

New BUG, downloading a screen shot via ethernet is soooo slowwww  ( 35 sec) , i was thinking RUU was not working anymore,
reset several times, but it was the RIGOl, also tested with other PC and Ultra Sigma, same result.

[EV]

Here are 2 pictures with new FW. Both channels are on. The other picture is when Display Type is Dots and the other when it is Vectors.

[Teneyes]

New BUG, downloading a screen shot via ethernet is soooo slowwww  ( 35 sec) , i was thinking RUU was not working anymore,reset several times, but it was the RIGOl, also tested with other PC and Ultra Sigma, same result.

Yes I confirm Ethernet access to the DS2000 with FW 00.03.00.01.03  is much slower than FW 00.02.01.00.03
The time to save a display to PC changes from about 5 seconds/frame  to 33 seconds/frame .

I use USB at 3 sec/frame

[Teneyes]

Has anyone seen and know what is the meaning of the new addition 'OPEN' to the "Power on" selection menu along with 'Default' and 'Last'??

[davidefa]

Not installed the new firmware, but I think is someting similar to: load last settings ( those used at turn off, this is the normal behaviour with my software ) or use 'some default' settings

[Fagear]

Don't know if it will be helpful... But while Dave still is waiting for stable FW to do his DS2000 review I've shot my own video.
Why it can be not helpfull? Well, it is not on English.

Unpacking: ?? Rigol DS2072: ? ?
Review: ?? Rigol DS2072: ??

Maybe I will do some captions on English later. Don't know yet.

[miguelvp]

He already did a while back (over a year ago):



There is a teardown too. But I'll look at yours when I get home from work.

[Teneyes]

FW 00.03.00.01.03 , Still No SCPI command access to 'CAN' protocol
See Display for:
  The SCPI command to set the trigger mode to 'SPI'
  The SCPI command to query  the current trigger mode 

  The SCPI command to set the trigger mode to 'CAN'
  The SCPI command to query  the current trigger mode 
 
  The DS2000 was manually set to 'CAN'

  The SCPI command to query  the current trigger mode 
 
  The SCPI command to set the trigger mode to 'USB'
  The SCPI command to query  the current trigger mode 
 

[Teneyes]

Multiple Bursts of 'CAN' messages with short duration between Bursts (75us burst period)

Multiple Bursts of 'CAN' messages with ERROR of missed Frames as the duration between Bursts is too Short.(102us burst period)

I'm not sure what the "Interframe space consists of at least three consecutive recessive (1) bits" spec.
in 'CAN' protocol means. ??
SPEC

Well I'm learning 'CAN' Frame Format and is shown in  #3 Pic

#4 shows the minimum time before next Burst will be decoded =  about 3 Bit periods

[zibadun]

Don't know if it will be helpful... But while Dave still is waiting for stable FW to do his DS2000 review I've shot my own video.
Why it can be not helpfull? Well, it is not on English.
Maybe I will do some captions on English later. Don't know yet.

, ?? ? ??. ?, ?! 

?

update: ok. the 'not English' font did not work  .  Maksim, great informative video. Thanks, good luck!

[Mark_O]

I'm not sure what the "Interframe space consists of at least three consecutive recessive (1) bits" spec.
in 'CAN' protocol means. ??

After the End of Frame field, there must be a minimum of 3 Recessive bits for the IFS field.  Of course, in Bus Idle, there can be any number of recessive bits for inter-frame space after that.  But 3 is the minimum, before another Dominant bit can trigger the next SOF.

EDIT:  I'm disappointed to see that they've failed to implement SCPI support for CAN.  That's pretty bogus.

[Mark_O]

#4 shows the minimum time before next Burst will be decoded =  about 14 Bit periods

If 14 bit periods are required, as you've indicated, then that means it can not successfully decode back-to-back CAN packets, which I deal with all the time.  I.e., no value as a diagnostic tool. 

EDIT:  OK, I think I see (most of) the problem.  You're counting the minimum interval before the next burst, starting after the ACK slot, right?  There are 11 bits after that which are still part of the CAN frame: ACK delim(1), EOF(7), IFS(3).  Which must all be recessive, so it just looks like dead space.  That accounts for 11 of the 14 bits you indicated.