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

[Mark_O]

Just to make it Clear to all;

Good idea.  Make it clear to all, and not just me. 

Zooming has no effect if there are Decoding errors. The decoding is done on the full un-Zoomed data.

Thanks for showing it's possible to zoom in beyond the point where decoded data is showable, yet still properly detect and show the byte boundaries.

However, that doesn't imply that decoding is done on the raw data, unzoomed or otherwise.  Everything I've ever seen or read indicates decoding is done from the screen display data.  And it's actually unnecessary to go beyond that.  If you consider how many decoded chars you can get on the screen at once (about a dozen), or even the collapsed <...> bytes (about twice that), it's still well within what would be expected when working from the 700 display samples (down to 240 bit-cells, in that case).

Below I show 3 displays where the errors still exists. Note you can see the error gaps

Yes, I can.  Thanks!  I find it quite interesting that, in spite of your hypothesis that whenever the samples/bitCell is <28, it fails, in fact it is still working, most of the time (82%).  And look at the pattern...  2 correct, 1 skipped, 3 correct, 1 skipped.  Repeat.  This suggests that it's phasing in and out, or something similar. The ones it missed didn't have any fewer samples/bit than the ones it handled properly!

I also like your grabs, which demonstrate that the Rigol displays the contents adaptively.  "Data: 0xNN", to "D:0xNN", to just "0xNN", to <...>.

Also Note that  if there are errors in non- Record mode there will be errors in the recorded frame ( same recorded points are used, Not the display data)

Well of course if there are any errors at any point in the acquisition process, there will be errors in Recorded frames.  However, A implies B doesn't mean the converse is also true.

[kff]

Is anyone else seeing a screen flicker in their ds2072a? It is especially noticeable on grays, and is probably caused by backlight leds. I would estimate the frequency at 40-60 hz. I searched here and on Google and surprisingly didn't find any posts mention this. Did I get a bad unit, or are you all less picky than I am? The scope is not modified in any way.

[Teneyes]

I find it quite interesting that, in spite of your hypothesis that whenever the samples/bitCell is <28, it fails, in fact it is still working, most of the time (82%).  And look at the pattern...  2 correct, 1 skipped, 3 correct, 1 skipped.  Repeat.  This suggests that it's phasing in and out, or something similar. The ones it missed didn't have any fewer samples/bit than the ones it handled properly!

I was wrong
I did more tests and I think I can show the limit for samples per bit for good decoding
The setup:
      14K Pts
      500us/div
      2MSa/sec
      400Kb/s , 500Kb/s , 666Kb/s , 900Kb/s
See Displays  for:
             5 Samples per Data Bit
             4 Samples per Data Bit
             3 Samples per Data Bit
             2 Samples per Data Bit
                A quirky Display
My Conclusion, The requirement for good decoding is 4 samples per Bit (RS232)

[Circlotron]

Is anyone else seeing a screen flicker in their ds2072a? It is especially noticeable on grays, and is probably caused by backlight leds. I would estimate the frequency at 40-60 hz. I searched here and on Google and surprisingly didn't find any posts mention this. Did I get a bad unit, or are you all less picky than I am? The scope is not modified in any way.

I noticed it a little when you are looking down toward the screen maybe 60 deg off axis but not when looking straight on. Mostly when the menus were showing and I *think* just after switch-on.

[Mark_O]

I find it quite interesting that, in spite of your hypothesis that whenever the samples/bitCell is <28,...

I was wrong
I did more tests and I think I can show the limit for samples per bit for good decoding
...
My Conclusion, The requirement for good decoding is 4 samples per Bit (RS232)

Nicely done.  I concur that 4 samples/bit is the magic number here (and not 28).    

(Though it may not specifically be a requirement for those 4 samples, but rather that anything less will result in the start/end phase of a bit-cell falling out of sync tolerance.)

Think about what that implies for acquiring comms-type data in segments, in RecordMode!  Properly adjusted, the duration and size can be quite amazing.  At just 4 samples/bit, that's 7x(!) as long as you originally thought possible.

[Teneyes]

Think about what '4 Sample points/Data Bit' implies for acquiring comms-type data in segments, in RecordMode!  Properly adjusted, the duration and size can be quite amazing.  At just 4 samples/bit, that's 7x(!) as long as you originally thought possible.

