A newbie needs some help with my first DSO

[Someone]

To take a practical example, if I am trying to decode some messages on an SPI bus, here is what I think I am understanding: On the Siglent, I will need to show "all" of the messages on the screen to capture them - even though at that point they will be so squished together than I can't discern the content of any of the messages. Then, once capture, I can zoom in and scroll through to see the actual content of the messages. Have I got it right?

This is where you might want to explore the sequence/history mode, which can capture packets each on their own acquisition "screen" without all the quiet/empty bits in between. That will be quicker to step through but depends if there is enough gap between the data to cleanly separate them. Or use triggers to capture the message/signal/packet/byte that you are specifically interested in. Or as posted above, have the zoom window open so you can see both the long and short timeframe.

Using the horizontal timebase control alone is just one way to work, and unlikely the best way to navigate the data.

One more possibly related question. I feel rather dumb for asking this, but ... I think I have just begun to realize that the "trigger point" of the waveform on the screen is actually in the center of the screen (by default), meaning that the scope is showing me events that happened before the trigger. Is that correct? Unless I have completely forgotten what I have done in the past with my old analog Tektronix, this is very different behavior, as the analog scope starts the sweep at the trigger, meaning that anything prior to the trigger simply cannot be shown. Clearly this is a huge advantage for the DSO! And if I understand correctly, I can adjust the trigger point left and right, so that I see less of what happened prior to the trigger and more after, or vice versa.

This is where the deep/long memory is an advantage, you can put the trigger as far to the right as the memory will support! Viewing data from before the trigger with your own little time machine.

[Someone]

The link to Dave's video was actually very helpful for me in making sense of what memory depth is. I confess that i was assuming it would work more like the Keysight, which is part of why I was having trouble understanding - I hit "stop," but there was no data past the end of the screen. I think I am now understanding that, for the Siglent and a few others, what is captured is only what fits on the screen at a given moment - thus, one must zoom out, capture, then zoom in to see detail. Right? Maybe?

No, there is no extra detail from capturing a longer screen and then zooming in. If anything it presents the risk of capturing less high frequency detail if increasing the timebase caused the scope to reduce the sample rate (due to hitting its memory depth limit).

In run mode (not single capture mode) the keysight models do not capture around the visible window all the time, it's a "bonus" that occurs some times. Some other brands do it all the time, but that slows the update rate and triggers/information may never reach the screen:

[nctnico]

You have to realise though that when doing protocol decoding, you don't want multiple trigger events in a single screen because the protocol decoding can decode one trace only. So typically triggering is set to normal and the signals are generated by instructing the DUT to do so. All in all a very slow process which doesn't need fast waveform updates at all. In most cases you want a record which is as long as possible. Capturing beyond the screen helps to look at the cause & effect of what has been captured. For example: sometimes there is a surprise and having more data is extremely helpfull to catch would could become an elusive bug, early on in the development process. But even without a need, capturing beyond the screen typically makes it not necessary to mess with the oscilloscope settings before having the DUT sending new data. Just scrolling left / right a bit to bring the section of interest on screen is enough.

[bdunham7]

But now that I know, it all seems so simple, and I feel so delightfully empowered ...

Lots of memory points are handy on occasion, but to really be able to use an oscilloscope you have to understand triggering.  And that is not simple.  Most scope work (or at least a lot of it) can be done with a few thousand points.  I even have one with less than 1k points and while that can be a limitation, it is pretty good at what it does.

[Someone]

Capturing beyond the screen helps to look at the cause & effect of what has been captured.

You're really going to push your single minded position that this is the true/only/correct way to do things? While conveniently avoiding mentioning the use of a zoom window to see everything simultaneously without any hidden surprises...

and people wonder why the signal to noise is so low here.

 

[tggzzz]

But now that I know, it all seems so simple, and I feel so delightfully empowered ...

Lots of memory points are handy on occasion, but to really be able to use an oscilloscope you have to understand triggering.  And that is not simple.  Most scope work (or at least a lot of it) can be done with a few thousand points.  I even have one with less than 1k points and while that can be a limitation, it is pretty good at what it does.

Very true.

For complex triggers related to digital signals, logic analysers and protocol analysers excel. They are much more effective (than scopes) at reducing the amount of non-information the user needs to ignore. That leaves us to concentrate on the useful information.

As with all things, carefully select the right type of tool for the task.

[nctnico]

Capturing beyond the screen helps to look at the cause & effect of what has been captured.

You're really going to push your single minded position that this is the true/only/correct way to do things? While conveniently avoiding mentioning the use of a zoom window to see everything simultaneously without any hidden surprises...

