Is a Rigol MSO5000 overkill for a hobbyist?

[switchabl]

I am somewhat shocked by the rage around the zoom issue. I'll admit I like the ability to zoom out on a stopped acquisition. Sometimes I don't quite know what to expect, start with some setting and then it turns out I need to see more. Maybe that is just because I am stupid and don't know what I am doing (always a realistic possibility). But to me it's just convenient that I don't have to start over. 

If you mostly work with signals that are periodic and easily replicated you may not care anyway. If you are used to Lecroy scopes you are probably used to a different workflow. There is nothing wrong with that. But there are many features on a scope I don't use either and that doesn't mean they shouldn't be there.

[Caliaxy]

Workaround from Keysight is dangerous trick. If you set Normal trigger mode, wait for a sparse  trigger, you get several, you see on the screen something interesting and press stop two things might happen: if there is a trigger within few hundreds milliseconds it will destroy capture from the screen, and get another long capture. Different from the one because of which you stopped the scope. Second option is that if you don't get a new triggerable event in that period, then it will stop and show you your screen. It will not have anything but on the screen in memory. So see, that Keysight trick doesn't work at all, and it's only purpose is to pretend it does...

Ha-ha!  So you are telling us that you:

(1) watch the screen of an oscilloscope capable of displaying >100,000 waveforms/second (and plotting the result on screen at a rate of at least 30Hz);
(2) notice a single rare event;
(3) press the STOP button to freeze the said rare event and inspect what’s outside of the curve plotted on screen;
(4) get a wave on the screen you can, indeed, zoom out BUT doesn’t show the rare event anymore?
(5) … and then you blame Keysight’s “dangerous” work-around that assumes that your reaction time is slower than the speed of light, so any non-naïve user would not do what you describe in the first place?

Bad example, doesn’t support your point…

[2N3055]

I agree with you. HDO 1000 is basically a DS1000Z with 12bit ADC and big touch screen.

As if that's nothing... 

We haven't seen the firmware capabilities yet but just as some people won't be affected by the noise on the MSO5000, other people will probably kill for the low noise and detail of an HD1000.

We have seen quite a lot of current firmware capability. There is a full user manual available.
It is scope for mostly analog work (and some decoding from analog ch, which might be enough for many people ), but from what we have seen (there are measurements available) HD1000 is worse than HDO4000 noise wise, and on par with some 8 bit scopes Micsig, SDS2000X+ and 10bit RTB2000. Which is a great result for Rigol but nothing groundbreaking. I think it is great technological advance for Rigol, but don't forget that all Rigol "bestsellers" so far where compeeting on price and nominally large featureset (even if implemented in barely usable way) not quality or superior performance. Their best products were DS1000Z (cheapest "real" scope) and MSO8000 (cheapest 2GHz scope).I recommended both on many occasions. MSO5000 at current price is also good value for money despite compromises (higher noise than any competition) for people not doing low level fine analog...
HDO1000 and HDO4000 would have been interesting products if they were MSO5000HD and MSO7000HD, i.e. a 12 bit low noise upgrade to current MSO line with new, hopefully better GUI (which it does seem they did much better this time, albeit it looks very new and will have to "mature" a bit..).

At the moment,  HDO4404 cost some 15% less then SDS2354X HD. SDS2354X HD is a proper MSO and a proper 12 bit scope.
In my mind that is 15% less money for 50% less of the scope...
And in my measurements on SDS2354X HD, when I apply all the same filters as HDO4000 does on 500uV/div I still get few percent less noise than HDO4000... So go figure, you cannot outsmart physics with firmware...

It remains to be seen how many people will choose one over other... But in my mind they do not directly compete... They are not exactly 1:1 products..

As for HDO1000 we have yet to see it in sales channel...  But HDO1x04 is listed on Rigol shop with MSRP of 1200€ to 2000€.
If you compare unhacked versions it is comparable with SDS2000X+ in price per MHz. Hacked, same, except SDS2000X+ goes to higher frequency, has built in AWG, and is MSO.
Cheapest HDO1000 is already too expensive for hobby users to casually buy it...
So again up to users to decide what feature set is important to them.

