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

[GermanMarkus]

So there seems to be an internal difference between the STANDARD 57600 baud decoding and the USERDEFINED 57600 baud decoding in the DS2072. So I tuned  down the userdefined baudrate to approx. 56200 baud and at this baudrate the decoding showed exactely the same incorrect decoding like the STANDARD 57600 baudrate mode.

Did you find what the higher limit of the UserDefined Baud rate also failed? 59,000?
To see what the tolerance band is.
Does it look like the program is sampling at 56,000 hz and not 57,600hz?
AS 14,400, 28,800, 57,600.... are called 14K 28K and 56K Baud

Hello Teneyes and all the other folks
Thanks for the reply!
So it seems like Teneyes assumed: The "standard" serial decoding on the DS2000 series apparently has some issue with the baudrate decoding timing: Selecting 56700 baud in "standard" mode uses 56000 baud to decode and NOT 57600!! But if you select the user defined baudrate and set this one to 57600 it works perfect! Tuning down in user defined baudrate to 56000 baud the decoding shows exactly the same problems like in standard 57600 mode. Maybe the DSO uses also 14000 (instead of 14400), 28000 (instead of 28800) in standard decoding mode - I dont know and have not tested that baudrates yet.
I´m using the latest FW 00.01.01.00.02!
So it´s not a big deal if you know what´s going on because you always can use the user defined baudrate - BUT SEEMS TO BE A FW BUG!

Take care and have fun with the DS2xxx´s anyway.

Markus

[marmad]

Maybe the DSO uses also 14000 (instead of 14400), 28000 (instead of 28800) in standard decoding mode - I dont know and have not tested that baudrates jet.
I´m using the latest FW 00.01.01.00.02!
So it´s not a big deal if you know what´s going on because you always can use the user defined baudrate - BUT SEEMS TO BE A FW BUG!

Thanks, Markus. If you could figure out the full parameters of the bug (e.g. by testing the other rates so that we know the extent), we can add it to the FW bug list - and report it to Rigol.

[tinhead]

FFT

wondering a bit about that picture, FFT center is 3kHz (so full span 6kHz) but FFT sample rate 10kSa/s ? That didn't make any sense. Or is that zoomed in and moved to left side?

[GermanMarkus]

Maybe the DSO uses also 14000 (instead of 14400), 28000 (instead of 28800) in standard decoding mode - I dont know and have not tested that baudrates jet.
I´m using the latest FW 00.01.01.00.02!
So it´s not a big deal if you know what´s going on because you always can use the user defined baudrate - BUT SEEMS TO BE A FW BUG!

Thanks, Markus. If you could figure out the full parameters of the bug (e.g. by testing the other rates so that we know the extent), we can add it to the FW bug list - and report it to Rigol.

Hi Marmad,
you and the others guys do pretty great stuff here - keep on with your work and thanks a lot!
So I´m trying to contribute a little bit too and was doing some more investigations with an independant serial transmitter (in this case I just was using an ordinary PC for generating quite long serial strings with approx. 100 characters each).
The result is that all of the standard decoding baudrates (2400, 4800, 9600, 19200, 38400 and 115200) work perfect! The only one who decodes with the wrong baudrate timing is the 57600 one. This decodes with 56000 baud!

So this is definitely a FW bug (I´m using the latest FW 00.01.01.00.02) and it would be great if you can put this issue on your FW update list - Thanks!

Anyway - as described before - the workaround for this kind of minor bug is quite easy: If you want to decode a 57600 baud serial string, just use the user defined baudrate and set this one to 57600 and everything is decoded fine!

Have fun in life and with the DS2xxx!

Markus

[GermanMarkus]

[]The only one who decodes with the wrong baudrate timing is the 57600 one. This decodes with 56000 baud! [/b][/color]
the workaround for this kind of minor bug is quite easy: If you want to decode a 57600 baud serial string, just use the user defined baudrate and set this one to 57600 and everything is decoded fine!

Hi Markus

SET THE RS232 TRIGGERING

Hi Teneyes,
I think the triggering has nothing to do with the timing of the serial decoding, so when triggering on the rising edge and in single mode it will trigger as soon as there will be the first communication character. I was triggering on all the other tested baudrates the same way and only in 57600 baud decoding the timing for the decoding is wrong. I think the timing for the decoding is completey independent of the triggering - am I wrong?
As you can see in my pictures the first character was decoded correct and then the decoding was wrong, that means the timing for the decoding was running wrong...
So I still assume this is a firmware bug...

Greez, Markus

EDIT: So, for being absolutely sure I was doing my tests again, this time with RS232 triggering but the result is the same: WRONG decoding in 57600 baud mode - all other baudrates work fine in decoding! So, it´s not a big thing, but it´s a BUG;-)

