Products > Test Equipment
REVIEW - Rigol DS2072 - First Impressions of the DS2000 series from Rigol
<< < (299/566) > >>
marmad:

--- Quote from: Galaxyrise on July 11, 2013, 03:13:50 pm ---Do you have any picture evidence that the DS2000 is capable of oversampling?  My first couple of attempts at this seemed to indicate otherwise (which is what I was complaining about a dozen pages ago) but I haven't spent the time yet to thoroughly convince myself of it.  If the DS2000 can only process what makes it to sample memory, then the anti-aliasing you want is simply not possible.
--- End quote ---

The technique doesn't require the DSO to ever sample faster than 2GSa/s - it just varies how it decimates those samples at slower time base settings. This could happen between the ADC and sample memory (which is how I think the Agilent does it) or it could happen between sample memory and display memory.
Galaxyrise:

--- Quote from: marmad on July 11, 2013, 04:54:58 pm ---The technique doesn't require the DSO to ever sample faster than 2GSa/s - it just varies how it decimates those samples at slower time base settings.
--- End quote ---
I've never suggested that the DSO sample faster than its max. I haven't seen evidence that the Rigol ever does any logic between ADC and sample memory, even if the current sample rate is 1MSa/s.

--- Quote ---This could happen between the ADC and sample memory (which is how I think the Agilent does it) or it could happen between sample memory and display memory.
--- End quote ---
I'm confused: I thought the anti-aliasing you've been talking about has to happen before writing to sample memory.  How could a sample->display algorithm help the situation in the agilent vs rigol images posted earlier? The presence of a high frequency signal has already been lost.
Teneyes:
Reporting A BUG
on FFT the DSO must maintain the Center frequency selected at the center of the display as you change through span scales
Start with span top (widest to see peak) then narrow span and the display must spread the frequency holding the center frequency at the Center of the Display!!!. see Pic , as only the Scale(FFT) was changed.  And NOT move the selected Peak way off the display, and Making the 'Pissed Off' User constantly  needing to adjust the Center Frequency.  Seem like the Programmers have never worked in Frequency domain

I will forward to RigolNA
ve7xen:
So I posted this a few days ago but I guess it got buried. Anyone have any comments on my posts about the MATH functions back here? https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg257777/#msg257777

Am I using it incorrectly or is it a bug?
marmad:

--- Quote from: Galaxyrise on July 11, 2013, 05:40:47 pm ---I'm confused: I thought the anti-aliasing you've been talking about has to happen before writing to sample memory.  How could a sample->display algorithm help the situation in the agilent vs rigol images posted earlier? The presence of a high frequency signal has already been lost.
--- End quote ---

Ok - a few things to clarify (some or all of which may be obvious):
The anti-aliasing I've been talking about won't solve EVERY aliasing problem - just the majority of them.
Most aliasing on a DSO happens when people use a slower time base setting, thus causing the DSO to use a lower sample rate - thus lowering the effective bandwidth of the DSO.
When you see an aliased waveform on the DSO screen, you should actually be seeing a block of pixels; i.e. the equivalent of a fuzzy band (because the period of the waveform ~<= the pixel-to-pixel time).
During normal sampling (regular time intervals), running an ADC clock at 1MSa/s is the same thing as sampling at 2GSa/s and keeping every 2000th sample (simple decimation) - with either technique you will get aliasing on, for example, a 20MHz sine wave.
OTOH, sampling at 2GSa/s and varying the sample you keep within certain parameters (random decimation) will NOT give you aliasing - because the sub-(beat)-frequencies which can appear due to the regular time intervals between samples will not occur.

The Rigol does NOT have to do this during sampling; it could sample at full speed (2GSa/s) into sample memory - then do random decimation (to simulate the current sampling rate) to display memory. Of course, this wouldn't work for ALL slower sample rates (at some point the memory wouldn't be large enough), but it could work for many slower rates.

Is this clear now?  :)
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod