DS2000 vs. DS1000Z record, playback, navigate, analyze, mask, etc. ??

[sync]

BTW, one other feature I don't see mentioned in the DS1000Z User Manual is the Measurement History. Does it exist on the DS1000Z?

I didn't found it too. I don't think it has it. Another thing the DS1000Z doesn't have is fine horizontal scale adjustment and the horizontal reference setting.

The DS1000Z is a low cost scope. It's feature limited. But the bang for the buck is astonishing.

[marmad]

Another thing the DS1000Z doesn't have is fine horizontal scale adjustment and the horizontal reference setting.

@sync: On the DS2000, when you push the Horizontal Scale knob, you go to Delayed Sweep (Zoom) - so to get fine scale adjust, you have to go to the Horizontal Menu and manually change the ScaleAdjust setting [Coarse/Fine]. You've checked in the Horizontal Menu?

[sync]

Yes. The horizontal menu has only two settings. Delay mode and time base mode (Y-T, X-Y, roll).

[echen1024]

Honestly though, the Rigol 1000Z series is an immensely powerful scope and you shouldn't complain that the 2000 might be better. Sure, it might, but when you are working with protocols like SPI, you will want a 1000Z.

[marmad]

Honestly though, the Rigol 1000Z series is an immensely powerful scope and you shouldn't complain that the 2000 might be better. Sure, it might, but when you are working with protocols like SPI, you will want a 1000Z.

I don't think Electro Fan is 'complaining'- I think he's trying to decide which DSO fits his needs (or future requirements) better. And it's not a question of "might be better" - the DS2000 is definitely a more feature-laden DSO - and if you don't need 4 channels (and I don't), it's a better choice.

And BTW, people have been using and debugging SPI implementations long before protocol decoding was available on cheap DSOs.

[echen1024]

Honestly though, the Rigol 1000Z series is an immensely powerful scope and you shouldn't complain that the 2000 might be better. Sure, it might, but when you are working with protocols like SPI, you will want a 1000Z.

I don't think Electro Fan is 'complaining'- I think he's trying to decide which DSO fits his needs (or future requirements) better. And it's not a question of "might be better" - the DS2000 is definitely a more feature-laden DSO - and if you don't need 4 channels (and I don't), it's a better choice.

And BTW, people have been using and debugging SPI implementations long before protocol decoding was available on cheap DSOs.

That is true, however, I have seen a couple others complain about this, and I was just pointing out that the 1000Z is still immensely powerful, and that it still has many features. Yes, I agree, if you are doing I2C or UART only, a 2000 series might be better, but for SPI, you almost need 4 channels on an oscilloscope, or go buy a true logic analyzer.

[eV1Te]

No doubt that the DS2000 is more powerful than DS1000Z (except for the 4 channels though). But also the DS2000 is 60-70 % more expensive than the non arb-waveform generator model of DS1000Z for the same bandwidth.

It is still 20-30 % more expensive than the DS1000Z-S which includes the dual 25 MHz arb-waveform generators.

You can actually get two DS1000Z-S for the same price as one DG1032Z waveform generator and one DS2000 

Thats how I reasoned when I bought my DS1000Z-S, since I needed both a function generator and a new oscilloscope.

[marmad]

But also the DS2000 is 60-70 % more expensive than the non arb-waveform generator model of DS1000Z for the same bandwidth.

But the bandwidth has been hacked on the DS2000 to 200MHz - so if you compare it to the DS1104Z, the price difference is only 23% (and it's cheaper than the DS1104Z-S).

Still, if you really need those extra channels, it's the way to go. 

[Mark_O]

Yes, I've seen that comparison before, and should have mentioned back then that it's obviously incorrect.     The 1000Z display region is 10% smaller than it should be.  Both in width and height.  So the pictorial comparison is misleading, since the area should be >20% larger.

How are you arriving at that conclusion? Do you have any real world data to back that up?

Sorry, you were correct - I went back and checked the file and the DS1000Z size was slightly off. I fixed it and posted the new comparison image.

Thanks!  That's much more useful.  20% more area, and now it's correct.

Both have exactly the same 400 pixels vertically, to cram the horizontal traces in to.  So if you want to view them stacked, rather than overlaid, you have to reduce the amplitude sensitivity just as much on the 2000 as the 1000.

That's true. But there's also the issue of dot pitch. Looking at two equivalently-sized fonts on two screens of the same resolution - but different sizes - does not produce the same perception of detail. If it did, most of us would have a lot more desk space than we do. 

Agreed.  But are you suggesting we didn't always have two or three 27" monitors on our desks?    Also worth noting, when I look at a 1000Z screen or a 2000 screen on my computer displays, they're exactly the same size and resolution.     But I will reluctantly acknowledge that a 7" screen is smaller than an 8" screen.  Always worth pointing out, for those who might not know. 

BTW, this "problem" is acknowledged by Rigol as evidenced by the fact that they use a bigger (and uglier, IMHO) font on the DS1000Z series.

That's an interesting observation, because when I started comparing the two, that's the very first thing I noticed (uglier font choice).  And it took me a minute to realize why they had done so.

In any case, I don't think the difference in the two screen sizes is enough (by itself) to merit going for one DSO or the other. I just wanted to point out that it's not quite so cut and dry as 'they're both 800x480 pixel screens'.

Fair enough.

[Mark_O]

Hi marshallh,

...

The longer answer is...

Geez, Marshall, you had to go and ask.   

[marshallh]

To be clear, I'm not trying to design or fix anything in particular, I'm just trying to build a very basic lab for learning;

I posted because what I see is someone who may spend so much time planning how he WILL learn that he never gets around TO learning.
People learn differently, that said, start building something and you'll very quickly see what you need to learn. How about getting both scopes and using them on a project

[Mark_O]

But also the DS2000 is 60-70 % more expensive than the non arb-waveform generator model of DS1000Z for the same bandwidth.

But the bandwidth has been hacked on the DS2000 to 200MHz - so if you compare it to the DS1104Z, the price difference is only 23%

Well, if you're gonna use that kind of logic , the bandwidth has not been hacked on the 2000A, and getting your hands on a non-A DS2072 may now be difficult to impossible (and even harder in the future).

[Mark_O]

I was just pointing out that the 1000Z is still immensely powerful, and that it still has many features. Yes, I agree, if you are doing I2C or UART only, a 2000 series might be better, but for SPI, you almost need 4 channels on an oscilloscope, or go buy a true logic analyzer.

I find it interesting that Rigol claims the 2000 can handle SPI decode on the 2000, in spite of the fact that it lacks sufficient channels to do so.  Yet they don't do that on the 4000, which lists SPI decode as a "DS6XXX4 Option".  I.e., available on the 4-channel version only.

[Mark_O]

And to return for a moment to EF's titular question:

DS2000 vs. DS1000Z record, playback, navigate, analyze, mask, etc. ??

The answers are:

- the 1000Z has a similar capability to set the trigger conditions that generate a Record frame.

- the 1000Z Records up to 60k frames, vs. 65k on the 2000.
  but due to the smaller memory capacity, the detail in those frames will be reduced.
  to increase detail, you can trade off # of events captured to boost samples/event.

- the 1000Z captures only the first N events, while the 2000 can optionally capture the last N.
  the later could be more useful when probing interactively, vs. running a delayed "batch mode"
  acquisition.

- for Playback, the 1000Z can Play frames back at various rates, just like the 2000.
  playback can be in Fwd or Rev, from a designated Start to End frame.  And you can Stop if you
  see something interesting.
 
- for Navigation,  it can also step forward & back, or go to Frame N.  It looks like also a JumpToEnd/Begin.
  it lacks the fast & convenient jog/shuttle dial on the 2000.  if you're only capturing a few hundred records,
  then manually scrolling through them isn't too bad.  but if you've recorded thousands of events, it may
  be easier (and quicker) to just hit Play and wait until you arrive in the desired neighborhood.

- for Analysis, it has nothing at all!  this is the biggest functional weakness, IMO. 
  the 2000 can compare ALL the captured frames against one frame selected as the template,
  OR the average of all the frames, OR against any arbitrary Mask, and highlight the occurrences
  that deviate by a specified %age.  the 1000Z does none of these.

- for Masks, both can define a Mask and then use it to count frames that exceed it.
  the 2000 can use a Mask in Analysis mode to post-process a segmented capture, but the 1000Z can't.

Initially, I had thought that both the 1000Z and 2000 could use a Masking Failure as a trigger condition, while in Record mode.  But reading more carefully, I'm not sure either can.  If not, it may be because the processor is not fast enough to do so in real-time.  So Mask Analysis would be available only as a post-processing option on the 2000.

[The LeCroys I've used do allow the Masks to be used in real time to capture qualifying events, but elaborate triggering is their forte.  It can even have up to 3 other conditions running on other channels (including Math channels), along with the masks.  But apparently even the Agilent 3000X doesn't provide this.  Though it can save a PNG of each Fail event.  So no reason to be disappointed if the Rigol's can't.]

One thing that's not clear from the manual for either scope is whether the acquired Record frames can still be panned and zoomed after capture, and Measures applied.  I suspect they can on the 2000, but not so sure on the 1000Z.  They definitely can't on the 1000C and CD.  And that's an extremely useful capability.

[Mark_O]

And to help EF out...

Other Limitations of the 1000Z to Consider:

1)  the 2000 has the ability to trigger on USB packets.  It can detect SOP, EOP, etc. and trigger on the desired element.  It can not decode a USB signal, but just being able to capture on selected segments can still be useful.

The 1000Z has no USB capability at all.

2)  the 2000A has a CAN option, which not only triggers on CAN messages (and even on specific field contents), but also has a full decode capability, error highlighting, etc.  While the 2000 (non-A) currently doesn't, it may in a future firmware update.

The 1000Z has no CAN capability, and likely never will.

3)  I just noticed that the claimed capability of the 1000Z to handle HDTV signals is bogus.  HDTV is either 720P or 1080i, or 1080p.  Yet the 1000Z is limited to 480P or 576P (PAL).     Where Rigol got the idea that EDTV signals were HDTV, I don't know.  But the claim is false.

~~

Those, along with the missing Measurement History on the previous page, is all I have.  And I still think the 1000Z is an excellent product, loaded with features, at a phenomenal price.  Unless someone is sure they'll never need a 3rd channel, or finds one of the functional omissions critical (CAN, for example), I think any beginner (and many pros) working with both digital and analog signals would be better off with the 1000Z than the 2000.

IMO, too much of the earlier comparisons (before your purchase) between the two focused simply on raw performance numbers.  Possibly because that was so easy to do.  The 1000Z was "less good" because it had "only" 24M  sample memory, since the DS2000 had 56M.  In that case, I guess the 2000 must be sub-par, because the DS4000 has 140M!

And the 1000Z is substandard because it can "only" sample at 1 GHz, vs. the 2 GHz of the 2000.  Which must suck, because the 4000 can sample at up to 4 GSa/s.  (Several posters also denigrated the 250 MSa/s limit on the 1000Z in 4-channel mode, then promptly compared that to the 1 GSa/s speed of the 2000 in 2-channel mode.     Why not compare against the speed of the 2000 in 4-channel mode... which is 0 Sa/s?)

And the 2000 kicks butt on the 1000Z, because its max bandwidth is 200 MHz, vs. only 100 MHz on the 1000Z.  But that's nothing compared to the 500 MHz bandwidth on the 4000.  So I guess the 2000 must be dog meat.


To avoid any confusion, marmad has never participated in any of the bashing of the 1000Z.  I think his objectives are the same as mine, which is to present all the pro's and con's in a clear light, and let everyone choose for themself which makes the most sense for them.  And I agree with him that if you don't need, and won't use, more than 2 channels, then the 2000 is definitely the better way to go.  Even though you're paying 43% more for half the channels, the performance of the 2000 fully justifies it.  His comment that while the 2000 sacrifices raw performance numbers to the 4000, it hasn't stripped functionality, is also apt.  (Well, it lost Flexray decode and a VGA out, but by and large, they're pretty close.)

OTOH, if 2-channels may not be enough for things you expect to be doing some of the time, then the set of compromises that Rigol made in bringing out a feature-packed 4-channel scope, for an exceptionally low price, do not invalidate the usability of the instrument.  And many would find the extra channels very useful and time-saving, though they've been getting by with only 2 for so long (due to non-affordability of 4-channel devices) they may not recognize situations where the extra channels would provide meaningful insight, or could reduce diagnostic time.  (Or say, "dammit", and do their testing in multiple phases, looking at 2 channels at a time, and taking 3-5 times as long.  Been there.  Done that.)

In my own experience, I have ~9 'scopes, and use them for different purposes.  Three are 2-channel, four are 4-channel, one is 8-channel, and one is 18-channel (a 2+16 MSO).  (I also have a collection of logic analyzers, and protocol analyzers as well, from 8-136 channels, and use those when appropriate.  But that's a different discussion.)  I spend about half of my time using 2-channels (sometimes just 1-channel!!).  And the other half using 3 or more channels.  But that's just me.  Your needs and use cases may vary.  There's no "one size fits all".