I'm not pushing anything on anyone. I want to show what is possible; how making measurements can be more efficient and effective. Just showing how to potentially use a tool more effectively depending on the situation. I leave the choice to the reader to judge whether it is useful for them or not. It is actually you who wants take options away from people in order to make everyone adhere to your limited, single minded way of thinking.

In the end there are more ways to skin a cat and some problems are better solved using a different approach which may not be obvious to those who never deal with such problems. You are kind of like my neurologist telling my surgeon on how to operate on my wrist. The neurologist complained the surgeon wanted to make a large cut in the palm of my hand leaving a big scar so his suggestion was to make a small cut on my wrist what would result in a much smaller scar. What the surgeon knew is that he could blend the scar in with one of the many creases in the palm of my hand and thus making the larger scar invisible. The neurologist overlooked that as surgery is not his field of expertise. Both have studied medicine, both are medical doctors but then specialisations and problems they deal with diverted.

[2N3055]

But now that I know, it all seems so simple, and I feel so delightfully empowered ...

Lots of memory points are handy on occasion, but to really be able to use an oscilloscope you have to understand triggering.  And that is not simple.  Most scope work (or at least a lot of it) can be done with a few thousand points.  I even have one with less than 1k points and while that can be a limitation, it is pretty good at what it does.

Very true.

For complex triggers related to digital signals, logic analysers and protocol analysers excel. They are much more effective (than scopes) at reducing the amount of non-information the user needs to ignore. That leaves us to concentrate on the useful information.

As with all things, carefully select the right type of tool for the task.

Since it is a beginner asking, you better explain what type of device you consider "logic analysers and protocol analysers".
Devices you are referring to are not manufactured anymore.

Today when you say "logic analysers and protocol analysers" people think you mean Saleae type USB device.
Which basically have no triggering to speak of, only very rudimentary one.
Actually, one of the reasons why some people buy MSO scopes is that they have better triggering than Saleae type devices.

[tautech]

To take a practical example, if I am trying to decode some messages on an SPI bus, here is what I think I am understanding: On the Siglent, I will need to show "all" of the messages on the screen to capture them - even though at that point they will be so squished together than I can't discern the content of any of the messages. Then, once capture, I can zoom in and scroll through to see the actual content of the messages. Have I got it right?

To a point.
Ideally we always want to see a truly stable waveform which signifies trigger settings are correct at least for basic decoding.
While there are several shortcuts to get a result my advice to get accustomed to the absolute power of the trigger suite you have.
Some KISS examples using a single channel for UART.

To get a properly stable waveform you need to prevent retriggering within a packet using a Holdoff time setting a little longer than a packet. How long is a packet is the first thing we need to know and for this we need get a few packets on the display and press Stop and eyeball its width against the graticules.
For these examples a 60ms Holdoff is just adequate to get rock solid stable triggering.
However, while we are still in the trigger menu, we need set the correct edge which for most protocols is Idle High so we need a falling edge trigger to mark the beginning of packet data.

Now we should have sound triggering however with the H Pos mid display there's only half the display to show full packets and their decode so we need move H Pos to the left with the encoder and set it in place with Utility/System Settings/Ref Position with H Pos set to Position.

The back of the job is now broken and just decode settings remain, assigning the correct channel/s and Threshold levels, Idle High in this case, baud rate etc.

As has been discussed Zoom mode can be useful now to display a # of packets to permit panning through them and the zoomed window for each packet decode or each byte.

Hoping the attached screenshots are of assistance.

[Someone]

Capturing beyond the screen helps to look at the cause & effect of what has been captured.

You're really going to push your single minded position that this is the true/only/correct way to do things? While conveniently avoiding mentioning the use of a zoom window to see everything simultaneously without any hidden surprises...

I'm not pushing anything on anyone. I want to show what is possible

By only suggesting a single method that is inferior in the majority of situations? That's not one-sided, misleading, or pushing at all.... [/s]

Persuasive language and trying to claim the majority in a corner case you invented is disingenuous. Misleading. Adding noise.

As always you conveniently leave out all the preconditions nesscecary for your corner case to be valid, and then conveniently expect people new to the conversation to already know that. Awful lot of hand waving and misdirection to push your nonsense for some reason.

Want to present it plainly/fairly? You won't get any push back, but rather you come back time and time again with the inflammatory and leading pronouncements.

[awakephd]

To take a practical example, if I am trying to decode some messages on an SPI bus, here is what I think I am understanding: On the Siglent, I will need to show "all" of the messages on the screen to capture them - even though at that point they will be so squished together than I can't discern the content of any of the messages. Then, once capture, I can zoom in and scroll through to see the actual content of the messages. Have I got it right?