[2N3055]

Workaround from Keysight is dangerous trick. If you set Normal trigger mode, wait for a sparse  trigger, you get several, you see on the screen something interesting and press stop two things might happen: if there is a trigger within few hundreds milliseconds it will destroy capture from the screen, and get another long capture. Different from the one because of which you stopped the scope. Second option is that if you don't get a new triggerable event in that period, then it will stop and show you your screen. It will not have anything but on the screen in memory. So see, that Keysight trick doesn't work at all, and it's only purpose is to pretend it does...

Ha-ha!  So you are telling us that you:

(1) watch the screen of an oscilloscope capable of displaying >100,000 waveforms/second (and plotting the result on screen at a rate of at least 30Hz);
(2) notice a single rare event;
(3) press the STOP button to freeze the said rare event and inspect what’s outside of the curve plotted on screen;
(4) get a wave on the screen you can, indeed, zoom out BUT doesn’t show the rare event anymore?
(5) … and then you blame Keysight’s “dangerous” work-around that assumes that your reaction time is slower than the speed of light, so any non-naïve user would not do what you describe in the first place?

Bad example, doesn’t support your point…

You understood it completely wrong. Did you read it at all or was I so bad at explaining?
THIS is exactly what Nico does and people call zoom out.. not me.
I was writing it out to illustrate how ridiculous it is..
It absolutely IS my point.

scenario that is proposed (not by me):
1. You are not plotting at 30 Hz because scope is set to max memory and you cannot get more than 5 triggers per second.
2. events are spaced every few seconds.. there is enough time to look at the screen and notice something interesting.
3. you quickly press stop. Now you have full buffer of 200ms of stuff around that trigger to investigate at will.
This is Nico's scenario and it makes sense to me. But this is not Keysight but a scope that has full manual memory mode and 100 times (literally) more memory.

I was explaining how Keysight DOES not capture outside screen but only pretends it does.

When scope is in Normal trigger mode screen is frozen between trigger events and shows capture from last trigger event.
Let's say there is burst every 1 seconds, but there is randomness in period so sometimes it shoot two bursts close...
So you're looking at the screen and you see some anomaly.
You press stop. here there are two possible outcomes:
1. there is no another burst within some short timeout period. In which case there IS NOTHING outside the screen.
2. there is another burst from DUT that invokes additional trigger event (in short time  after you pressed STOP), which gets captured in full memory and you can see that on the screen. Screen that was on when you wanted to investigate is gone and you are looking at something else...

Is this better explanation.. ?

[balnazzar]

HDO1000 and HDO4000 would have been interesting products if they were MSO5000HD and MSO7000HD, i.e. a 12 bit low noise upgrade to current MSO line with new, hopefully better GUI (which it does seem they did much better this time, albeit it looks very new and will have to "mature" a bit..).

I have to agree about that.

[Martin72]

Not when you don´t need to observe very low voltage signals.

And even when you do, it can be made to work (hires mode, heatmap mode, etc).

If you're looking at low level signals all day long then it would make life difficult but many (most?) people simply aren't in that category.

(and if you are, the new Rigol HD will probably kick Siglent ass)

Unlike others, I'm mostly talking about the oscilloscopes I know/have owned.
And this was my verdict about the 5000 - Don´t believe I didnt try anything before giving it up..
And also I said, it depends from the needs you have - Some need it some not, that´s all and make the scope not worser/better in general.
And finally, stop this childish "kick ass" thing..There´s no fight, no who got the longest contest..

[Caliaxy]

You understood it completely wrong. Did you read it at all or was I so bad at explaining?
[...]
scenario that is proposed (not by me):
1. You are not plotting at 30 Hz because scope is set to max memory and you cannot get more than 5 triggers per second.
2. events are spaced every few seconds.. there is enough time to look at the screen and notice something interesting.
3. you quickly press stop. Now you have full buffer of 200ms of stuff around that trigger to investigate at will.
This is Nico's scenario and it makes sense to me. But this is not Keysight but a scope that has full manual memory mode and 100 times (literally) more memory.