I can assure you though that going for the best possible performance, in lieu of functionality considerations, is often a mistake. Case in point, the "best" scope I own has a 1 GHz bandwith, samples at 5 GSa/s on all 4-channels, and uses four 3-GHZ probes that at retail (which I sure as heck didn't pay) cost significantly more than a DS2074.  And it's one of my least used scopes.   

[Mark_O]

And BTW, people have been using and debugging SPI implementations long before protocol decoding was available on cheap DSOs.

True.  But they weren't having as much fun doing it. 

And if someday your needs change, and SPI becomes as important to you as I2C is now, you might even find yourself wishing you had 2 more channels.

[marmad]

And if someday your needs change, and SPI becomes as important to you as I2C is now, you might even find yourself wishing you had 2 more channels.

I use a logic analyzer for nearly all of my decoding - I rarely use the DSO; it's not really the correct tool for the job. The I2C decoding on the DS2000 is handy in a pinch, but I wouldn't rely on it (or any oscilloscope decoding) as my main (or only) option.

MSOs (and protocol decoding in general) are like cameras in cell phones. Manufacturers combine the functions because they are share similar attributes - and it's sometimes handy to use the thing that you just happen to be holding (or have sitting in front of you ). But no one (at least not yet) serious about photography relies solely on their cell phone camera.

[sync]

One thing that's not clear from the manual for either scope is whether the acquired Record frames can still be panned and zoomed after capture, and Measures applied.  I suspect they can on the 2000, but not so sure on the 1000Z.  They definitely can't on the 1000C and CD.  And that's an extremely useful capability.

Measurements, cursors, zooming, panning and delayed timebase are working in playback mode on the 1000Z. But using it is cumbersome because of the missing dedicated record mode buttons.

[marmad]

One thing that's not clear from the manual for either scope is whether the acquired Record frames can still be panned and zoomed after capture, and Measures applied.  I suspect they can on the 2000, but not so sure on the 1000Z.  They definitely can't on the 1000C and CD.  And that's an extremely useful capability.

Measurements, cursors, zooming, panning and delayed timebase are working in playback mode on the 1000Z. But using it is cumbersome because of the missing dedicated record mode buttons.

Virtually any processing that can by applied to real-time signals (including protocol decoding) can be applied to segments (excluding acquisition modes - although you can use the different modes to initially capture the segments).

One standard post-processing technique (and super-easy to implement) that Rigol failed to include for segments is "Display All" (showing all acquired segments simultaneously to look for deviations). My RUU software can do this, but you have to get all the segments out of the DSO, which takes a fair bit of time (each segment is considered a unique acquire by the DSO - you can't just export the entire segmented memory in one transfer).

Of course, you can locate deviations with the Analysis function, but that requires time to setup and run; having a "Display All" would save time in many circumstances - and should be included on both the DS2000 and DS1000Z as standard.

[Mark_O]

One thing that's not clear from the manual for either scope is whether the acquired Record frames can still be panned and zoomed after capture, and Measures applied.  I suspect they can on the 2000, but not so sure on the 1000Z.  They definitely can't on the 1000C and CD.  And that's an extremely useful capability.

Measurements, cursors, zooming, panning and delayed timebase are working in playback mode on the 1000Z.

Thanks, sync!  That's good to hear.  The older Rigol's are really crippled, in that regard.

But using it is cumbersome because of the missing dedicated record mode buttons.

But of course, that's not (good to hear).    I assume that's because you have to leave the Record menu to access those functions, then return back to the Record menu again to navigate between frames?  That is a PITA I  hadn't considered.  I'm glad you mentioned it, because it can negatively impact usability.  (Which is what marmad has been saying all along.  )

[sync]

But using it is cumbersome because of the missing dedicated record mode buttons.

But of course, that's not (good to hear).    I assume that's because you have to leave the Record menu to access those functions, then return back to the Record menu again to navigate between frames?

Yes.

[Mark_O]

I use a logic analyzer for nearly all of my decoding - I rarely use the DSO; it's not really the correct tool for the job. The I2C decoding on the DS2000 is handy in a pinch, but I wouldn't rely on it (or any oscilloscope decoding) as my main (or only) option.

Thanks for the perspective.  I had thought you valued the I2C decoding on the DS2000 more highly.

MSOs (and protocol decoding in general) are like cameras in cell phones. Manufacturers combine the functions because they are share similar attributes - and it's sometimes handy to use the thing that you just happen to be holding (or have sitting in front of you ). But no one (at least not yet) serious about photography relies solely on their cell phone camera.

I get the analogy, and agree that the PD's in MSO are weaker in general.  I hope you weren't inferring that anyone using a serial analyzer on a 'scope isn't "serious".  Certainly if you can be confident that the serial analysis issues you're dealing with are 100% in the logic domain, then there's no reason to be using a DSO for that.

However, in my experience., sometimes (10-20%?, but too often, in my book) the problems lie in the voltage domain.  Thresholds not correct, drooping voltage levels, foreign signal coupling, spikes or sporadic noise incursion, RFI/EMI, etc.  You can wind up scratching your head for a while, if these issues are unknown, and wasting a lot of time with a LA.  Since you'll never catch them with a logic analyzer. 

That's why I often start with a DSO, to make sure those issues aren't present.  And if the problem IS purely on the logic side, but can be readily seen on the DSO, I'm done.  I only pull out the logic analyzers when I really need to, which is less often the better the PD is in the DSO or MSO I have available.  An LA tends to require significantly more setup time, which often isn't justified.  And if it turns out I need to correlate a certain serial data packet with some analog control signal or sensor in the SUT, then I'm back to the scope anyway.

The "correct" tool for a job is the one that gets the job done quickest and most completely.  That will vary with the task at hand.  It's also dependent to some degree on the context as well.  I.e., there's a difference between troubleshooting an existing device, and evaluating a new embedded system design under development.  In the former, you are less likely to run into problems outside the logic domain, than in the later.  (Though it's possible either way.)

YMMV.

[Mark_O]

Virtually any processing that can by applied to real-time signals (including protocol decoding) can be applied to segments (excluding acquisition modes - although you can use the different modes to initially capture the segments).

That's excellent.  And the way it should be.

One standard post-processing technique (and super-easy to implement) that Rigol failed to include for segments is "Display All" (showing all acquired segments simultaneously to look for deviations).

I agree, but can't you achieve a similar result (identifying outliers) by selecting Analysis with Average as the Source?  With a Display All, you have an overlay which reveals nonconformity (presumably using intensity), but you can't identify which event(s) were involved?

Of course, if all you're trying to do is verify the presence or absence of deviations from the standard, then a DisplayAll would give you everything you needed to know.  And very quickly.

My RUU software can do this, but you have to get all the segments out of the DSO, which takes a fair bit of time (each segment is considered a unique acquire by the DSO - you can't just export the entire segmented memory in one transfer).

Ah, thanks.  That makes sense.  I think I had asked you about segment extraction in PM a while back, and that's the same way Agilent does it.  How long is "a fair bit of time"?

Of course, you can locate deviations with the Analysis function, but that requires time to setup and run; having a "Display All" would save time in many circumstances - and should be included on both the DS2000 and DS1000Z as standard.

I guess I had assumed that an Analyze pass was relatively quick.  Evidently, not so much.  But I agree that would be a good addition to the firmware for these scopes.  Did you forward that suggestion to Rigol via Drieg yet?  If not, you should.

[neslekkim]

I have been wondering about these two scopes, in the pricerange, the DS1104Z and the DS2072 is very close to each other, but cannot decide wether the one or the other, yes, 4 channels is probably fine, but what about the 1 vs 2G Samplingrate?, is there other things that makes the choice easier?

[Mark_O]

I have been wondering about these two scopes, in the pricerange, the DS1104Z and the DS2072 is very close to each other, but cannot decide wether the one or the other, yes, 4 channels is probably fine, but what about the 1 vs 2G Samplingrate?, is there other things that makes the choice easier?

> but what about the 1 vs 2G Samplingrate?

What about it?  One is twice as fast as the other.  I don't understand the question.  Will 1 GSa/s be inadequate for your needs?  If so, you don't want the 1000Z.

This question has been discussed pretty extensively here.  If you do a Search, you can find many pro's & con's.  Or click on ElectroFan's name, and then the link listing his Posts, and you'll find many threads on this specific topic.

Do you need (or will you at some point need) 4 channels?  Then the choice is clear.  If not, then the 2000 has better performance specs, along with usability enhancements that will make it a better choice for some folks.  The 1000Z is also notably smaller and lighter physically, and that may give it an edge for some, while being completely irrelevant for others.

One functional advantage the 1000Z has that the 2000 lacks is the ability to handle SPI, because it requires 4 channels.  4 channels also means you can actually use the 2 serial Decoders, while the 2nd Decoder on the 2000 is pretty much meaningless (you've already run out of channels to use them with just Decoder1).  If you need to decode a serial link using 2 channels, on the 1000Z you still have 2 channels left to probe other signals.  You have no channels left on the 2000. 

If you need a Function/AWG generator and have limited bench space (or want one built-in for portable use, with fewer boxes to carry), it's an available option on the 1000Z-S, but not on the 2000.

If none of those considerations are important to you, the 2000 is likely the better choice.  Both are actually great options.