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:
(Original post:
https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg262688/#msg262688)
From what I can see, there is fw bug there. The 40mV of wave doesn't cover four divisions neither at high or low resolution.
Some captures from Owon SDS7102. No aliasing at all, right trigger appearing.
From what I can see, there is fw bug there. The 40mV of wave doesn't cover four divisions neither at high or low resolution.
Those were both high res. The difference was the sample rate. When I used "Normal" instead of "High Res" Acquisiton, the waveform was fine. There's some kind of aliasing going on, taking the 40mV, 100kHz signal and displaying it (at 1GSa/s) as 2mV, 2.33kHz, or (at 1MSa/s) as 10mV, 12kHz. Stopping the scope and zooming in, the 100kHz, 40mV waveform will be there: I'm pretty sure the Ultravision "High Res" happens when converting the acquired samples to display and does not affect acquisition at all.
Thanks for providing another comparison! In your Owon example, is that with high res acquisition? What happens when you drop the sample rate down to 1MSa/s?
I see now but I am not familiar with the menu and philosophy of Rigol.
The Owon has a different firmware philosophy. It doesn't follow the logical of Normal and High Resolution (at least not in this way).
There is the Acquisition Mode (Normal, Peak and Average) and the Memory Length (1k, 10k, 100k, 1M, 10M). You set the Acquis. Mode and Length of Memory and the Sampling is automatic according to Time base. If you see at the first capture with 1ms, it automaticaly sets 500MS/sec but at the second that is in stop mode (not running) with 5us Time base the Sampling sets to 1GS/sec.
I hope to don't confuse you, now...
Self Calibration
How well does the 'Self-Cal' work for your DS2000?For No input , after a 'Self-Cal' ,
I seem to consistently get:
Channel 1 -125uV
Channel 2 25uV
Looks like Chan. 2 is better
Note: 20MHz BW , 1msdiv 128 Averaging
By "no input" do you mean grounded or floating?
By "no input" do you mean grounded or floating?
Floating or 50 Ohm terminations , not much different
most is RF interference + Noise inside
more to show the Display offset after Cali.
Temperature has effect.
after 36 hours
Chan. 1 20uV better
and
Chan. 2 +130uV off
Ordered my DS2072 from Pete at TEquipment.net. Received the EEVblog discount when I mentioned I heard of them from this place. Really helpful and prompt order processing and shipment. Hope to see it Monday or Tuesday next week... Can't wait to play around with the scope, based on all I have read here.
I ordered my DS2072 on September 16 from TEquipment, it shipped on the 17th, and was received on the 23rd. Great service and prompt shipping!
So, my unit shows the following:
Serial - DS2A1534xxxxxx
S/W version - 00.01.01
H/W version - 2.0
It looks like it was manufactured between August 19 and the 25th. The RP3300A (10x) probes were included.
Used RiGen version 2b1 on an old XP netbook. It took only a minute and worked great to unlock all the options. Thanks to EEVblog for all the info!
Now, for the life of me, I cannot get the extended system info, even before the "upgrade". I read marmad's instructions on the first page of this thread, but just can't get the right keystroke combination. Did something change?
With the patient guidance and assistance of Teneyes, I was *finally* able to obtain the extra system information of my DS2072. I won't admit here, in public, the stupid thing I did along the way.
Here's how it reads:
Model: DS2202 (after the hack found here)
Serial: DS2A15340xxxx
Software version: 00.01.01.00.02
Hardware version: 1.0.2.0.0
FPGA version:
SPU 03.01.05
WPU 00.06.05
CCU 12.29.00
MCU 00.05
Finally i have a Rigol DS2072
My system information are:
Model: DS2072
Serial: DS2A15320xxxx
Software version: 00.01.01.00.02
Hardware version: 1.0.2.0.0
FPGA version:
SPU 03.01.05
WPU 00.06.05
CCU 12.29.00
MCU 00.05
Calibration date: 15-Aug-2013
Probe: Rigol RP3300A - Fixed 10:1 Probe
DS2072 here too, let's to the point..
Model: 2202 (after hack)
Serial: DS2A15350XXXX
Software version: 00.01.01.00.02
Hardware version: 1.0.2.0.0
FPGA version:
SPU: 03.01.05
WPU: 00.06.05
CCU: 12.29.00
MCU: 02.12
I wanna do test with others keygens and did wanna know how to do for uninstall the current hack ?
Thanks.
Hey guys, a pretty insignificant question that should be easy to answer, and I don't think it really deserves it's own thread.
Is there any way to simply press a button and have what ever channel you are using to bring itself to the centre of the screen? It's just a PITA to have to manually scroll the 5 volts or so up to where the trace is when I go from 5V/div to 10mV/div.
thanks
-kizzap
kizzap, try pushing the knob you are rotating.
kizzap, try pushing the knob you are rotating.
Pushing the knob I am turning (the smaller knob for the channel) puts zero volts onto the centre of the
horizontal vertical division. Maybe I need to change a setting somewhere.
-kizzap
edit:fixed mistake
Set the coupling to AC mode.
Set the coupling to AC mode.
Perfect! Thankyou from a Oscilloscope noob.
-kizzap
Pushing the knob I am turning (the smaller knob for the channel) puts zero volts onto the centre of the horizontal vertical division. Maybe I need to change a setting somewhere.
For when DC coupling is important, (from memory) there is a setting in the Utility->System menu called "VerticalExp" which is "Ground" by default. I use "Center". With it set to Center, whatever is in the center of the screen stays there as I change the vertical resolution. So say I want to watch a 5V signal. I start at 2V/div, spin the little knob to get the 5V signal on the center graticule, then start turning the big knob to zoom in, making small adjustments to the little knob as needed. There is a limit to how far you can zoom in this way. You can zoom in more with a 10x probe than with a 1x probe (since the maximum offset doesn't get scaled.) Getting the signal centered this way takes hardly any time at all, though it's certainly not quite as easy as pressing a single button.
I've been doing this a lot lately, as I'm looking at small, low frequency stuff (which would be lost in the noise with ac coupling), putting the scope into roll mode at like 2s/div and watching the trace go by.
Pushing the knob I am turning (the smaller knob for the channel) puts zero volts onto the centre of the horizontal vertical division. Maybe I need to change a setting somewhere.
For when DC coupling is important, (from memory) there is a setting in the Utility->System menu called "VerticalExp" which is "Ground" by default. I use "Center". With it set to Center, whatever is in the center of the screen stays there as I change the vertical resolution. So say I want to watch a 5V signal. I start at 2V/div, spin the little knob to get the 5V signal on the center graticule, then start turning the big knob to zoom in, making small adjustments to the little knob as needed. There is a limit to how far you can zoom in this way. You can zoom in more with a 10x probe than with a 1x probe (since the maximum offset doesn't get scaled.) Getting the signal centered this way takes hardly any time at all, though it's certainly not quite as easy as pressing a single button.
I've been doing this a lot lately, as I'm looking at small, low frequency stuff (which would be lost in the noise with ac coupling), putting the scope into roll mode at like 2s/div and watching the trace go by.

Exactly what I was after, I am mucking around with a power supply design, testing output ripple which you do kinda need to know in relation with the output voltage.
As an aside note, I found that using AC coupling, the ripple existed between -3 and -10mV, as in not symetric about "0" Volts. I'm assuming that this is to be expected?
Last January, marmad wrote:
How could BMPs be faster than PNGs? They are often ~100x bigger - and writing to an external device usually requires more time than processing - although I can't say I've actually timed saving BMPs on the DS2000. Also, I don't know if the brand of USB stick you're using (or FW 01.00.02) affects save/transfer rates - but my timed speeds are:
My Rigol takes ~15 seconds to write a PNG file to a USB stick.
This isn't quite accurate. Your 15 secs is the time to first convert the BMP to a PNG internally, THEN write it to USB. As you correctly pointed out, PNGs are vastly smaller, and would thus write out much more quickly.
The Rigol UltraVision Utilities take ~2.3 seconds using USB to transfer, convert & save a BMP (all bitmap transfers from the DSO are BMP - conversion to other formats is handled by RUU).
That implies the actual data transfer rate over USB is in excess of 490 kB/sec (since a bit of that 2.3 sec is used on the PC side for conversion from BMP to PNG). That's assuming the images are 24-bits deep (x800 x480, or 1125 kB each). Of course, writing to a USB stick may be a bit slower, or a lot slower, depending on the stick. But if you did write a screen image out in BMP format, and timed it, I suspect you'd find it would be much less than 15 secs.
Since the actual transfer rate would be the same in both cases (using the same stick), and the sizes of the PNG and BMP are both known, you could then calculate the separate contributions from transfers and BMP conversions. (First factor out the fixed transfer rate, then determine the conversion overhead.)
@Mark_O , I find using RUU just great , capture DSO data to files quickly on my PC then quicky forward to reports, E-mail.
Also RUU captures the Menu so the pictures explains the Setup
I find using RUU just great , capture DSO data to files quickly on my PC then quicky forward to reports, E-mail.
Also RUU captures the Menu so the pictures explains the Setup
Thanks, Teneyes. Does RUU create the stacked menus on the side, or was that your composite?
Those were both high res. The difference was the sample rate. When I used "Normal" instead of "High Res" Acquisiton, the waveform was fine. There's some kind of aliasing going on, taking the 40mV, 100kHz signal and displaying it (at 1GSa/s) as 2mV, 2.33kHz, or (at 1MSa/s) as 10mV, 12kHz. Stopping the scope and zooming in, the 100kHz, 40mV waveform will be there: I'm pretty sure the Ultravision "High Res" happens when converting the acquired samples to display and does not affect acquisition at all.
Interesting, I see it's the same with the DS2000. I've come to a similar conclusion about High Res acquisition mode in my experiments with the DS1000Z -
https://www.eevblog.com/forum/blog/eevblog-522-rigol-ds1000z-oscilloscope-quick-look/msg331537/#msg331537I feel Rigol are cheating somewhat. Instead of oversampling and filtering at acquisition time they are simply doing it as a math operation at display rendering time. This means it further low-pass filters the traces before displaying them. So, not actually an acquisition mode at all.

The DS4000 better not have the same flaw. It's got a price tag that warrants this done properly.
Interesting, I see it's the same with the DS2000. I've come to a similar conclusion about High Res acquisition mode in my experiments with the DS1000Z
This was already discussed in-depth in this thread back around
this post.
I feel Rigol are cheating somewhat. Instead of oversampling and filtering at acquisition time they are simply doing it as a math operation at display rendering time. This means it further low-pass filters the traces before displaying them. So, not actually an acquisition mode at all.
Cheating compared to who? From the material I've read, at least both Agilent and Tektronix (and perhaps others) do it the same way. This just seems like another case of a feature not working the way that
you expected (or prefer) that it worked.
To quote from the Agilent DSO-3000X Users Guide:
"High Resolution mode averages sequential sample points within the same acquisition. An extra bit of vertical resolution is produced for every factor of 2 averages....
The number of extra bits of vertical resolution is dependent on the time per division setting (sweep speed) of the oscilloscope. The slower the time/div setting, the greater the number of samples that are averaged together for each display point...
High Resolution mode limits the oscilloscope's real- time bandwidth because it effectively acts like a low-pass filter."So yes, just like other manufacturers' implementations of High Resolution mode, Rigol's implementation acts exactly the same way - and will filter the waveform (and cause anti-aliasing if the effective sample rate is reduced too far for the incoming signal).
"within the same acquisition" means oversampling. Oversampling is done at acquisition time before storing each high-res sample. Yes there is a filtering effect, but this is firstly applied to the "oversampled" data rather than the final trace samples. How much the filter affects the trace samples is often definable.
Agilent have done it correctly, unlike Rigol.