I was explaining how Keysight DOES not capture outside screen but only pretends it does.

I did read it, but I can only read what you write, not your mind (working on that ☺). You just didn't elaborate.

So you are saying that the workflow a different user (Nico) has developed on a different scope (non-Keysight), with 100x more memory would not work if Keysight’s approach were implemented on the said scope (which isn't). Is this what you are trying to say? What is the point of stating that?

Keysight’s approach seems a neat trick to speed-up the acquisition in normal mode while providing you with extra information in STOP or single-shot mode. Yes, it would not allow users like Nico to use it with their workflow, but it does not matter at all, because they should not attempt to use this particular scope in this particular way. The acquisition rate would be very likely too fast for them to react, anyways, so that scenario is not a real-life one. Horses four courses. Nothing “dangerous” here. That’s my point.

[Fungus]

I am somewhat shocked by the rage around the zoom issue. I'll admit I like the ability to zoom out on a stopped acquisition. Sometimes I don't quite know what to expect, start with some setting and then it turns out I need to see more.

Exactly the point. If you've got it stopped and are looking at something you need to be able to zoom out.

Zooming out then recapturing isn't a comfortable/natural way to work and it isn't always possible to do it.

[2N3055]

You understood it completely wrong. Did you read it at all or was I so bad at explaining?
[...]
scenario that is proposed (not by me):
1. You are not plotting at 30 Hz because scope is set to max memory and you cannot get more than 5 triggers per second.
2. events are spaced every few seconds.. there is enough time to look at the screen and notice something interesting.
3. you quickly press stop. Now you have full buffer of 200ms of stuff around that trigger to investigate at will.
This is Nico's scenario and it makes sense to me. But this is not Keysight but a scope that has full manual memory mode and 100 times (literally) more memory.

I was explaining how Keysight DOES not capture outside screen but only pretends it does.

I did read it, but I can only read what you write, not your mind (working on that ☺). You just didn't elaborate.

So you are saying that the workflow a different user (Nico) has developed on a different scope (non-Keysight), with 100x more memory would not work if Keysight’s approach were implemented on the said scope (which isn't). Is this what you are trying to say? What is the point of stating that?

Keysight’s approach seems a neat trick to speed-up the acquisition in normal mode while providing you with extra information in STOP or single-shot mode. Yes, it would not allow users like Nico to use it with their workflow, but it does not matter at all, because they should not attempt to use this particular scope in this particular way. The acquisition rate would be very likely too fast for them to react, anyways, so that scenario is not a real-life one. Horses four courses. Nothing “dangerous” here. That’s my point.

I have to work on my explanations and you have to work on understanding...
This is second time you extrapolated something that wasn't even suggested.

Point is that Keysight is not "capturing outside the screen" like people say it does. It only pretends to do so..
So yes, Nico's workflow doesn't work with Keysight but people keep saying it should "because it captures outside the screen". It does not.
So users don't know that about Keysight and therefore don't know they should not use Keysight in this manner.
If you don't know the difference, then you are the first one who needs this warning about Keysight.

You are presuming wrong usage here. This type of use would use a selective trigger that would fire off only occasionally, be it anomaly, or specific level or message. It would be used for non repetitive events. Why you presume 100000 triggers per second and then stop mode? Why did you even think of that? What would be use of that ?? Who in their right mind would think they can stop scope in 100 ns?

[2N3055]

I am somewhat shocked by the rage around the zoom issue. I'll admit I like the ability to zoom out on a stopped acquisition. Sometimes I don't quite know what to expect, start with some setting and then it turns out I need to see more.

Exactly the point. If you've got it stopped and are looking at something you need to be able to zoom out.

Zooming out then recapturing isn't a comfortable/natural way to work and it isn't always possible to do it.

That is why you start with capturing more in a first place.. instead of relying on magical mind reading memory "that should" capture more...

[Someone]

I am somewhat shocked by the rage around the zoom issue.

If nctnico would stop posting inflammatory and misleading comments that make out like this is a issue that affects everyone/everything the "drama" would dissapear almost immediately. Notice how the OP was asking about one specific thing: capturing as much data as possible, but nctnico only want to talk about their "human trigger" use case. So we have:

- The scope could and should capture much more data with respect to the screen's window. It has the memory and should have the computational/sampling power to do that without slowing down. Otherwise, even the workaround by Keysight is better than nothing. And according to tautech even Siglent is changing its "design choices" about that.

The "zoom out" trick is by definition slowing down a scope, all that data around the screen is captured and not seen on the window but is blocking another trigger from happening.

Yes, there is use for that, but its an extreme corner case and not the normal/typical use. It requires the user to know what trigger rate they want, accept not seeing any of the "zoom out" data during operation, and for some odd reason refuse to use a zoom window.

Explained in context and actually including the explanation, which nctnico then jumps on and makes the ridiculous and unframed/unsubstantiated claim that

suggesting to use the zoom window is just stupid

Without any clarification or disclaimer that it is "stupid" in their (unstated) very very narrow (almost imaginary) use case, while the rest of us know using zoom is generally not stupid. Its that difference between honest and well communicated situational things, vs nctnico's nonsense generalisation that they insist on pushing (knowingly, intentionally) creating fake drama....   and derailing endless threads.

Running extra capture around the visible window slows down a scopes possible trigger rate, this isn't theoretical but has been measured and is well known. That is a true generalisation, and the information that the OP was missing.

If the trigger is known/accepted to be slow
and
the user cannot use triggers to capture the desired signal so will be pressing stop manually
and
the detail to trigger on is substantially away from other important detail that must be captured
and
the detail for the human trigger is no longer visible when using a zoom window

then you might be worried about nctnico's warning, as you see its some obscure corner case, and not a general issue that "zoom window is just stupid". There are many many possible other solutions to that problem that people will have different constraints/values so its not a obvious or necessary solution. Despite asking and thinking about it I have not heard any other real use cases for capturing data outside the display, they all fall back onto people trying to force an imaginary situation.

[nctnico]

Meanwhile there are lots of people stating that they like to zoom out. Personally I use it all the time because for some of the measurements I do regulary, I simply can't know what time/div setting to use. Needing to make only one measurement is more convenient. Again: just like several other have stated already. But they are likely corner cases as well.  Heck, I even state the earth is a sphere. You'll now try to argue it is flat because you can't see it is a sphere.

[Fungus]

Zooming out then recapturing isn't a comfortable/natural way to work and it isn't always possible to do it.

That is why you start with capturing more in a first place.. instead of relying on magical mind reading memory "that should" capture more...

So what you're saying is we should never turn the horizontal knob to "max", just in case...?

[Someone]

(1) watch the screen of an oscilloscope capable of displaying >100,000 waveforms/second (and plotting the result on screen at a rate of at least 30Hz);
(2) notice a single rare event;
(3) press the STOP button to freeze the said rare event and inspect what’s outside of the curve plotted on screen;
(4) get a wave on the screen you can, indeed, zoom out BUT doesn’t show the rare event anymore?

The misleading posts have confused you too! "Zooming Out" requires (is predicated on) that the triggers be slow enough a human is able to press stop and capture the important event. So now you're just adding more confusion and drama.

There are scope modes which will do what you are talking about, history/replay mode:

But that is not an industry standard mode so segmented/circular buffers might prioritise capturing rather than displaying to the screen.

[Fungus]

"Zooming Out" requires (is predicated on) that the triggers be slow enough a human is able to press stop and capture the important event. So now you're just adding more confusion and drama.

The level of denial reaches record heights.

What's the problem in having a bit of extra memory on either side of the screen? Why wouldn't you want that? Can somebody explain to me why it's a bad thing?

[2N3055]

"Zooming Out" requires (is predicated on) that the triggers be slow enough a human is able to press stop and capture the important event. So now you're just adding more confusion and drama.

The level of denial reaches record heights.

What's the problem in having a bit of extra memory on either side of the screen? Why wouldn't you want that? Can somebody explain to me why it's a bad thing?

Good question. Nothing is wrong. We all do it by using timebase to capture a bit wider than event. That is all.
Wrong is to say it is necesary. It is not if you use scope properly.  Simple as that.

[Someone]

"Zooming Out" requires (is predicated on) that the triggers be slow enough a human is able to press stop and capture the important event. So now you're just adding more confusion and drama.

The level of denial reaches record heights.

What's the problem in having a bit of extra memory on either side of the screen? Why wouldn't you want that? Can somebody explain to me why it's a bad thing?

As I have explained over and over, having more memory captured around the screen reduces the capture rate. So for situations with fast triggers you might not ever see some events. That's a significant downside that keeps being hidden by blanket statements like yours, anyone with a reasonable grasp of how a scope works would realise this but you bring up "zero downsides" as a complete straw man.

Neither approach is is wrong or incorrect under all situations.

What I point to is that a) 90% of the discussion on this matter is confusion (unintentional confusion? we need more discussion, intentional confusion? that's trolling) and b) having worked with many many people and listened to many many discussions on here most people want to have all the captured data on the screen (for all the benefits and downsides that has)

Refusing to acknowledge the pros and cons of different methods is why this topic turns into a dumpster fire each time. I explain them politely, and then people come in and try to argue some ridiculous extreme position.... thread derailed and more noise added.

The OP raising the questions they did is evidence of how broken this discussion is, there appears to be no intent from some to help people learn and use their devices effectively, but instead some internet point winning nonsense.

[Fungus]

As I have explained over and over, having more memory captured around the screen reduces the capture rate. So for situations with fast triggers you might not ever see some events.

No it doesn't.

As has been pointed out over and over: You only zoom out when the thing is stopped so "capture rate" doesn't enter into it. Memory is a big circular buffer which is constantly being filled. The data is in there regardless of how much of it is being shown on screen.

[Caliaxy]

Point is that Keysight is not "capturing outside the screen" like people say it does. It only pretends to do so..

Of course it does "capture outside the screen". It does it in single shot mode, when it's relevant. The fact that it takes another single shot when you press STOP in Normal mode is irrelevant for the reasons we just discussed (and seem to agree...).

[Someone]

As I have explained over and over, having more memory captured around the screen reduces the capture rate. So for situations with fast triggers you might not ever see some events.

No it doesn't.

As has been pointed out over and over: You only zoom out when the thing is stopped so "capture rate" doesn't enter into it. Memory is a big circular buffer which is constantly being filled. The data is in there regardless of how much of it is being shown on screen.

You are (same as nctnico) making this imaginary "argument" with the assumption that the trigger rate and what you want to see  (and human trigger on) is slow enough that there is no blind time or missed triggers, and you will be inspecting the stopped capture that is sure to have exactly the information you want contained within it.

SO JUST SAY THAT, instead of drawing out endless noise.

Right from the outset I have clearly explained the framing/situation:

Running extra capture around the visible window slows down a scopes possible trigger rate, this isn't theoretical but has been measured and is well known. That is a true generalisation, and the information that the OP was missing.

When the trigger rate is unknown, or approaching/higher than the capture period (on or around the screen) you can end up with missed triggers that may well have been the information the user was interested in. That is the far more common use case of a scope.

Your point blank statement that nothing is lost or missed when having the capture extend outside the scope screen in plainly wrong:
[data data data data data data data | trigger on screen | data data data **missed trigger** data data]
For all the people scrambling to reduce blind time and increase the amount of information arriving at the screen, you are proposing the opposite and trying (unsuccessfully) to argue that there is no downside.

People might consider the ability to "zoom out" as a feature the want, that's fine. They should walk into that understanding the use cases and alternatives rather than being bullied by a noisy minority to accept that blindly as the way to do it. But to go around claiming that use "zoom out" use case has no downsides or limitations is going so far out into absurdity its saying an awful lot about either a) your motivations for being here, or b) your understand of how scopes are used/work. They might not be downsides in specific cases, but you need to say that rather than the short generalisation which is so plainly wrong.

           x1000

[EEVblog]

          x1000

Give it a rest.

[Fungus]

Your point blank statement that nothing is lost or missed when having the capture extend outside the scope screen in plainly wrong:
[data data data data data data data | trigger on screen | data data data **missed trigger** data data]

It's almost as if you believe the screen is refreshing at 120,000 frames/sec and that every one of those triggers is being displayed.

[Someone]

Your point blank statement that nothing is lost or missed when having the capture extend outside the scope screen in plainly wrong:
[data data data data data data data | trigger on screen | data data data **missed trigger** data data]

It's almost as if you believe the screen is refreshing at 120,000 frames/sec and that every one of those triggers is being displayed.

I'll call that as I see it, troll post is troll. You know that is not what I said or meant but you keep throwing up more strawmen to fake like I dont know what I'm talking about.

Scopes can render multiple acquisitions on top of each other onto the screen, and yes there are scopes that can display 120,000 triggers per second (or more) through to the screen. You know all this, but here is some learning material on the topic:
"Application Note for Oscilloscope Waveform Update Rate Determines Probability of Capturing Elusive Events" https://xdevs.com/doc/HP_Agilent_Keysight/5989-7885EN%20English%20_%202014-08-02%20_%20PDF%202.87%20MB%20c20140903%20%5B12%5D.pdf
Also talks about blind time (keeping on topic here). That data outside the visible window in the above example is lost and never seen if more triggers arrive. A serious problem and a reason to not use an acquisition buffer larger than the screen. Which falsifies your unsubstantiated claim:

As I have explained over and over, having more memory captured around the screen reduces the capture rate. So for situations with fast triggers you might not ever see some events.

No it doesn't.

As has been pointed out over and over: You only zoom out when the thing is stopped so "capture rate" doesn't enter into it. Memory is a big circular buffer which is constantly being filled. The data is in there regardless of how much of it is being shown on screen.

See how that quoted line actually presents the information in context. If you are talking about an entirely different situation with slow trigger rates, yes that's a thing, with many ways to capture and look at the data. You don't lose any data from the last trigger when you press stop, but all those triggers that happened before had data/event off screen that were never seen and couldn't be triggered on ,the reason why people wouldn't always run their scope with "zoom out". The capture rate of a scope is degraded when you increase the capture window, on all current scopes (it is theoretically possible to not do that but it hasn't been implemented) which is why zooming out is often a bad choice.

[Fungus]

Scopes can render multiple acquisitions on top of each other onto the screen, and yes there are scopes that can display 120,000 triggers per second (or more) through to the screen.

Of course, but none of that is incompatible with being able to remember what was outside the screen and allowing the user to zoom out later.

Proof: Other 'scopes manage to do it.

[2N3055]

Scopes can render multiple acquisitions on top of each other onto the screen, and yes there are scopes that can display 120,000 triggers per second (or more) through to the screen.

Of course, but none of that is incompatible with being able to remember what was outside the screen and allowing the user to zoom out later.

Proof: Other 'scopes manage to do it.

You keep moving target and state deliberate controversies..

There are scopes that can capture outside the screen and do 1M wfms per second. True.
But not AT THE SAME TIME. Proof: Keysight 3000T in Digitizer mode VS normal realtime mode..

But that all is a moot point.

I find R&S, LeCroy, Siglent, Picoscope type of history buffers (that actually remember 1000s of previous triggers) much more important and useful.  That is the feature that I would take into account in purchasing decision. Why nobody speaks about that...?