Yes  the recorded frame below of a 270 byte/frame and at 8128 frames  shows that 2,194,560 Bytes of data were recorded.
BUT, I adjusted the speed and block size to maximize the capacity of the DSO.
IRL, with the DSO setting a Fixed sample rate for the Timebase and Memory depth selected there will be limitations.

Note: In my test I found 5 samples/bit better as there was missed start bit errors with just 4 samples

[Teneyes]

EDIT:    This Bug is Fixed in Latest Firmware 00.03.00.01.03

Here's an Obscure Bug.   It is an ERROR in the displaying of Decoded RS232 Data. under certain conditions  .

The Basic set-up is:
        RS232 Data Triggering on 'Start bit' for 115.2Kb/s
        RS232 DATA Decoding   for 115.2Kb/s
        DSO set for normal Triggering
        DSO set zoom down to 5us/div in Zoom window
        Memory Depth   at   14kPts  ,  140Kpoints
        Timebase settings of 500us  to 10ms

        Data Block set to 10 Bytes burst of Hex '55'
        ( 2 second repeats not significant)
        data pattern  is START (1), 0101 0101 ,  Stop (0)

Below I show a series of Displays, and the descriptions are:
#1  Mem=140K,500us/div,Display of Decoded Data is positioned after Start Bit,  3 Bytes OK
#2  Mem=140K,500us/div,Display of Decoded Data is positioned after Start Bit,  Position  OK
#3  Mem=140K, 1ms/div ,Display of Decoded Data is positioned after Start Bit,  Position  OK
#4  Mem=140K, 2ms/div ,Display of Decoded Data is positioned after Start Bit,  Position  OK
#5  Mem=140K, 5ms/div ,Display of Decoded Data is positioned after Start Bit,  Position  OK
 
#6  Mem=1.4M,500us/div,Display of Decoded Data is positioned near Start Bit,    Position Shifted
#7  Mem=1.4M, 1ms/div ,Display of Decoded Data is positioned near Start Bit,   Position Shifted
#8  Mem=1.4M, 5ms/div ,Display of Decoded Data is positioned before Start Bit, Position Shifted
#9  Mem=1.4M,10ms/div ,Display of Decoded Data is positioned before Start Bit,Position Shifted

#10 Mem= 14M,10ms/div, Display of Decoded Data is positioned after Start Bit,  Position  OK


The ERROR seems to occur only In Zoom window with a Memory depth of 1.4MB and the shift increases as the Timebase is Longer       
The decoding is correct , it is just the Position on the Display is NOT sync'd to the corresponding waveform
NOTE:  in both firmware  00.02.01.00.03 and   00.03.00.00.00

[Teneyes]

EDIT:    This Bug is Fixed in Latest Firmware 00.03.00.01.03
The shifting of Decoded Data at 1.4MPts also occurs when a Data Trigger is used.
Note: the Displaying of the Triggering DATA Byte is positoned at the trigger pointer (orange) is when the Data byte is completely detected , at halfway point of the Last Bit in the Data Byte.  For 1.4MPts in is shifted earlier 1.5 bits
Trigger point = x'55' = Binary '85' ,  disappointed that if display is in Hex that the data trigger is not also in Hex

See Displays:

[Teneyes]

EDIT:    This Bug is Fixed in Latest Firmware 00.03.00.01.03
After show the shifting of data Bug in previous post , WIM13 referred me to a Decoding BUG at long timebase settings (>10ms/div).
I did some testing , using 56MPts.

Here are displays showing good decoding of long 3000 Bytes data Blocks at 20ms/div using 115200b/s decoding.
All the Decoding is Perfect from first Byte to Last. 
The series of displays are with varying Bit Patterns:  x55, xFF, xF0, and x00.
And Zoomed in to 5.050us/div  , (one byte)
Check them out.

[Teneyes]

EDIT:    This Bug is Fixed in Latest Firmware 00.03.00.01.03
The Big Problem with the Perfect displays in my last Post was that the input was at 112000 b/s NOT 115200

Notice the Delay from the trigger to the end of last byte is 267.85 ms
Perfect for  a data rate of 112000 b/s
Bit Rate(b/s)   Bit Period (ms)   Byte period (ms)   Total Block Period (ms)
  112000            0.008929               0.08929                     267.8571

FOR 57.6Kb/s    56Kb/s  shows perfect decoding