[tinhead]

wondering a bit about that picture, FFT center is 3kHz (so full span 6kHz) but FFT sample rate 10kSa/s ? That didn't make any sense. Or is that zoomed in and moved to left side?

The display was 50Hz/div , span of the display =14 x 50 = 700Hz
therefore the display was from 2.65 - 3.35 KHz

 "According to the Shannon Sampling Theorem"

i haven't asked about Shannon but about settings. It is not like you think it is, you can't simply count the visible DIVs and multiply with per DIV value as it could be zoom or part of zoomed window (which is here the case). Center is set to 3kHz, so worst case full span would be 6kHz, what is too much for 10kSa/s. And this is exactly what i asked, and the proper answer was "yes, it is zoom/cut/moved so span 2.65 - 3.35 KHz".

[poida_pie]

we seem to be looking at the FFT function of the DS2072 right now.

Have a look at the results I get.
Input is via 50 ohm bnc, with terminator, from Rigol DG1022, 6.32 kHz sine, 1v p/p into
my DS2072 channel 1 200mV/div.

Even though I have chosen a timebase to yield a decent FFT sample rate for the input signal
to display the FFT (the purple text in the first image says "50.000kSa/s") it seems there are lots of
rubbish peaks in the FFT. There is no way the function generator has that kind of signal from a 1 v sine
into 50 ohms.

See the second image. This is from a custom program I wrote that obtains the raw sample data from the DSO
and then performs FFT. the db scale is incorrect. forget about that for this discussion, it is immaterial.
Notice how you see what you expect to see, a clear peak at 6.32kHz and another much smaller one at 2x 6.32kHz. This is to be expected from a cheap function generator. The specs say about 1% THD anyway.
The DS2072 sample rate in this case was 50 kSa/s. I download only the first 2048 samples of the 14,000 available and process it. I also draw the waveform's first hundred or so points above the FTT.
My program can obtain more of the samples, up to 8K and it shows the same story. I use 2048 samples each transfer
to save time and increase frame rates.
You can see the sample points too, they are drawn in white. So it's a 6.32kHz sin, sampled at 50 kSa/s.
The correct information is there. No rubbish peaks. (I dare not use the word alias or I will be shouted at again)

To get a realistic FFT of a signal on the DS2072 you need to speed up the time base to much faster than
the FFT display's sample rate. At 100K there are clear problems still, I need to go to 200kSa/s to get something
approaching reality. This is what I used for the third image.

I conclude by saying that the Rigol DSOs I have owned (DS1102e and DS2072) BOTH perform the same way with respect to generating FFT displays.
They use the display data to make the FFT, not the raw sample data.
This limits very severely the quality of the FFT results.
You need to choose a timebase or sample rate to provide a DISPLAY that has not much fine detail in it
if you want the DS2072 to perform an FFT on it. Using the DISPLAY data to produce FFT power spectra is a poor choice when I have shown the information IS PRESENT AND IS ACCURATE in the raw data.
I estimate about a factor of 20 at least improvement is possible with using the raw data.

I suspect it would take a long time for the DS2072 to produce FFTs from (portions of the) raw data compared with the display data since the latter is already scaled and processed in preparation for drawing on the screen. So the choice was made on that basis by Rigol.

[tinhead]

The Rigol 'Center' is Not the Center frequency of the Scanned span as in a Spectrum Analyzer.
For Rigol DSOs (D2000,DS4000,DS6000),
The 'Center Freq.' is that Frequency that is set at the Center of the display.

When the center of screen is marked as "center", then on left and right side there are exact the same amount of DIVs. As long the FFT is from one edge of the screen to the opposite edge, the center marking is center of full span, a typical center frequency. When you move the FFT to left or right direction then of course that "center" marking if showing the actual frequency on the center line location, so when you move to max. right it will be 0 (or whatever is set to start freq) and when you move to left the full span freq. So whatever you set as DIV, the center marking (again, when position not changed) is always the center frquency of the span. When you zoom in, still the same situation - as long the FFT has been not moved to right or left direction.

[tinhead]

Here is what My DS2072 shows at the left end of the FFT freq.spectrum  , always 0 HZ
see display 2 (Rigol center =0kHz )

really? Even of your picture on left side there is no zero



but as you said

therefore the display was from 2.65 - 3.35 KHz

and this is exact what i said here (zero to full span or range x to range y, depends on settings):

When the center of screen is marked as "center", then on left and right side there are exact the same amount of DIVs. As long the FFT is from one edge of the screen to the opposite edge, the center marking is center of full span, a typical center frequency. When you move the FFT to left or right direction then of course that "center" marking if showing the actual frequency on the center line location, so when you move to max. right it will be 0 (or whatever is set to start freq) and when you move to left the full span freq. So whatever you set as DIV, the center marking (again, when position not changed) is always the center frquency of the span. When you zoom in, still the same situation - as long the FFT has been not moved to right or left direction.

