-
As someone waiting for the 1000Z to be back in stock, who finds the 1052 terribly noisy, it bothers me to hear the fan is loud. What size fan is inside and is it plausable that I will be able to mount a bigger and/or better fan inside?
-
As someone waiting for the 1000Z to be back in stock, who finds the 1052 terribly noisy, it bothers me to hear the fan is loud. What size fan is inside and is it plausable that I will be able to mount a bigger and/or better fan inside?
I wouldn't worry about it too much. The 1000Z is reasonably quiet (about 54-55dB in front of the scope - whicy by the way is very similar to a DS2000 I also measured). If you want loud, try a Tektronix analog scope (on the order of 61dB in front of the scope and 69dB on the side next to the vent.) I would be surprised if you don't like the 1000Z a bunch. Overall, Rigol did a great job. -
I would be surprised if you don't like the 1000Z a bunch. Overall, Rigol did a great job.
Except for soldering encoders. Don't get me wrong, it's a great scope, like it, and would buy again, but the encoders (the small ones for V and H position) are horribly off-axis. -
As someone waiting for the 1000Z to be back in stock, who finds the 1052 terribly noisy, it bothers me to hear the fan is loud. What size fan is inside and is it plausable that I will be able to mount a bigger and/or better fan inside?
You can listen to it in the video I posted, though that's probably not much help. It's louder than any other piece of electronics I own - any of my computers, DVR, cable TV box, etc. I'd expected the 1074Z to be similarly quiet to those, so I was disappointed by that. But on an absolute scale I wouldn't say it's "loud", just more like "noticeable". It's like the noise level of a typical mid-tower PC from 5-10 years ago. -
You can listen to it in the video I posted, though that's probably not much help. It's louder than any other piece of electronics I own - any of my computers, DVR, cable TV box, etc. I'd expected the 1074Z to be similarly quiet to those, so I was disappointed by that. But on an absolute scale I wouldn't say it's "loud", just more like "noticeable". It's like the noise level of a typical mid-tower PC from 5-10 years ago.
I thought that was a really excellent review, particular nice to see when you drilled down through the long-memory capture. Just out of curiousness, at the given data-speed, how much SPI data are you capturing at 200ms/div?
Completely agree btw. about the big lack of scopes in the mid-range, which is also why the 1074Z is on my TO-GET list after Christmas. If the fan is always on and sounding like on the 1052E, I will definitely try to add some temperature control to the fan or replace if with a high quality Papst or similar. -
As someone waiting for the 1000Z to be back in stock, who finds the 1052 terribly noisy, it bothers me to hear the fan is loud. What size fan is inside and is it plausable that I will be able to mount a bigger and/or better fan inside?
You can listen to it in the video I posted, though that's probably not much help. It's louder than any other piece of electronics I own - any of my computers, DVR, cable TV box, etc. I'd expected the 1074Z to be similarly quiet to those, so I was disappointed by that. But on an absolute scale I wouldn't say it's "loud", just more like "noticeable". It's like the noise level of a typical mid-tower PC from 5-10 years ago.
Right, I think "noticeable" is a good description rather than "loud". IMO, the 1000Z is not really loud in absolute terms but it's not silent like a fanless piece of equipment. Just as a frame of reference, where I measured the DS1000 and also the DS2000 to both be about 55dB in front of the scopes (these were specific units in a particular room with other gear and ambient noise, YMMV) I also have a several year old mid/full size chassis PC that is about 50dB in front of the PC and a similarly sized server that is about 60dB in front of the server (plus the Tek analog scope at 61dB in front of the scope and 69dB at the vent). So it's somewhat relative to what you are accustomed to hearing. -
Alrighty. Sorry for the long delay, and no, I was too lazy to do the serial video, so I did one highlighting the Anti Aliasing and waveform capture rate, with some random commentary thrown in.
Enjoy
http://youtu.be/bc49tgS3JpA
Note, as of this time, the video has not been uploaded yet. My internets been acting like a dog and this is a 1080P video for your viewing pleasure. Please do not tear me apart. -
Alrighty. Sorry for the long delay, and no, I was too lazy to do the serial video, so I did one highlighting the Anti Aliasing and waveform capture rate, with some random commentary thrown in.
When you're measuring your waveform update rate and change the memory depth to 12M, the rate drops to ~41 waveforms a second and you say, 'God! It's terrible'.
At that moment, the Rigol is sampling at 500MSa/s - so 2ns per sample. In order to fill 12M of memory, it takes 24 milliseconds. What is the maximum number of times in a second any sampling device in the world could capture 24ms of time?
1 / .024 = 41.666.
So in fact, it's not terrible at all - it's almost perfect given the memory size. -
I did some calculations after and realized the same thing. I'm not really familiar with the wfm/s spec, and probably should do some more research next time. Oops.Alrighty. Sorry for the long delay, and no, I was too lazy to do the serial video, so I did one highlighting the Anti Aliasing and waveform capture rate, with some random commentary thrown in.
When you're measuring your waveform update rate and change the memory depth to 12M, the rate drops to ~41 waveforms a second and you say, 'God! It's terrible'.
At that moment, the Rigol is sampling at 500MSa/s - so 2ns per sample. In order to fill 12M of memory, it takes 24 milliseconds. What is the maximum number of times in a second any sampling device in the world could capture 24ms of time?
1 / .024 = 41.666.
So in fact, it's not terrible at all - it's almost perfect given the memory size. -
hi echen1024.. nice videos!
At that moment, the Rigol is sampling at 500MSa/s - so 2ns per sample. In order to fill 12M of memory, it takes 24 milliseconds. What is the maximum number of times in a second any sampling device in the world could capture 24ms of time?
1 / .024 = 41.666.
So in fact, it's not terrible at all - it's almost perfect given the memory size.
I've always thought there needs to be a change in the way they do this. The problem is that they sample at the chosen rate, filling the memory buffer (takes 24ms) then when they are finished they update the screen (can be done approx. 40 per second) ... but the screen is often zoomed in to a small portion of the entire capture buffer, and this zoomed in area could be updated much, much faster and at the same time.
They just need to sample continuously into the 24M sample buffer; 'trigger' should be a display control, sliding the view window over the samples, forward in time, and stopping when a trigger matches, and displaying the really small portion of the sample memory that fits into the graticule at that trigger point. Triggering should not necessarily be something that controls when a sample is taken (although this is useful too). In my view, sampling should be continuous, not-triggered, and the 24Meg sample buffer is circular, and the display is merely a triggered viewport into the sample memory. It is sliding across the samples in real-time and checking the samples for a trigger match... the trigger level is used to center the viewport on a matching point in the sample memory, then the (very small) display window is updated, and moved on to the next sample, looking for another trigger match..
5 (standard), or 6 (widescreen) horizontal divisions on either side of the center line (10 or 12 total divisions) at 5ns/div means only 50ns or 60ns of time sampled data needs to be taken from the sample buffer and displayed; you could theoretically update that much data 20 million times per second (not realistic, I know, because you can't draw it that fast)... but you could guarantee at least 100,000 waveform updates per second this way. You would be able to stop sampling anytime and scroll around in the buffer. Sampling data and displaying that data should be two separate functions of the scope.. most scopes are full or DSP's and FPGAs, yet still put those two functions in a sequential lockstep.
Maybe that's how the big guys get the huge waveform updates per second. it just seems like it should be the only way it is done (or least, the default way)
-
I got nice, new, 6500k lights installed today. No more ripe mango colors.
-
I've always thought there needs to be a change in the way they do this. The problem is that they sample at the chosen rate, filling the memory buffer (takes 24ms) then when they are finished they update the screen (can be done approx. 40 per second)
@codeboy2k: Maybe you're confusing screen refreshing (which happens perhaps a maximum of 50 times per second on any DSO) with updating the intensity buffer (which can happen thousands of times per second). As shown in the video, when the memory size is reduced, the Rigol is updating the intensity buffer much faster - although the screen refreshing happens at the same rate as always.QuoteThey just need to sample continuously into the 24M sample buffer;
Sampling continuously into a 24M buffer @ 2GSa/s means a maximum of 83 new waveforms per second. There is nothing you can do to increase that number artificially.Quote5 (standard), or 6 (widescreen) horizontal divisions on either side of the center line (10 or 12 total divisions) at 5ns/div means only 50ns or 60ns of time sampled data needs to be taken from the sample buffer and displayed; you could theoretically update that much data 20 million times per second (not realistic, I know, because you can't draw it that fast)... but you could guarantee at least 100,000 waveform updates per second this way.
100k waveforms per second means 100k different (i.e. newly sampled) waveforms per second - sampling continuously into 24M would never allow that many new waveforms - ergo, the sample size has to be reduced.QuoteMaybe that's how the big guys get the huge waveform updates per second. it just seems like it should be the only way it is done (or least, the default way)
Perhaps you mean the following: it seems obvious that the way Agilent achieves it's high update rates with a fixed memory size at small time bases is by sampling and updating only the visible screen area (e.g. 50ns of time) - until you STOP the DSO, at which time it fills the entire 1/2/4M buffer for scrolling/viewing.
But Rigol allows user-selectable memory sizes, so you control the trade-off between memory size and waveform update rate. Not as efficient - but more user control. -
It probably is the reason why Rigol allows user selectable memory sizes. One can pick the trade off between memory size and wfms/sec. It probably is not economical to continuously guarantee a high wfm update rate across all spectrums, since there is the time needed 1GS/s to fill up the memory buffer at a specific point. The only simple way to increase it is to increase sampling rate.
-
When you're measuring your waveform update rate and change the memory depth to 12M, the rate drops to ~41 waveforms a second and you say, 'God! It's terrible'.
Considering this it seems that 'dead' time (the time data is dropped), would be a more useful measure than wfm.
At that moment, the Rigol is sampling at 500MSa/s - so 2ns per sample. In order to fill 12M of memory, it takes 24 milliseconds. What is the maximum number of times in a second any sampling device in the world could capture 24ms of time?
1 / .024 = 41.666.
So in fact, it's not terrible at all - it's almost perfect given the memory size. -
Considering this it seems that 'dead' time (the time data is dropped), would be a more useful measure than wfm.
Ahh... but then you get into the question of whether you consider non-acquisition time as the dead time (like Rohde & Schwarz - à la 'real') or non-display time as the dead time (like Agilent - à la 'effective'): -
If the display window could be changed such that the entire acquisition is visible (either by reducing the acquisition memory or zooming out till the point the entire acquisition is displayed), I'd say "real" dead-time. If that isn't possible than I'd say "effective" dead-time.
The bottom line is that I'd like to know what the chances are I'm going to see a randomly occurring glitch on the screen. WFM figures are nice for marketing material; but seem clumsy when it is fully specified for all possible settings, and pretty close to useless if it is not fully specified. -
The bottom line is that I'd like to know what the chances are I'm going to see a randomly occurring glitch on the screen. WFM figures are nice for marketing material; but seem clumsy when it is fully specified for all possible settings, and pretty close to useless if it is not fully specified.
Sure, I agree. The waveforms per second or preferably, the blind time, could always be displayed on the screen (along with sample size and rate). I assume it isn't done because the blind time is actually quite huge at smaller time base settings - even on faster update rate DSOs - as shown in this chart of the Rigol DS2000:
But the odds of seeing a randomly-occurring glitch would depend on the frequency of the glitch - which is impossible to know beforehand if it's random. Plus, even if the odds say that the average test time for catching a once per second repeating signal fault @ 10ns/div (with a probability of 99.9%) is one hour - you still might catch it in one second.
-
IMHO they wouldn't have to fill the memory first and then display. In my unfinished USB scope design I split the data stream from the ADCs into one which went to the display and re-triggered as soon as the display is full (nearly killing any dead time) and one stream which went to the memory. During acquisition it would show min/max of many acquisitions (didn't got to intensity grading) and in offline mode it would allow browsing through the memory (up to several Gpts of data).
-
IMHO they wouldn't have to fill the memory first and then display. In my unfinished USB scope design I split the data stream from the ADCs into one which went to the display and re-triggered as soon as the display is full (nearly killing any dead time) and one stream which went to the memory. During acquisition it would show min/max of many acquisitions (didn't got to intensity grading) and in offline mode it would allow browsing through the memory (up to several Gpts of data).
There has to be some translation between the captured samples and the display - and unless you're only sampling at exactly the rate of (1 div / pixels in div), also some decimation. But if you're capturing only one sample per pixel, it means it would be impossible to zoom in for more detail when stopped.
Not only that, but you would surely reach the refresh limits of the LCD (which would be rather low compared to fast waveform update rates) - one of the issues intensity grading is specifically designed to avoid. -
You are thinking too much in black and white. Realtime mode and browsing through data are two different ways of looking at a signal. Treat them as such. In realtime mode you want to show as much of the signal as possible so show as much data as possible (synchronised by the trigger) either by showing min/max (peak detect) or persistance (intensity grading). In offline mode (scope stopped) you want to browse through the data. In that mode you don't want intensity grading, just the samples and/or peak-detect.
-
You are thinking too much in black and white. Realtime mode and browsing through data are two different ways of looking at a signal. Treat them as such. In realtime mode you want to show as much of the signal as possible so show as much data as possible (synchronised by the trigger) either by showing min/max (peak detect) or persistance (intensity grading). In offline mode (scope stopped) you want to browse through the data. In that mode you don't want intensity grading, just the samples and/or peak-detect.
Actually, it sounds to me like you're thinking in black and white (real time vs browsing). I often stop my DSO after capturing samples in real time, and then look more closely (i.e. zoom in) at the samples. I also capture segments (real time) and then examine them (browse).
In any case, whatever you believe are the correct ways to look at a signal, LCD displays have a minimum response time; i.e. the maximum number of times that data can be altered on the display per second. Streaming directly to the display would severely limit the maximum waveform update rate to a much lower number then any decently-fast intensity-grading DSO using sample memory and an intensity buffer. The blind times would be worse at any time base lower than 1ms or so (depending on the response time of the LCD). -
I just received my DS1074Z today. I won't have much chance to play with it until after Christmas, but I unboxed it, powered it up, calibrated all 4 probes at 10x, and then poked through the menus and probed a signal or two.
First impression.. it's a solid piece of gear.. even more weight to it than I expected. I was using it in my kitchen initially, then moved it down to the garage workbench. In neither place did the fan make enough noise for me to even notice. Now, this IS my first scope so I have nothing to compare it to, but it was impressively quiet for my expectations.
The display is gorgeous. I'm sure the gradient display on the DS2000 series is better, but I think Rigol did a hell of a nice job with the 64-level gradient or whatever this model supports. So much bang for the buck, especially for a hobbyist like myself. I can't wait to probe some more interesting signals with this device. I think I'll try my hand at a basic function generator so I can visualize some stuff.. I have a schematic for one based on a quad op-amp IC, 4 diodes, 2 caps, and some resistors. -
I just received my DS1074Z today. I won't have much chance to play with it until after Christmas, but I unboxed it, powered it up, calibrated all 4 probes at 10x, and then poked through the menus and probed a signal or two.
Oh god. The self-cal takes FOREVER! My old Siglent took less than a minute. This thing takes 10.
First impression.. it's a solid piece of gear.. even more weight to it than I expected. I was using it in my kitchen initially, then moved it down to the garage workbench. In neither place did the fan make enough noise for me to even notice. Now, this IS my first scope so I have nothing to compare it to, but it was impressively quiet for my expectations.
The display is gorgeous. I'm sure the gradient display on the DS2000 series is better, but I think Rigol did a hell of a nice job with the 64-level gradient or whatever this model supports. So much bang for the buck, especially for a hobbyist like myself. I can't wait to probe some more interesting signals with this device. I think I'll try my hand at a basic function generator so I can visualize some stuff.. I have a schematic for one based on a quad op-amp IC, 4 diodes, 2 caps, and some resistors. -
IMHO Rigol made a real killer with the DS1000Z series. I was looking for a used 100MHz TDS3000 series scope to have a portable scope but the DS1000Z appears to be better in so many ways that buying an 'old' TDS3000 seems like a waste of money. I think we may see prices for second hand scopes drop really fast.
@marmad: forget about the LCD refreshrate. Its not relevant. If the software updates the screen 5 times per second its more than enough. -
IMHO Rigol made a real killer with the DS1000Z series. I was looking for a used 100MHz TDS3000 series scope to have a portable scope but the DS1000Z appears to be better in so many ways that buying an 'old' TDS3000 seems like a waste of money. I think we may see prices for second hand scopes drop really fast.
I must admit, for value, this is a killer scope. Only thing I can think of is the Tek construction is probably nicer.
@marmad: forget about the LCD refreshrate. Its not relevant. If the software updates the screen 5 times per second its more than enough.