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

[dpenev]

Hi Guys,

I did some measurements with DS2102 today and the scope overshoot calculation seems strange,
my switching regulator is having huge ringings but definitely they are not not 47%?
Any thoughts.

Best Regards
Dimitar
 

[dpenev]

Oh do they mean 0.47V instead of 47% ?
Dimitar

[TP]

I don't see any transition on screen from which to measure the overshoot.  I thought overshoot was how much a step rise overshoots the final level, i.e. how much a 5V square wave overshoots 5V.  Your trace has no transition, just some ringing on a steady level.

[dpenev]

Hi TP,

Well in the manual it is just written:
"9. Overshoot: the ratio of the difference of the maximum value and top value of the waveform to the amplitude value."
So I have decided it can be generalized for my ringings. But Apparently the documentation is not fully correct and the scope
is searching the positive edge in order to do the calculations. As the name suggests actually

I have confirmed that in case of periodic square wave the Overshoot is showing the value properly.

Thanks
Dimitar

[colinbeeforth]

Hi, on page 44, scummos said:

"Yes, definitely. sin(x)/x interpolation is the "mathematically correct" way to reconstruct a signal, so there isn't really a reasonable alternative"

I have no wish to offend, but must humbly disagree, linear interpolation is a very suitable alternative, either that or LeCroy got it all wrong. (I've owned a 9310M for over 10 years - they got it right!)

The 93xx series scopes use linear interpolation, and maybe others, that I'm unaware of.  It's simple, and warns you clearly when you are at risk of believing the nonsense on the screen.  When an acquired waveform looks spikey (visually very distinctive), there are insufficient samples to make an intelligent guess about the incoming waveform.  Unlike an analogue scope, with any sampling dso, you cannot know what happened to the waveform between samples.  There is insufficient evidence between samples to even guess.

Yeah, you can spout Nyquist and sampling theory, but the honest truth is that between samples, we are left ignorant.  Using sinx/x interpolation, a dso reconstructs sine like curves through the real data points, however, if it draws any line that deviates from a straight line, the dso is guessing at what the input waveform might be.  What's that?  Your cheeks flush with anger, "according to Nyquist..."  The Nyquist criteria demand that for sinx/x reconstruction to be valid, there must not be any sine component exceeding half the sampling frequency.  Now, tell me how you can ensure that difficult requirement.  Yes you say, a totally brick wall filter at half sample rate in the front end.  Show me any scope that has a "Switch Nyquist Filter On" button.  Since the sample rate varies dramatically over the range of timebase settings, the Nyquist filter must shift its corner frequency from a few Hertz to maybe 500MHz - and that has to be brick wall filter so it reduces any sine component more than 1/2 sample rate, and it must recuce it below the minimum discernible level (8 bit= -48dB from adc fullscale).  Nyquist is a fine mathematical concept but <totally irrelevant> to modern dsos.

Show me the Nyquist filter on any dso and I'll accept it's sinx/x interpolation.  The theory works neatly for a theoretical dso, but isn't relevant to any scope on the market today - except perhaps for audio/vibration fft analysers, they often have proper Nyquist filters, and so sinx/x is valid.

A wide range lab or workbench dso can never have a Nyquist filter broad enough to validate sinx/x across its timebase range- it's not impossible, but very hard to build & and impossibly expensive.  Linear interpolation is also somewhat invalid, but so long as you have 10 to 20 samples for one cycle of the highest sine component, it works well enough.  Linear interpolation is also intrinsically safe, since it clearly alerts the user if undersampling occurs - waveforms go spikey.

And to the group member finding noise on the power supply, it looks like there are roughly 3 sinewaves in 20 nS, so that is around 150MHz, a signal like that is very likely to be rf pickup, not in your power supply.  Even a few inches of ground lead will serve as an antenna.  The built in frequency counter saying 8 something MHz is spurious.

Cheers, Colin

[marmad]

I have no wish to offend, but must humbly disagree, linear interpolation is a very suitable alternative, either that or LeCroy got it all wrong. (I've owned a 9310M for over 10 years - they got it right!)

Hi Colin,

Thanks for your post. As discussed in another thread here recently, one annoying thing about Rigol is the lack of written information about exactly what they're doing. They're clearly using sin(x)/x much of the time (when you have 'vectors' chosen - which is what the menu item is called) but perhaps they're using linear interpolation below a certain number of sample points per division? Here are three different images from (under)sampling a 5MHz sine and square wave (~15ns rise time) at 20MHz, 50MHz, and 100MHz. I'm far from an expert on the subject, but I'm not sure if the 20MSa/s image accurately portrays sin(x)/x interpolation.

[marmad]

Take the following with a grain of Rigol salt    but supposedly the new DS2000 firmware is due out by the end of this week. Of course, Rigol has mentioned - then ignored - other release dates, so it might not happen - but the specificity of it makes me think it will be fairly soon.

[orbiter]

Taken with the proverbial grain... But thanks for keeping us up to date anyway Marmad

[EEVblog]

Take the following with a grain of Rigol salt    but supposedly the new DS2000 firmware is due out by the end of this week.

I've heard that every week since before xmas 

[marmad]

I've heard that every week since before xmas 

Oh well, it's the first time Drieg has told me a week; the last date he reported that Rigol told him was around the spring festival (Feb. 10th) - so... well, what can I say? Question your source 

[EV]

 

[colinbeeforth]

Hi marmad,

thanks for posting the pictures.  I see what you mean.  The spikey looking waveform demonstrates what undersampling looks like when using linear interpolation.  Yet other pictures I've seen on this thread demonstrate sinx/x interpolation on the DS2000 series.  It's very hard to understand which interpolation is being used when.

One of the cute things my LeCroy does (amongst many) is whenever the number of data samples per centimetre drops below 10 or so points, each individual data point is highlighted, so you can see what data points the linear interpolation is making its way through.  Without having to press buttons, or interpret numbers, or switch modes, the scope immediately and visually alerts you to the fact that it is close to undersampling.  Many scopes have an option to show dots or vectors.  But if sinx/x keeps the waveform looking rounded and believable, you don't know when to switch to dot mode to check for undersampling.

The lack of solid information in manuals seems to be a common problem with Chinese scopes.  I get the feeling that the Chinese manufacturers are completely paranoid about competition and the theft of their ideas.  They act like they are so fearful of copying that they won't even let their purchaser know how the scope works.  Most of the low cost DSOs I've had the misfortune waste time on are so poor that there's nothing worth stealing!  I'm delighted to see Rigol making  a big leap in construction quality and design with their new scopes.  I hope their development continues.  It's always a question though, when competition drives down prices, can any manufacturer then afford to provide the sort of support and software fixes that such heavily software based  scopes seem to need?  It will be interesting to see how it turns out.

Cheers, Colin

[jpb]

I have a LeCroy WaveJet which only does linear interpolation, there is no Sin(x)/x option, so I'm pleased to see colinbeeforth's posts.

For normal captures I find I don't need interpolation anyway (it may be different when zooming in by a large factor), even at 1nsec a division, if I set the memory depth for 500 points it shows a thousand curves overlayed but as the trigger point is slightly different on each curve the dots are filled in without interpolation being needed. This can also be done for a single curve by turning Equivalent Time capture on.

The above relies on repetitive wave forms but then so does Sin(x)/x interpolation.

The one area where it might be nice is when zooming given that the WaveJet has "only" 500K of memory and not multi megabytes - I've not used the scope enough to know if this is a practical issue or not.

[marmad]

One of the cute things my LeCroy does (amongst many) is whenever the number of data samples per centimetre drops below 10 or so points, each individual data point is highlighted, so you can see what data points the linear interpolation is making its way through.  Without having to press buttons, or interpret numbers, or switch modes, the scope immediately and visually alerts you to the fact that it is close to undersampling.

That's a great idea - and I think it would be fairly easy to implement in a DSO with intensity grading. Maybe I'll try to put it into a future version of the control software I'm writing.

The lack of solid information in manuals seems to be a common problem with Chinese scopes.  I get the feeling that the Chinese manufacturers are completely paranoid about competition and the theft of their ideas.  They act like they are so fearful of copying that they won't even let their purchaser know how the scope works.

Perhaps this is part of the problem, but I get the sense that it also has to do with providing 'extras' (more $ outlay for them) above and beyond what is strictly required to manufacture and sell the item.  The same reason that most (all?) PC software for Chinese-made test equipment is crap.

The one area where it might be nice is when zooming given that the WaveJet has "only" 500K of memory and not multi megabytes - I've not used the scope enough to know if this is a practical issue or not.

I think the other thread discussing this shows that it's definitely a good feature to have when zooming at slower sample rates.

[marmad]

Attached is an unedited and unsorted text file containing all of the SCPI variables (top paragraph) and commands (bottom paragraph) culled from the DS2000 firmware. The reason it's unsorted is because it makes it a bit easier to tell if a command is a sub-command (for example, all of the sub-commands of the :SYSTEM command follow each other, like :SYSTEM:ETIMpedence? [External Trigger impedance])

There is tons of stuff which is undocumented and/or commands that normally belong to the DS4000 series. I've tried only a small percentage of them - and of course, it's unlikely that any of these will unlock hidden features - but you never know. It's interesting to note that the DSO appears to respond to all of the commands - even if it won't let you change the settings. For example, when I query the DSO with a command that belongs to the DS4000:
:CHAN1:IMPedance?
It returns:
OMEG  (which means 1M)
But if I try to change it:
:CHAN1:IMPedance FIFTY
I get an "Invalid Input" message on the DSO screen.

One internal variable I was able to change is another feature which is on the DS4000 - the reference clock. The DS4000 can output the internal 10 MHz sample clock from a BNC connector at the rear panel - or accept an external 10 MHz clock there to synchronize multiple oscilloscopes. The command
:SYST:RCLOCK COUT (or CINT)
seems to change the variable internally on the DS2000 - although, of course, we don't have the BNC connector which brings the output/input from/to the mainboard.

There is lots of interesting stuff here - like the variables named D0 - D15 - clearly meant for an LA module. I've just started studying the file myself - but one thing I noticed quickly is the command WSAVe - which is a command for saving recorded frames. I tried to figure out the syntax to see if I could get it to work (there is a sub-command LOCation - which clearly goes with it) but either I couldn't find the correct syntax or - more likely - it's still unimplemented.

Anyway, check it out - it's very interesting - and please post back here if you find a hidden gem - or manage to get the DSO to do something strange 

[Kaptein QK]

Haha, I think many systems accepts that command!

[wb3fsr]

File with the SCPI variables  and commands (

Not in the File  :SYSTEM:BRICk=on

But it happens

  Teneyes, That's not funny, I live in Brick! Really I do... 

Regards,

PeterV

[John South]

Hi All - I have received the new official release firmware from Rigol today. It seems to fix some bugs and make general operation smoother. I don't currently have a list of changes but will try to find out. I'll be sending Dave a copy today. If you do update you have to follow the below method - Thanks Marmad hope you don't mind me doing a copy and paste.

Ok back to have a play and see what is fixed/changed


You do this by using two hands when booting up - one thumb on the 'Power On' switch - one thumb on the 'Help' button. When you press 'Power On', all of the scope LEDs will light for ONE SECOND - during that brief period, you must PRESS AND LET GO of the 'Help' button. It can be a little tricky, but if it works, bootup will stop before the Rigol logo with the 'SINGLE' button lit (if it doesn't, turn off power and try again until you get it). Then insert the USB stick with the file on it. The CH1 LED will flash as the DSO loads the file.

Once updating is finished, several of the LEDs will light up - and all flashing, etc. will stop. That's it! Remove the USB stick and reboot, and check your firmware version using the method listed above

[marmad]

Hi All - I have received the new official release firmware from Rigol today. It seems to fix some bugs and make general operation smoother. I don't currently have a list of changes but will try to find out. I'll be sending Dave a copy today. If you do update you have to follow the below method - Thanks Marmad hope you don't mind me doing a copy and paste.

Good to hear, John - Thanks for the post!    I'm glad the info that I got from Petr (drieg) about the impending release was accurate. Personally, my main concern is that they've fixed the sample memory reading problem - but I'll be curious how many the bugs listed on the first page of this thread they've managed to get rid of.

[marmad]

I don't currently have a list of changes but will try to find out. I'll be sending Dave a copy today. If you do update you have to follow the below method

BTW, John, is it possible to get a copy of the FW via you - or best we arrange it through our own respective dealers?

[John South]

Hi Marmad - best you get it through your respective dealers in case of any issues caused . If that's not possible let me know and I'm sure something can be arranged.

[marmad]

* NEW FIRMWARE FOR DS2000: FW v.01.00.00.03 *



Over the last couple of months we've been giving Rigol the occasional hard time for being late with the promised firmware update. Well, it's now here - and although, after having tested it for an hour or so, I haven't seen any new features - Rigol appears to have gone down our bug list (from Page 1 of this thread) and killed (most of) them one by one. All credit to Rigol - they have clearly responded to the complaints we've posted here - and though I haven't tested enough to be absolutely sure, I can only find one two remaining bugs from the list that they didn't get yet (Edit: As Dave pointed out - there is also still the update 'bug'; which makes it slightly complicated to update the FW [the GUI menu option doesn't work] - but that wasn't in the original list since it was assumed to be gone) .

Here is the list again from FW v.00.01.00.05 - and what appears to be fixed in FW v.01.00.00.03:

1) The scope appears to first clear the display then restart the sweep whenever moving the waveform vertically, changing the vertical or horizontal scale, moving trigger position, turning on/off channels, etc.

Fixed!! Yay, they are no longer clearing the waveform before moving it horizontally or vertically. It feels much more responsive.

2) The way the scope handles intensity grading in delayed sweep mode needs some work - it doesn't appear to be the same as if you just stop the sweep and zoom in via the horizontal scale.

Fixed

3) If you use the FINE horizontal scale adjust at scales >=20ms (Press -> [Horizontal] Menu -> ScaleAdjust -> Fine), the max/min horizontal trigger position becomes locked to the next lower major division*10/14 - instead of staying 10x/14x of whatever the actual setting is.

Fixed

4) When you turn on tracking cursors (if all cursors off), the measurement window doesn't appear.

Fixed

5) X-Y channels are reversed.

