Products > Test Equipment
REVIEW - Rigol DS2072 - First Impressions of the DS2000 series from Rigol
marmad:
--- Quote from: evanh on November 21, 2013, 07:55:45 am ---As the commentator says right at the start...
--- End quote ---
By commentator, do you mean Dave - the owner and operator of this forum and EEVBlog? ;D
Anyway... back to measured data:
I did a more precise measurement of the BWs of the DS2000 - and came up with the following table comparing the DSO-2000X and DS2000 High Res implementations:
Rigol DS2000 series Agilent DSO-2000X series (based on Svuppe's data)
Time base BW (-3dB) Eff.SR Bytes Averaged Eff.Bits BW (-3dB) Eff.SR Bytes Averaged Eff.Bits
100ms/div 429Hz 250kHz 256 bytes 12 bits ?
50ms/div 859Hz 500kHz 256 bytes 12 bits ?
20ms/div 2.1kHz 1.25MHz 256 bytes 12 bits ?
10ms/div 4.3kHz 2.5MHz 256 bytes 12 bits 34kHz 25MHz ~325 bytes 12 bits
5ms/div 8.6kHz 5MHz 256 bytes 12 bits 67.87kHz 50MHz ~325 bytes 12 bits
2ms/div 21.5kHz 12.5MHz 256 bytes 12 bits 169.6kHz 125MHz ~325 bytes 12 bits
1ms/div 42.9kHz 25MHz 256 bytes 12 bits 339kHz 250MHz ~325 bytes 12 bits
500us/div 85.9kHz 50MHz 256 bytes 12 bits 676.7kHz 500MHz ~325 bytes 12 bits
200us/div 171.6kHz 100MHz 256 bytes 12 bits 1.689MHz 1GHz ~260 bytes 12 bits
100us/div 343kHz 200MHz 256 bytes 12 bits 3.364MHz 2GHz ~260 bytes 12 bits
50us/div 686kHz 500MHz 320 bytes 12 bits 6.704MHz 2GHz ~130 bytes 11 bits
20us/div 1.37MHz 1GHz 320 bytes 12 bits 16.87MHz 2GHz ~52 bytes 10 bits
10us/div 2.75MHz 2GHz 320 bytes 12 bits ?
5us/div 5.5MHz 2GHz 160 bytes 11 bits ?
2us/div 13.75MHz 2GHz 64 bytes 11 bits ?
1us/div 27.5MHz 2GHz 32 bytes 10 bits ?
500ns/div 55MHz 2GHz 16 bytes 10 bits ?
Hydrawerk:
At DSOX2000 everything is automatic, LOL. You cannot set acquisition length, sin(x)/x interpolation, or vectors / dots. :--
marmad:
Added the following table to the first post in this thread:
Updated High Res bandwidth table here.
Carrington:
--- Quote from: marmad on November 21, 2013, 11:47:02 am ---Added the following table to the first post in this thread:
--- End quote ---
Perfect, I keep a copy, for my personal collection.
Thanks. ;)
marmad:
--- Quote from: Galaxyrise on November 20, 2013, 04:29:23 am ---I had assumed that the raw samples were written to segmented memory, which would mean that the scope had to apply the high res algorithm to segmented memory in order for it to work at all in that mode, and thus there was no good reason not to enable changing between normal and high res on recorded data.
--- End quote ---
@Galaxyrise: Maybe the reason you can't switch between Normal and High Res with recorded frames is because the display frames are already "compiled" from the raw samples and stored separately in display memory. That's why the DSO can play them back so quickly. The raw samples are still in sample memory - and can be read out via SCPI - but the DSO doesn't want to alter or change the compiled frames once they're stored.
But I just discovered something quite interesting when you turn on the Analyze mode in Record.
Here is an image of a recorded frame of a 780kHz sine wave @ 200us/div in Normal mode:
Here is an image of a recorded frame of a 780kHz sine wave @ 200us/div in High Res mode. The sine wave falls precisely into the second null point of the stopband filter:
Here is that same frame when in Analyze mode. You can see the filtered display frame above, but the DSO is clearly using the raw samples for the tiny frames below:
If you then Analyze based on Trace - even though the template seems different - you won't get any errors:
OTOH, if you Analyze based on Mask, you will get errors - since the Mask is built from the non-High Res samples below:
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version