To a point.
Ideally we always want to see a truly stable waveform which signifies trigger settings are correct at least for basic decoding.
While there are several shortcuts to get a result my advice to get accustomed to the absolute power of the trigger suite you have.
Some KISS examples using a single channel for UART.

To get a properly stable waveform you need to prevent retriggering within a packet using a Holdoff time setting a little longer than a packet. How long is a packet is the first thing we need to know and for this we need get a few packets on the display and press Stop and eyeball its width against the graticules.
For these examples a 60ms Holdoff is just adequate to get rock solid stable triggering.
However, while we are still in the trigger menu, we need set the correct edge which for most protocols is Idle High so we need a falling edge trigger to mark the beginning of packet data.

Now we should have sound triggering however with the H Pos mid display there's only half the display to show full packets and their decode so we need move H Pos to the left with the encoder and set it in place with Utility/System Settings/Ref Position with H Pos set to Position.

The back of the job is now broken and just decode settings remain, assigning the correct channel/s and Threshold levels, Idle High in this case, baud rate etc.

As has been discussed Zoom mode can be useful now to display a # of packets to permit panning through them and the zoomed window for each packet decode or each byte.

Hoping the attached screenshots are of assistance.

I was able to follow some of that ... will have to sit down and try actually to decode a signal in order to see if I truly understood or not. Unfortunately, this weekend is tied up with a trip, so it may be a few days before I get time.

[tggzzz]

I was able to follow some of that ... will have to sit down and try actually to decode a signal in order to see if I truly understood or not. Unfortunately, this weekend is tied up with a trip, so it may be a few days before I get time.

Can I suggest starting with a signal you know, either:

• a "simple" standard like a square wave with 0.1% duty cycle and sharp edges
• a complex serial stream like a program "printing" A...Za...z to a UART, with/without spaces between the characters

[awakephd]

Can I suggest starting with a signal you know, either:

• a "simple" standard like a square wave with 0.1% duty cycle and sharp edges
• a complex serial stream like a program "printing" A...Za...z to a UART, with/without spaces between the characters

Oh, believe me, I am starting simple. Last night I set up an ATTiny84 to output 0 - 254 on 8 of its pins - nice, simple square waves of varying frequencies to test, try out the various available measurements, etc. I even did an FFT, not that I truly know enough about FFTs to understand how to set it up or what I was seeing as a result ...

[tggzzz]

Can I suggest starting with a signal you know, either:

• a "simple" standard like a square wave with 0.1% duty cycle and sharp edges
• a complex serial stream like a program "printing" A...Za...z to a UART, with/without spaces between the characters

Oh, believe me, I am starting simple. Last night I set up an ATTiny84 to output 0 - 254 on 8 of its pins - nice, simple square waves of varying frequencies to test, try out the various available measurements, etc. I even did an FFT, not that I truly know enough about FFTs to understand how to set it up or what I was seeing as a result ...

FFT of digital signals...

The square wave's period shows up in the frequency domain as the fundamental frequency plus odd harmonics.
The highest harmonic is determined by the transition time; the period is irrelevant.
Varying the duty cycle changes the amplitude of the low frequency harmonics, but the high frequency harmonics are unaffected.

Maybe https://entertaininghacks.wordpress.com/2018/05/08/digital-signal-integrity-and-bandwidth-signals-risetime-is-important-period-is-irrelevant/ might help a little by confirming the theory you will learn.

But learning how to trigger on characters emitted by a UART is a useful way of understanding your scope's capabilities. Doubly so when comparing it with a logic or protocol analyser.

[OLderDan]

...But learning how to trigger on characters emitted by a UART is a useful way of understanding your scope's capabilities. Doubly so when comparing it with a logic or protocol analyser.

First I want to thank OP for starting such an interesting thread, but, I get here and the story just stops?

[vk6zgo]

In the early days of DSOs, memory depth was of much greater instant impact on everyday use of a 'scope to look at complex analog signals.
One standard use was to look at one, or several analog video fields, to look at aberrations on the blanking level & sync part of the waveforms.

To this end, to accommodate the around 40ms duration of two fields, the 'scope would be set to around 5ms/div.
Early DSOs often quoted quite decent sample rates, but these were only valid for much faster time/div settings.

At these slow timebase rates, the memory would soon run out of capacity, so as the sweep time was increased, the sample rate was reduced, until a complex wideband video signal became totally unrecognisable.

Over time, memory depth slowly, then rapidly, increased, until that original problem has pretty much disappeared with decent affordable DSOs, & the other niceties of memory depth have become the primary topics of discussion.