I sure wish Rigol checked their Firmware !!!  (00.03.00.00)
I hope this is NOT crippling of the DS2000 DSO, but I think this is on the DS4000 series also.

I'm not doing so well at the 50ms/div timebase ,

[Wim13]

In my post of 25 dec 2013, already noticed that there as more noise on the FW 00.02 version, with two channels enabled.
Not with 1 channel enabled, then the signal is clean.

so i tested version FW 00.03 but still the noise is there.
Test signal is 100 Mhz 0 dB, on other scoop it is a steady clean signal. ( also on FW 00.01.01, or on one channel ) )

In a later post there was stated that it has to do with the shading.
But if you look at the RMS values they also changes a lot, difference between one channel and two channel enabled.

the best version was and is still 00.01.01, gives the best result.

See pictures below, test1 is FW 00.01.01, test2 is FW 00.02, and test3 is FW 00.03

[Wim13]

Implementation of FFT, differenses between DS2000 and DS1000z, most
things works the same on these two DSO.

i had the possibility the see the FFT on a DS1000z, most things are the same
on a DS2000 and a DS1000z.

But on the DS1000z the FFT is more user friendly, even better as on the DS2000

[Mark_O]

so i tested version FW 00.03 but still the noise is there.
Test signal is 100 Mhz 0 dB, on other scoop it is a steady clean signal. ( also on FW 00.01.01, or on one channel ) )

On Test3-1 vs. Test1-2, it's obvious the intensity grading is significantly higher.  Did you change that, or is the firmware rendering the same level setting differently?

[Wim13]

No i did not change the grading, but the signal in test 1 is much cleaner.

in the pictures the same singal generator is used and the same setting.

[Teneyes]

so i tested version FW 00.03 but still the noise is there.
Test signal is 100 Mhz 0 dB, on other scoop it is a steady clean signal. ( also on FW 00.01.01, or on one channel ) )

EDIT:    This is better in Latest Firmware 00.03.00.01.03
Here are displays showing Dot sample .  #1 Ch1 only then #2 display of Ch1&Ch2
  In dots mode the Vrms on Ch1 =425mV
  In dots mode the Vrms on Ch1 =429mV with Ch2 on
In vector mode the Vrms on Ch1 =447mV with Ch2 on
In vector mode the Vrms on Ch1 =420mV with Ch2 on and at 2ns/div

I think a the Sin(X)/x interpolation is making some of the difference.
With TB set to 2ns/div the waveform is more accurate.
There is some affect when Ch2 2 is ON. there are Many factors to consider.

These displays are with 2048 point averaging to filter noise

[Wim13]

i did a test on a DS1000z  where you can turn off and on Sin(x)/x
that makes a lot...lot  off difference. ( temp a DS1000z  for test ).

But why was it then on FW version 01 of the DS2000  better, what did they change..?


(pictures below are from the DS1000z, for the DS2000 see some posts back )

[Sparky]

i did a test on a DS1000z  where you can turn off and on Sin(x)/x
that makes a lot...lot  off difference. ( temp a DS1000z  for test ).

Whoa! The amplitude change --- how could sin(x)/x interpolation change the amplitude like that?

But why was it then on FW version 01 of the DS2000  better, what did they change..?

Whatever they did, it is unfortunate...  I will hope they find it as a bug and change it back.

[Teneyes]

The External Frequency Counter.
I just realized the FW 00.03 allows the 'Ext Trig' input to be used as a Counter,
Some measurements:
        Selectable from the Counter menu
        Range       =  15hz - 52MHz
        Resolution  =    6 digits
        Sense       =   280  mVpp   

Note: The counter had a Flashing display for several minutes before it started working, (a Self Calibration on first use maybe???)

[Galaxyrise]

i did a test on a DS1000z  where you can turn off and on Sin(x)/x
that makes a lot...lot  off difference. ( temp a DS1000z  for test ).

Fifteen sample points per waveform, goodness! There's hardly any real data there, it's almost all interpolated. I wonder what interpolation it's using when you turn sin(x)/x off; it doesn't look like 15 straight line segments to me, and it's certainly not 15 points. 

[Wim13]

Implementation of FFT, differenses between DS2000 and DS1000z, most
things works the same on these two DSO.
But on the DS1000z the FFT is more user friendly, even better as on the DS2000