and the center is always a center of the screen, so when zero to full span the center marker is center frequency, and when range x to range y then it it still center frequency (of the specific range). Only when you move it's not center frequency anymore, which is exactly what it should be (but maybe you expecting something unexpected from Rigol? )

[Teneyes]

and the center is always a center of the screen, so when zero to full span the center marker is center frequency, and when range x to range y then it it still center frequency (of the specific range). Only when you move it's not center frequency anymore, which is exactly what it should be (but maybe you expecting something unexpected from Rigol? )

@Tinhead
Here are more displays to show what the Rigol DSO does ?
The input in all displays is 3KHZ, that is the Carrier signal Peak shown

The displays are shown with the Center at   1k, 2k, 3k, 3k

you sure are making this Blog bigger

[Teneyes]

Hi All
 I am hopeful people can understand this topic and make comments

  To address a question from VE7XEN on the Math Function  Diff()
The manual states:

"Calculate the discrete time differentiate of the selected source.
 You can use differentiate to measure the instantaneous slope of a waveform."

This is somewhat true, but NOT very useful
First it is not the waveform but the display trace that is differentiated
Next the "discrete time " interval is fixed at the sample rate , and not configurable ( delta T)
Next the "instantaneous slope" is always a step in digital sampling resulting in only spikes
Next the scaling is complex to understand.

To demostrate with some displays:
Display 1.  An input of a Triangle signal , should differentiate to a Square wave
                but show ??  5VU

Display 2.  An input of a Triangle signal , should differentiate to a Square wave
                at a Low level (100mV) to show the discrete pulses

Display 3.  An input of a Triangle signal , should differentiate to a Square wave
                at a Lower level (200mV) to show less the discrete pulses

Display 4.  An input of a Triangle signal , should differentiate to a Square wave
                at a even Lower level (500mV) to show a few the discrete pulses that match the
                steps in the displayed traces

Display 5.  An input of a very slow Triangle signal , should differentiate to a Square wave
                at a even Lower level (500mV) to show a few the discrete pulses that match the
                steps in the displayed traces
                Note: the steps are Not from the generator, 
                         the ramping was accurate to be better than 150uV/6ms

Now, I think this implementation of differentiation is simple and Useless i!!
The question I have for members,
What is a better way??
   Use sample data (more than just the 1400 points of the display data
   Allow high res data, when selected On) ?
   Allow adjustable differentiation intervals ?
   Interpolation between calculated points  ; d(V)/d(t)?
   Process calculate points with smoothy, box car average on results?

[tinhead]

What DSO do you Have ? a Tekway??

currently no DSO, but it's not that i forgot already how they work (and i don't mean now Tekway as they new on the market and actually copied what Tektronix is doing) and what they displaying while in FFT.

[Carrington]

Wow with a homemade 1K probe, I have obtained a rise time of 1.25ns on a DS2202.   

[rf-loop]

FFT

wondering a bit about that picture, FFT center is 3kHz (so full span 6kHz) but FFT sample rate 10kSa/s ? That didn't make any sense. Or is that zoomed in and moved to left side?