There are still DSOs available which are sufficiently low in memory depth that the old problem raises its head. They are usually very cheap, or old.

[Electro Fan]

Today when you say "logic analysers and protocol analysers" people think you mean Saleae type USB device.
Which basically have no triggering to speak of, only very rudimentary one.

2N3055, please elaborate on why this is and why LA makers don’t include more/better triggering?
(Clearly digital only LA’s can’t trigger on analog signals but once a signal is in a digital realm specifying trigger conditions should not be too hard - yes?). Thx

[2N3055]

Today when you say "logic analysers and protocol analysers" people think you mean Saleae type USB device.
Which basically have no triggering to speak of, only very rudimentary one.

2N3055, please elaborate on why this is and why LA makers don’t include more/better triggering?
(Clearly digital only LA’s can’t trigger on analog signals but once a signal is in a digital realm specifying trigger conditions should not be too hard - yes?). Thx

I'm afraid I don't know why they don't.
I would presume it is because many of those USB protocol decoders (like Saleae) are simple USB streaming devices that have no logic on primary hardware side, but simply stream data to software.
There are some USB LA/PA that have some logic, and have various degree of triggering, but you need to search for them.
But even those don't have very sophisticated triggering that old LA used to have.

[nctnico]

With more memory, triggering becomes less important. Especially on a logic analyser which has a capture -analysis workflow. I have a high-end logic analyser from Tektronix with a programmable trigger statemachine which can trigger on sequential and logical conditions beyond your wildest dreams. But it is extremely rare that I use that feature. My logic analyser has so much memory and a time stamped mode that it can collect extremely long time spans. In many cases I don't care about a trigger condition, I just hit the 'run' button to make a single acquisition. That single acquisition has all the information I need. The search & analysis features of the software help me to find problem areas and correlate cause & effect. Then again, I fire my logic analyser up when my MSO runs out of steam but that is unlikely to happen. I find myself using an MSO for 99% of the measurements I used to use a logic analyser for.

My first logic analyser only had like 1kpts or 2kpts of memory. Triggering on very specific conditions was very important as the memory was short. Getting a full picture of cause & effect typically required taking at least several measurements, storing / retrieving data and comparing. It did the job but getting a result (as in identify a problem) could take very long.

[tggzzz]

With more memory, triggering becomes less important. Especially on a logic analyser which has a capture -analysis workflow. I have a high-end logic analyser from Tektronix with a programmable trigger statemachine which can trigger on sequential and logical conditions beyond your wildest dreams. But it is extremely rare that I use that feature. My logic analyser has so much memory and a time stamped mode that it can collect extremely long time spans. In many cases I don't care about a trigger condition, I just hit the 'run' button to make a single acquisition. That single acquisition has all the information I need. The search & analysis features of the software help me to find problem areas and correlate cause & effect. Then again, I fire my logic analyser up when my MSO runs out of steam but that is unlikely to happen. I find myself using an MSO for 99% of the measurements I used to use a logic analyser for.

My first logic analyser only had like 1kpts or 2kpts of memory. Triggering on very specific conditions was very important as the memory was short. Getting a full picture of cause & effect typically required taking at least several measurements, storing / retrieving data and comparing. It did the job but getting a result (as in identify a problem) could take very long.

The key point about complex triggers and filters is that they reduce the amount of "noise" in the captured data. Reduced "noise" reduces the importance of long capture buffers. While I will, reluctantly, eyeball 1kSamples of data, there's no way I'm going to trawl through 10MSamples of data!

I'll discuss this in "logic analyser terms"; the equivalents with protocol analysers shouldn't be difficult to work out

The simplest kind of filter is "clock rising edge", since that removes crap that is irrelevant to your state machine implementation. If you have a 1kHz state machine clock and sample at 10MS/s, that immediately removes 99.9% of the "data".

The next kind of filter is to only look at information to/from one device on a bus. Sometimes the filter can be as simple as a single CE line, sometimes it involves recognising an address.

Closely allied to that is only capturing information in (filtering) or after (arming/triggering) your FSM has entered a specific state.

In many cases you want to be able to demonstrate that something has not occurred. In such cases the capture depth is, of course, irrelevant; you just let the analyser rip and hope/expect to see it still waiting when you return after your coffee break. That kind of analysis is difficult without

[nctnico]

