A newbie needs some help with my first DSO

[KungFuJosh]

Come on Rob, never get in the way of true love. 😉

[nctnico]

Oh FFS
Please you 2 go get a room together, not one where the OP is attempting to get his head around the featureset of his first DSO.

Don't worry. I have set a hard limit at two replies to tggzzz within 20 posts. 

[BillyO]

This may already have been mentioned, but the full memory available is always filled on a Siglent (most scopes for that matter).  You can just go to the history to see the rest of it if you have nothing better to do with your life than scroll through 10s of millions of data points looking for something you didn't expect.   

As I think someone already said, learning how to define triggers properly is the key.  And that is time you only have to spend once.

[nctnico]

If (part of) your work (like mine) consists of doing single shot measurements, then history doesn't matter. It is wasted memory because the previous measurement simply isn't relevant. So please give me the choice to have full memory in a single shot even though some or most of it doesn't show on screen right away.

[BillyO]

If (part of) your work (like mine) consists of doing single shot measurements, then history doesn't matter. It is wasted memory because the previous measurement simply isn't relevant. So please give me the choice to have full memory in a single shot even though some or most of it doesn't show on screen right away.

Can you explain this a little better (not being argumentative, but I just don't understand)?  What is it you are looking for that can ONLY occur after the moment of acquisition? 

[egonotto]

Hello,

It would be good if awakephd would say what signal sources he has available, so that you could suggest better experiments.

Best regards
egonotto

[bdunham7]

So please give me the choice to have full memory in a single shot even though some or most of it doesn't show on screen right away.

That option is there but you just don't like the way you make it happen--and it isn't really that much work even if it isn't what you're used to.

[Someone]

If (part of) your work (like mine) consists of doing single shot measurements, then history doesn't matter. It is wasted memory because the previous measurement simply isn't relevant. So please give me the choice to have full memory in a single shot even though some or most of it doesn't show on screen right away.

Can you explain this a little better (not being argumentative, but I just don't understand)?  What is it you are looking for that can ONLY occur after the moment of acquisition?

for your reading pleasure, a separate 562 post thread on just that topic, linking to the context that nctnico intentionally leaves out (which makes this blatant inflammatory posting):
https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/msg3060638/#msg3060638
Dismissal of using a zoom window for... ill-defined/unsubstantiated reasons. Perhaps this forum will get another several thousand posts of crap on this topic over the next 10 years?

[Fungus]

it isn't really that much work even if it isn't what you're used to.

It should be zero work when it's something that's done as often as this.

I simply don't see the excuse for not fulling the memory when you press STOP.

(or use single trigger - same thing)

The STOP button is one of the single biggest features of a DSO.

[Someone]

it isn't really that much work even if it isn't what you're used to.

It should be zero work when it's something that's done as often as this.

I simply don't see the excuse for not fulling the memory when you press STOP.

Refer you back to the mega thread:
https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/
If the data is captured already for the stop button to hold it, then you've been having to capture that data on every trigger and slow the acheivable acquisition rate. If that is intended behaviour then it should be set and adjusted by the user, not the default. Using a zoom window adds more controls and makes the mode obvious, fewer controls, quicker to do, but takes up some of the visible screen. A trade off I'm very happy with and do not want swapped out.

[BillyO]

for your reading pleasure, a separate 562 post thread on just that topic

Okay, I get the gist (without reading all 562 posts).  So, with my background in mathematics and physics I can see absolutely no reason to assume that "some unknown event" would be more likely to occur after some arbitrary (arbitrary WRT "some unknown event") trigger point than before.  In fact, because the very nature of "some unknown event" being unknown, in it's very nature it can be proven mathematically that it must be just as likely to occur before the trigger point than after .. annnnd .. given the fixed amount of memory available (whatever that amount may be) there could be no possible advantage one way or the other since we cannot know when "some unknown event" might occur.  From a physics perspective, this is just slap in the face obvious.

The end result is that a "zoom out" or "scroll forward" feature is just a gimmick.  Like pink paint on your Cadillac.

Some people believe the earth is flat too.   

[Someone]

for your reading pleasure, a separate 562 post thread on just that topic

Okay, I get the gist (without reading all 562 posts).

You'd think if it was such a killer feature then one of the proponents would be able to show us some screen shots of an (even a contrived) example where it is beneficial. Instead we just get endless hand waving and arguing.

[bdunham7]

I simply don't see the excuse for not fulling the memory when you press STOP.

The memory is full either way when you press STOP.  Apparently you would prefer that it be filled with something different by default. 

[BillyO]

Instead we just get endless hand waving and arguing.

  Yup, the special imaginary advantages of cool gizmos.

[tggzzz]

Oh FFS
Please you 2 go get a room together, not one where the OP is attempting to get his head around the featureset of his first DSO.

I tend to agree.

I did post use-cases for which advanced features are used, but they were ignored.

[tggzzz]

...
for your reading pleasure, a separate 562 post thread on just that topic, linking to the context that nctnico intentionally leaves out (which makes this blatant inflammatory posting):
https://www.eevblog.com/forum/testgear/oscilloscope-zoom-out-quirk/msg3060638/#msg3060638
Dismissal of using a zoom window for... ill-defined/unsubstantiated reasons. Perhaps this forum will get another several thousand posts of crap on this topic over the next 10 years?

Interesting, for several reasons.

[tautech]

Oh FFS
Please you 2 go get a room together, not one where the OP is attempting to get his head around the featureset of his first DSO.

I tend to agree.

I did post use-cases for which advanced features are used, but they were ignored.

And rightly so.

Did you not walk before you could run......sure this stuff is pretty straight forward to many of us but some need a helping hand before just getting past basic features.

[tggzzz]

Oh FFS
Please you 2 go get a room together, not one where the OP is attempting to get his head around the featureset of his first DSO.

I tend to agree.

I did post use-cases for which advanced features are used, but they were ignored.

And rightly so.

Did you not walk before you could run......sure this stuff is pretty straight forward to many of us but some need a helping hand before just getting past basic features.

Often it is useful to be aware of use cases so that:

• you can recognise them when they arise
• you gain perspective of why certain features are present
• you choose the most appropriate tool for the job, e.g. avoiding using a hammer with screws

It is always useful to have knowledge that exceeds the current requirements. That way you know the boundaries, and that you haven't unwittingly strayed outside the boundaries.

However with modern DSOs the boundaries are a little like this[1]
https://www.google.co.uk/maps/place/Netherlands/@51.4459163,4.9256093,21z/data=!4m6!3m5!1s0x47c609c3db87e4bb:0xb3a175ceffbd0a9f!8m2!3d52.132633!4d5.291266!16zL20vMDU5ajI?entry=ttu
but that's an advantage, isn't it.

[1] to get the best understanding, slowly zoom out 4 or  5 times, concentrating on the boundaries

[nctnico]

If (part of) your work (like mine) consists of doing single shot measurements, then history doesn't matter. It is wasted memory because the previous measurement simply isn't relevant. So please give me the choice to have full memory in a single shot even though some or most of it doesn't show on screen right away.

Can you explain this a little better (not being argumentative, but I just don't understand)?  What is it you are looking for that can ONLY occur after the moment of acquisition?

I need to take you a step back here.

First of all: When you measure something, you want to be able to make a relation between cause and effect so you can draw a conclusion from the measurement result. This may sound obvious but for many it requires training to measure / collect data in a way so it is possible to establish a singular cause & effect relationship.

Secondly: I'm not looking at something which can only occur after the moment of acquisition. I just want 1 acquisition with as much data as possible so I can see what happened before AND after an event. I might not always need the data but with shorter memory DSOs I have often wished to have more data in order to have more information about what happened before and after an error condition. That can show the problem so it can be fixed right away or can give valueable glues on what to set triggers for and thus save a lot of time (and money) instead of poking around in the dark. Keep in mind that my typical measurements are for DUTs which are highly sequential through hardware and/or software.

Back to the history buffer: When I'm debugging / testing embedded firmware / FPGA / hardware, each single shot measurement represents a new version with a fix or change. Which means that whatever is in the history buffer is no longer relevant information as I won't be able to match a specific acquisition with a specific change somewhere. There is no way to draw a meaningfull conclusion from the data in the history buffer. So I rather have no history buffer at all if that means getting more memory for the current acquisition.

A history buffer is only usefull if you can record all relevant information in/by the oscilloscope itself (input versus output) without making changes to the DUT. That way you can draw a meaningfull conclusion from the acquisitions in the history buffer. Keep in mind though that a history buffer and segmented recording are functionally equal it is just that an automatic history buffer is easier to use / setup.

[Fungus]

Please post an example of where filling up the memory is worse.

(Or where not filling it up is better...)

[2N3055]

Please post an example of where filling up the memory is worse.

(Or where not filling it up is better...)

He cannot, because there is none.

If you need long capture you take a long capture (regardless how you do it, by setting manual long memory or long time base).
If you are at shorter time base you are using only small portion of memory so rest is either waisted for nothing or you can put history there and make it useful.

[Fungus]

It's not just about zooming, it's about panning left/right after STOP.

The Rigol DS1045Z's serial decoders were widely mocked for only being able to decode what was visible on screen.

To me the Siglent system seems like that except serial decoding was something I only did every other week but zooming/panning is something I do all the time.

[2N3055]

It's not just about zooming, it's about panning left/right after STOP.

The Rigol DS1045Z's serial decoders were widely mocked for only being able to decode what was visible on screen.

To me the Siglent system seems like that except serial decoding was something I only did every other week but zooming/panning is something I do all the time.

Why do you think you cannot move around captured buffer on Siglent? You can. Exactly the same as on any other scope.

[BillyO]

I need to take you a step back here.

First of all: When you measure something, you want to be able to make a relation between cause and effect so you can draw a conclusion from the measurement result. This may sound obvious but for many it requires training to measure / collect data in a way so it is possible to establish a singular cause & effect relationship.

Secondly: I'm not looking at something which can only occur after the moment of acquisition. I just want 1 acquisition with as much data as possible so I can see what happened before AND after an event. I might not always need the data but with shorter memory DSOs I have often wished to have more data in order to have more information about what happened before and after an error condition. That can show the problem so it can be fixed right away or can give valueable glues on what to set triggers for and thus save a lot of time (and money) instead of poking around in the dark. Keep in mind that my typical measurements are for DUTs which are highly sequential through hardware and/or software.

Back to the history buffer: When I'm debugging / testing embedded firmware / FPGA / hardware, each single shot measurement represents a new version with a fix or change. Which means that whatever is in the history buffer is no longer relevant information as I won't be able to match a specific acquisition with a specific change somewhere. There is no way to draw a meaningfull conclusion from the data in the history buffer. So I rather have no history buffer at all if that means getting more memory for the current acquisition.

A history buffer is only usefull if you can record all relevant information in/by the oscilloscope itself (input versus output) without making changes to the DUT. That way you can draw a meaningfull conclusion from the acquisitions in the history buffer. Keep in mind though that a history buffer and segmented recording are functionally equal it is just that an automatic history buffer is easier to use / setup.

I respectfully remain unconvinced.  I think you have convinced yourself of an advantage that is not there.

Besides, there is a way to do exactly what you want by setting up your capture properly - and in this case you can place your trigger point any where you like in the data captured.  Zoom = Pink Cadillac.  Only has merit to those that "like it".

[nctnico]

I need to take you a step back here.

First of all: When you measure something, you want to be able to make a relation between cause and effect so you can draw a conclusion from the measurement result. This may sound obvious but for many it requires training to measure / collect data in a way so it is possible to establish a singular cause & effect relationship.

Secondly: I'm not looking at something which can only occur after the moment of acquisition. I just want 1 acquisition with as much data as possible so I can see what happened before AND after an event. I might not always need the data but with shorter memory DSOs I have often wished to have more data in order to have more information about what happened before and after an error condition. That can show the problem so it can be fixed right away or can give valueable glues on what to set triggers for and thus save a lot of time (and money) instead of poking around in the dark. Keep in mind that my typical measurements are for DUTs which are highly sequential through hardware and/or software.

Back to the history buffer: When I'm debugging / testing embedded firmware / FPGA / hardware, each single shot measurement represents a new version with a fix or change. Which means that whatever is in the history buffer is no longer relevant information as I won't be able to match a specific acquisition with a specific change somewhere. There is no way to draw a meaningfull conclusion from the data in the history buffer. So I rather have no history buffer at all if that means getting more memory for the current acquisition.

A history buffer is only usefull if you can record all relevant information in/by the oscilloscope itself (input versus output) without making changes to the DUT. That way you can draw a meaningfull conclusion from the acquisitions in the history buffer. Keep in mind though that a history buffer and segmented recording are functionally equal it is just that an automatic history buffer is easier to use / setup.

I respectfully remain unconvinced.  I think you have convinced yourself of an advantage that is not there.

You are allowed to have your own opinion. I'm sorry I can't explain the advantages of zooming out better (they are definitely real, like not having to think about the precise trigger point!) and you feel the need to go down the ridiculing path instead of just respecting other people's ideas even if you don't fully understand them.