Here is cheap Owon for around this same.
10kSa/s (original center of course 2.5kHz (0-5kHz)
Then shifted center to 3kHz.
After then zoomed in. (Owon keeps ofd course user adjusted center when zoom in for more narrow span in display)
Signal 3kHz with FM modulation. Mod freq 50Hz.
(Signal produced  by Siglent AWG - so signal itself is far far better than device what show it)




Same but now 300kHz mod FM and modulating freq 5kHz
1MSa/s, shifted for 300kHz to center and then zoomed in.



And then just also for fun.


 

162kHz. First DSP (double sideband) with + and - 3kHz sidebands (3kHz mod)
and last just same with AM (carrier + 3kHz sidebands and 50% mod depth.

Shifted horizontally so that 162kHz center and then zoomed in.
(whole FFT is of course 0-500kHz (1MSa/s)

Only strange is: what is Rigol doing and why? 10kSa/s but full FFT span 0 - ? is it really not 5kHz?

If compare to Owon result... why so big difference? With this resolution it do not see noise floor between 50Hz peaks in two first images.
But about this displayed center, of course "center" is where user have adjusted it. So I can not see any strange there in Rigol for this. Just normal shift-zoom etc. User adjusted as he have want. (between natural limits (but why 6kHz)

[cthree]

It's unfortunate that all of this discussion of the 2000 series scopes is contained in a single 104 page thread.

[Galaxyrise]

This seems oddly reminiscent of trying to convince you that Rigol's High-Res mode produces the same results as everyone else.

I'm probably just inviting more abuse onto myself, but the Rigol High-Res mode is so different from what I expected that I am curious to see comparisons.

How do other scopes (especially the Agilent) handle a 40mVpp 100kHz sine wave at 1ms/div 10mV/div?  Both max memory depth and 1MSa/s.

Here's the Rigol images for comparison:

[Teneyes]

I encountered a mysterious issue when serial decoding a well known 57600 baud serial datastream. The encoding showed me some wrong characters and so I thought maybe the oscillator of the selfmade sending µcontroller device is out of spec. and I tried the "user selectable" baudrate on the DS2072 and at first I used the same baudrate there too, that's 57600. And - I don't know why - when I switched to the user defined baudrate with exactely the same baudrate (57600) the decoding was perfect ! So there seems to be an internal difference between the STANDARD 57600 baud decoding and the USERDEFINED 57600 baud decoding in the DS2072.  Does anybody have any idea or could verify this issue on his Rigol DSO.

Yes, working with Markus,we have confirmed this Bug, isolated it
and we have reported it to Rigol support (add to Bug List??)

Display 1  Shows when the baud rate set by USER=57600 it operates correctly
           There are 13 x  8 bit data  displayed across the display with the baud rate set 

Display 2  Shows when the baud rate set by Rigol=57600 it operates Incorrectly
           Now the only change is the switch from User to Rigol fix Baud rate
           There are Only 9 x  8 bit data blocks displayed across the display
           There are errors of missed data
            Pan right to see setup --->

Display 3  Shows how when the baud rate set by Rigol = 38800 it operates correctly

Display 4  Shows how when the baud rate set by Rigol = 115200 it operates correctly
       

[Wim13]

Showing the baudrate issue , on a different way,

Picture 1, 9600 bd. 1 start bit and 1 stop bit no parity,

scoop on 104 uSec per div is the same as 1 bit per division,
so you can see that the decode (green ) block is 8 bits long, 8 divisions long.


Picture 2, 57600 bd set by user,

scoop on 17.4 uSec, the same again , 1bit per division
set for  8 bits, the green block decodes 8 bits in 8 divisions.


Picture 3, 57600 bd set by Rigol,

scoop still on 17.4 uSec, 1 bit per division
now you see that the green decode block has changed in size... .....
which ofcourse is not correct.

[CodyShaw]

It's unfortunate that all of this discussion of the 2000 series scopes is contained in a single 104 page thread.

Why? I think this whole thread is quite constructive!

In other news, my 2072 just got past US-->Canada customs last night. I hope it comes soon!

[zibadun]

It's unfortunate that all of this discussion of the 2000 series scopes is contained in a single 104 page thread.

Why? I think this whole thread is quite constructive!

In other news, my 2072 just got past US-->Canada customs last night. I hope it comes soon!

it's a problem if you are not following every post. You can miss a block of good posts forever. Or if you are a new user, it's so hard to skim through the entire thread.   happens on other forums also..   I wonder if there is an efficient way to process all this info.  May be the most informative comments should be flagged somehow by readers to make them easier to find. 

[Teneyes]

[ if you are a new user, it's so hard to skim through the entire thread.
  I wonder if there is an efficient way to process all this info.  May be the most informative comments should be flagged somehow by readers to make them easier to find.

For me, I went thru all pages and deleted 5 pages worth of Posts,
where someone has quote my whole post
where I posted an incorrect guess
where It was small talk

Yes most informative comments , could be a separate Blog sort of a Sub BLOGS

Maybe :
     one for Bugs
     one for Tips
     one for Info on:
            Memory Depth
            RECORDING , just point to already RUU thread
            FFT
            MATH
            DECODES
            Aliasing
            Arguments
            Priority votes on Bug fixes
            Hack point to already hack thread
 
  Where would the Table of contents Be

I would be willing to quote and re posts all my Posts, would you? 
         
Who's a tech librarian?,Let's look at who's got the neatest work bench
             

[ve7xen]

A wiki is a good solution for this kind of thing.

I don't have time to maintain one, which tends to be everyone's problem with this kind of thing, but if someone wants to step up and manage the content I am willing to host one.

[Carrington]

Teneyes, ve7xen:

These two ideas are great, and I think that very necessary, given the scale that fortunately is reaching this post.

[EEVblog]

It's unfortunate that all of this discussion of the 2000 series scopes is contained in a single 104 page thread.

What do you suggest instead?
Separate thread for every minute detail that interests you?

[EEVblog]

A wiki is a good solution for this kind of thing.
I don't have time to maintain one, which tends to be everyone's problem with this kind of thing, but if someone wants to step up and manage the content I am willing to host one.

cthree has agreed to set it up and maintain it!