With more memory, triggering becomes less important. Especially on a logic analyser which has a capture -analysis workflow. I have a high-end logic analyser from Tektronix with a programmable trigger statemachine which can trigger on sequential and logical conditions beyond your wildest dreams. But it is extremely rare that I use that feature. My logic analyser has so much memory and a time stamped mode that it can collect extremely long time spans. In many cases I don't care about a trigger condition, I just hit the 'run' button to make a single acquisition. That single acquisition has all the information I need. The search & analysis features of the software help me to find problem areas and correlate cause & effect. Then again, I fire my logic analyser up when my MSO runs out of steam but that is unlikely to happen. I find myself using an MSO for 99% of the measurements I used to use a logic analyser for.

My first logic analyser only had like 1kpts or 2kpts of memory. Triggering on very specific conditions was very important as the memory was short. Getting a full picture of cause & effect typically required taking at least several measurements, storing / retrieving data and comparing. It did the job but getting a result (as in identify a problem) could take very long.

The key point about complex triggers and filters is that they reduce the amount of "noise" in the captured data. Reduced "noise" reduces the importance of long capture buffers. While I will, reluctantly, eyeball 1kSamples of data, there's no way I'm going to trawl through 10MSamples of data!

Well, you don't have to trawl to 10Msamples of data. Just select part of the acquisition and let the analysis tools do their job to answer questions like minimum / maximum setup & hold, number of clock pulses in an interaction / burst, frequency, etc. Typically I'm interested whether a design behaves the way I intend it to behave so there are no hidden surprises lurking. There are many ways something may appear to work only to fall apart when the cirumstances are slightly different. Having one acquisition to do analysis on is much easier compared to setting different triggers and re-measure for every detail you want to check. And even if you set triggers to detect fault situations, you will want to have as much data as possible to see what lead to the fault c.q. what where the circumstances. Otherwise you only know a fault occured without a clue on how to reproduce it.

[tggzzz]

With more memory, triggering becomes less important. Especially on a logic analyser which has a capture -analysis workflow. I have a high-end logic analyser from Tektronix with a programmable trigger statemachine which can trigger on sequential and logical conditions beyond your wildest dreams. But it is extremely rare that I use that feature. My logic analyser has so much memory and a time stamped mode that it can collect extremely long time spans. In many cases I don't care about a trigger condition, I just hit the 'run' button to make a single acquisition. That single acquisition has all the information I need. The search & analysis features of the software help me to find problem areas and correlate cause & effect. Then again, I fire my logic analyser up when my MSO runs out of steam but that is unlikely to happen. I find myself using an MSO for 99% of the measurements I used to use a logic analyser for.

My first logic analyser only had like 1kpts or 2kpts of memory. Triggering on very specific conditions was very important as the memory was short. Getting a full picture of cause & effect typically required taking at least several measurements, storing / retrieving data and comparing. It did the job but getting a result (as in identify a problem) could take very long.

The key point about complex triggers and filters is that they reduce the amount of "noise" in the captured data. Reduced "noise" reduces the importance of long capture buffers. While I will, reluctantly, eyeball 1kSamples of data, there's no way I'm going to trawl through 10MSamples of data!

Well, you don't have to trawl to 10Msamples of data. Just select part of the acquisition and let the analysis tools do their job to answer questions like minimum / maximum setup & hold, number of clock pulses in an interaction / burst, frequency, etc. Typically I'm interested whether a design behaves the way I intend it to behave so there are no hidden surprises lurking. There are many ways something may appear to work only to fall apart when the cirumstances are slightly different. Having one acquisition to do analysis on is much easier compared to setting different triggers and re-measure for every detail you want to check. And even if you set triggers to detect fault situations, you will want to have as much data as possible to see what lead to the fault c.q. what where the circumstances. Otherwise you only know a fault occured without a clue on how to reproduce it.

Those examples are little more than glorified signal integrity problems.

If you look the points I made and you snipped, you will realise that they are about more complex "higher" level specification and implementation issues.

[nctnico]

No, definitely not signal integrity issues. The difference between your and mine approach is that you want to catch things you think might be wrong. OTOH, I want to see that what seems to be working correctly is actually correct. For example: I don't want to just check the messages I expect on a bus but also check if there aren't any unexpected messages on a bus. That offers a much higher degree of test coverage. But it requires acquiring & analysing much more data.

[tggzzz]

No, definitely not signal integrity issues. The difference between your and mine approach is that you want to catch things you think might be wrong. OTOH, I want to see that what seems to be working correctly is actually correct. For example: I don't want to just check the messages I expect on a bus but also check if there aren't any unexpected messages on a bus. That offers a much higher degree of test coverage. But it requires acquiring & analysing much more data.

I wrote glorified signal integrity tests, as a shorthand.

Your understanding of my test objectives.and techniques is flawed.

[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.