@Wim
Good to see Wim, I hope those features will go into the DS2000 Firmware someday
On the DS1000;
Can you please check what happens when you push the Multifunction knob when selecting the FFT vertical offset & Vertical Scale,
On the DS2000 with Vrms , pushing knob set 0 Vrms to the middle of the scale , Useless
What is a negative Volt on an FFT display???
Thanks

That is the same on the DS2000 and the DS1000z,
i also see no use for negative voltage for a FFT display in Volt mode, that works with AC voltages.
But it is only the scale that has a negative voltage, not the signal.

On the DS2000 the FFT controls depends lot on the timebase, you have to
change the timebase first to change the FFT range.
On the DS1000z it is different, if you change the timebase, the FFT follows.
thats is more user friendly.

The more i look at the DS1000Z the more i like it.
The DS2000 is better in performance and faster, but the DS1000z UI has
learned from the DS2000 and is enhanced.

[Keyrick]

With more and more people stating and receiving the New FW 00.03.00.00, I thinking it would good to report new Bugs here.  Marmad has kept a good list on the 3rd post of this Blog.  Altough Marmad usually confirms all bugs himself , I think it would be helpful for a few others to confirm any reports.  Also if any Fixs to an existing bug is a complete fixed.

These are Bugs I have found:

     #03__01   The Clear Button does not work.

     #03__02   The decode display does not clear when decode is turned off

     #03__03   Once the lg(CH1) advance Math function is applied you can Edit the function;
                   If the Expression button is press the DSO hangs. and if in start Last System. the
                   attempt to change the expression , will hang the DSO!!!    

     #03__04   The Set Counter Menu has display Error (unnecessary scrolling,small )  see Pics
                   This occurs when system 'System'-'Power On' - is set to 'Last' and the trigger is
                   NOT set to EDGE trigger.
                   Power cycle after PULSE trigger causes 3 items in Menu ,most others 2 items set in Menu
                   Auto Setup Button resets trigger to Edge  and all 4 Menu Items??? (CH1,Ch2,Ext,Off)

If anyone ventures onto Fw 00.03.00.00, please help to confirm any of these.

Edit 1  Added more info on Bug #03__04

Is there any reason that all users of a DS2072A should upgrade to 00.03.00.00?  I just received mine on Friday, and I asked Rigol for a copy of the new firmware.  They sent me a copy of the GEL file and the procedure to install it.  They also advised, in a cautionary way, that there should be a reason to do the upgrade, and as a newbie to this hardware, I don't see the need as of yet.

With the bugs found in the new version, I am wondering if it is prudent of the user, other than for enthusiasts who want the latest and greatest, to perform this upgrade on their scope.  I have not found anything from the manufacturer that denotes the improvements found in the .03 version.  I may have missed the valid reasons for doing so, and it would be nice if someone could point those features/improvements out to a newbie like me!

So, should I install 00.03.00.00?  Thanks in advance for any responses.

Rick

[Teneyes]

I have not found anything from the manufacturer that denotes the improvements found in the .03 version.  I may have missed the valid reasons for doing so, and it would be nice if someone could point those features/improvements out to a newbie like me!
So, should I install 00.03.00.00?  Thanks in advance for any responses.
Rick

HI Rick and welcome to this Forum,

Good Question, and quick answer is NO. ,
I suggest get used the FW 00.02.01.00.03, and check the list of bugs on the 3rd post here (collected by Marmad and others).
It is better to know the pit falls found by others. 
But here are some features added in FW00.03.00.00 that you may need on Occasion.
    Ext Input used as Frequenct Counter
    Recording Frames of Serial Data Decoded
    Fix of some of the Bugs list

In any case you can switch back to the old FW at any time .
(In order to switch Firmwares , one can use a USB stick and Load FW into the DSO)
( it only takes 171S to change from FW 00.03... to 00.02.....)
(     and  237S to change from 00.02... to 00.03....  bigger file)

[Keyrick]

Thanks Teneyes for the welcome and the response.  I think I will wait and use this bad boy for a while before I decide to do the upgrade.  With that in mind, I will ask another newbie question.

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?  BTW, my scope is on 00.02.00.00 from Tequipment.

Thanks again.

Rick

[Keyrick]

Gotcha,

Thanks. 

[megik]

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?