Fixed

6) Self-calibration will automatically expire any trial options currently running.

Not fixed.

7) AUTO routine sometimes fails to latch onto signals.

Unknown - the AUTO routine on every DSO that I've used fails sometimes. In any case, it was never a problem for me, so I'll let someone else test it.

8 ) The 'repeat' (looping) playback of frames recorded in Record Open mode doesn't seem to work correctly (hardly ever).

Fixed

9) There is a major bug involving the transfer of sample memory between the DSO and the PC - which you normally do using VISA and SCPI commands.

Fixed

10) There is a bug involving the reading of WFM files into DSO memory.

Fixed

11) Anti-Aliasing does not return to ON when the DSO is powered-up, even if the Menu setting shows it as "ON".

Fixed

12) A bug confined to the menu selection of Channel 1 = ON and Trigger = External keeps the sample rate stuck at 1G SA/s (instead of raising to 2G Sa/s - as it should be).

Fixed

13) When using both channels and attempting to read 7MB (or 28MB) sample depths out of the scope, the DSO transfers the wrong number of bytes (something 'random' between 6.9 - 7MB (or 27 - 28MB)).

Not fixed.

Good job, Rigol! Now, can you please add Save/Load for Recorded Frames and some other new features? 

[drieg]

Finally I got it too!
Good to hear, that the time and effort invested into reporting/confirming this buglist to/with Rigol yielded results

[EV]

Congrats Marmad! This is very good result, if only one bug is not corrected! 

[EEVblog]

Here is the list again from FW v.00.01.00.05 - and what appears to be fixed in FW v.01.00.00.03:

Nice work! 
But what the heck are Rigol doing with their serial number system, can it get any more confusing?