New Scope Demoboard from Batronix

[rpro]

For others, this is the "Hf Test Track" section.
Mainly responsible are two fast risetime logic gate ICs (tr<450ps), one IC is directly connected to the RF out BNC socket, so that you have a quite fast pulse at the start.
The signal also looks pretty clean.

Here is how it looks with the DHO804(924) and MSO5000. More "ringing" on MSO than DHO, though no undershoot before rise edge on both (similar to your Lecroy WR9054 pic).

[Grandchuck]

More Batronix board learning via mostly trial and error.  This is with SW1 set to C which selects a 10 kHz sine with peaks after X periods.  Using channel 1 for pulse triggering is straightforward.  Using channel 2 is more finicky. 

This makes me wonder what folks do when they have no idea what kind of a glitch or anomaly they are looking for.  Do they use single sweep repeatedly until they spot something and then zoom/expand to investigate and go from there to set up an appropriate trigger?

[ebastler]

This makes me wonder what folks do when they have no idea what kind of a glitch or anomaly they are looking for.  Do they use single sweep repeatedly until they spot something and then zoom/expand to investigate and go from there to set up an appropriate trigger?

I would let the scope acquire in RUN mode, triggering on the normally recurring signal, and watch out for weak traces which are out of the ordinary. Switching on color grading may help to make those weak (i.e. rare) traces more prominent. 

[2N3055]

More Batronix board learning via mostly trial and error.  This is with SW1 set to C which selects a 10 kHz sine with peaks after X periods.  Using channel 1 for pulse triggering is straightforward.  Using channel 2 is more finicky. 

This makes me wonder what folks do when they have no idea what kind of a glitch or anomaly they are looking for.  Do they use single sweep repeatedly until they spot something and then zoom/expand to investigate and go from there to set up an appropriate trigger?

You can use persistence, or you can also use mask mode, where you create mask that is few percent larger than signal (auto mask function) and then let it run. In mask mode you can also save violations into history and inspect them later.

[tautech]

More Batronix board learning via mostly trial and error.  This is with SW1 set to C which selects a 10 kHz sine with peaks after X periods.  Using channel 1 for pulse triggering is straightforward.  Using channel 2 is more finicky. 

This makes me wonder what folks do when they have no idea what kind of a glitch or anomaly they are looking for.  Do they use single sweep repeatedly until they spot something and then zoom/expand to investigate and go from there to set up an appropriate trigger?

A Pulse trigger will find this when set correctly.

An example using Search feature and a Pulse trigger with SDS1104X-E.
https://www.eevblog.com/forum/testgear/siglent-sds1204x-e-released-for-domestic-markets-in-china/msg1370717/#msg1370717

[Martin72]

A Pulse trigger will find this when set correctly.

If you know what you're looking for...
He asked how you generally get to it first before you target it with a more specific trigger.
With the demo boards, I know because I have selected a corresponding signal.

[Performa01]

This makes me wonder what folks do when they have no idea what kind of a glitch or anomaly they are looking for.  Do they use single sweep repeatedly until they spot something and then zoom/expand to investigate and go from there to set up an appropriate trigger?

That's the beauty of a History that's always running silently in the background: You need not sit and wait for something unusual to happen, you just work as usual. Whenever you notice something unusual in the corner of your eye, you just hit the Stop button. Then you can browse the History (either play it back at any arbitrary speed or go through it frame by frame) until you find the suspicious record.

Now you have all the time in this world to analyze the data to your hearts content, using all the tools the SDS is offering and you will be able to figure out a suitable trigger so that you can reliably capture that specific event in the future.

[pdenisowski]

This makes me wonder what folks do when they have no idea what kind of a glitch or anomaly they are looking for.  Do they use single sweep repeatedly until they spot something and then zoom/expand to investigate and go from there to set up an appropriate trigger?

Depends on the anomaly Many (most?) scopes have a glitch, runt, or width trigger for finding pulses that are the "wrong" level or duration.  There are also timeout triggers for when signals get "stuck" at a certain level, and masks or zone triggers are also useful for finding signals that diverge too far from expected values. 

I have a video that talks about the different trigger types (and how they are implemented on one of our oscilloscopes)



(Note that he Batronix demo board manual actually uses this scope - the MXO - for most of their examples)

[2N3055]

This makes me wonder what folks do when they have no idea what kind of a glitch or anomaly they are looking for.  Do they use single sweep repeatedly until they spot something and then zoom/expand to investigate and go from there to set up an appropriate trigger?

Depends on the anomaly Many (most?) scopes have a glitch, runt, or width trigger for finding pulses that are the "wrong" level or duration.  There are also timeout triggers for when signals get "stuck" at a certain level, and masks or zone triggers are also useful for finding signals that diverge too far from expected values. 

I have a video that talks about the different trigger types (and how they are implemented on one of our oscilloscopes)



(Note that he Batronix demo board manual actually uses this scope - the MXO - for most of their examples)

Nice video, as always.

Even most basic scopes nowadays have pretty much what would be "very advanced set of triggers" just 10 years ago....

It is quite easy to look at nonmonotonic edges or risetimes, pulse widths that are less or more than they should be, runts, dropouts, setup times violations etc etc..
You setup triggers for it and then wait. On scopes with all time running history you can also go back and shuffle through violations etc..

But question was about how do you find something that you don't already know how to search for.

In most scopes you can only use persistence (waiting to catch something on the screen that will give you some clues what to look for in more specific terms), or mask test. With mask test you have also on some scopes capability to save all violations for later (in history) or do some other stuff with it.

As an example, on Siglent and LeCroy scopes you also have deep memory measurements where you can setup several measurements simultaneously and use statistics and histicons to look at distribution of certain parameters.
This is very powerful technique to verify parameters of signals.
For instance you measure pulse period, P-P voltage, risetime, etc.
And let scope run for some time. You end up with statistics for millions of periods with statistical distribution right there.
And if distribution is tight and shape is Gausian (meaning stohastic) you have nice stable signal.
If distribution is multimodal (more than one peak in histogram), then you have some discrete states of the sistem influencing that parameter.
If you measure pulse period (or frequency, same difference, 1/t) and you get distribution that looks like bathtub, that means that signal is frequency modulated, and specifically with sinusoidal modulation...

So with good analytical tools, it is not about staring into the screen waiting for something to happen. It is about configuring the scope to do the hunting for you, and automating tedious work.

And then having an insight that this, this and this parameter seems to be "wondering around" you can tailor triggers to catch it "red handed" and try to correlate anomaly with other parts of the system to try and catch what causes it.

Advantage of this approach is that you quickly start not only to know "something" is wrong, but you start to analyze, understand and quantify signal qualities from the start.

More advanced scopes have SignalScan/Wavescan type of tools. Those tools practically automatically do some steps for you, isolating certain parts of signal with characteristics that seem to be statistical outliers, for operators consideration... These tools might assist you to create needed triggers and such.

Nice timesaver, but using proper steps you can actually achieve most of that manually, if scope has the rest of basic capabilities.

[Grandchuck]

I tried the persistence advice and saw some benefit.  Trying to create a mask around the glitch produced a lockup instead.  Learning can be painful

[RAPo]

Is there a kind of flowchart that, based on a description of the signal characteristics, gives you a step-by-step procedure for selecting and setting up a trigger(type)?

For instance, I have a 100kHz ramp signal with an anomaly: once in a while (not constant), the signal goes away for some time and starts again. I would like to know the "blackout" period.
What are the steps to set up the scope and answer my question?

[Grandchuck]

Persistence ON and OFF.

[pdenisowski]

Is there a kind of flowchart that, based on a description of the signal characteristics, gives you a step-by-step procedure for selecting and setting up a trigger(type)?

For instance, I have a 100kHz ramp signal with an anomaly: once in a while (not constant), the signal goes away for some time and starts again. I would like to know the "blackout" period.
What are the steps to set up the scope and answer my question?

Sounds like a timeout trigger:  the scope should be configured to trigger when the signal level is < X volts for more than Y seconds. Assuming that the time/div is set properly, you should be able to acquire the entire "blackout" period and measure the time using markers.  Since the scope will trigger when the ramp resumes, you might also want to apply a trigger offset so that the ramp restart is near the right edge of the screen.

If you have (or would like to see this on) a R&S MXO oscilloscope, I'd be happy to set it up and post a short video.

(There are other ways of doing this, but that's the first that comes to mind).

[ebastler]

Persistence ON and OFF.

The glitches produced by the demo board are still pretty frequent; so I would say the non-persistent view actually gives a better idea in this case that it is indeed a glitch. But if the glitches are rarer, they might only pop up occasionally if you set a short or no persistence time, and could be easily overlooked.

Have you tried colour grading? I find that it nicely highlights the rare events in a different color, and does not render them as dimly as intensity grading does in some situations.

[Grandchuck]

Color grading and persistence.

[Grandchuck]

Changed the Batronix board to a low glitch frequency.  Now it takes a while for them to appear.  With a glitch frequency of 0.2 Hz, one trial took a full minute for the first one to show up.

[Njk]

So with good analytical tools, it is not about staring into the screen waiting for something to happen. It is about configuring the scope to do the hunting for you, and automating tedious work.

And then having an insight that this, this and this parameter seems to be "wondering around" you can tailor triggers to catch it "red handed" and try to correlate anomaly with other parts of the system to try and catch what causes it.

Advantage of this approach is that you quickly start not only to know "something" is wrong, but you start to analyze, understand and quantify signal qualities from the start.

True, but also the other considerations (just to be fair):

- It's virtually impossible to construct a trigger that will catch every particular event in the real application case;

-  One can give many examples when all the advanced capabilities are absolutely necessary, but other one can give at least equal number of examples when all that wonders are entirely optional;

- The instrument that I don't know is useless for me. So more overhead by the learning curve, which does not depend on application;

- The cost of really advanced instrument can be really high. No way to afford it without having a lot of associated obligations. Imagine a young graduate who is deeply indebted by tuition fees, certification, licensing, etc., so he have to pay his debt during all his career. Not a slavery, but servitude seems a correct word. A modern method for causing an individual to work hard;

- In general, reliance on an advanced tool that you can't DIY weakens you because that increases your dependency on a service provided by other people.

[2N3055]

So with good analytical tools, it is not about staring into the screen waiting for something to happen. It is about configuring the scope to do the hunting for you, and automating tedious work.

And then having an insight that this, this and this parameter seems to be "wondering around" you can tailor triggers to catch it "red handed" and try to correlate anomaly with other parts of the system to try and catch what causes it.

Advantage of this approach is that you quickly start not only to know "something" is wrong, but you start to analyze, understand and quantify signal qualities from the start.

True, but also the other considerations (just to be fair):

- It's virtually impossible to construct a trigger that will catch every particular event in the real application case;

-  One can give many examples when all the advanced capabilities are absolutely necessary, but other one can give at least equal number of examples when all that wonders are entirely optional;

- The instrument that I don't know is useless for me. So more overhead by the learning curve, which does not depend on application;

- The cost of really advanced instrument can be really high. No way to afford it without having a lot of associated obligations. Imagine a young graduate who is deeply indebted by tuition fees, certification, licensing, etc., so he have to pay his debt during all his career. Not a slavery, but servitude seems a correct word. A modern method for causing an individual to work hard;

- In general, reliance on an advanced tool that you can't DIY weakens you because that increases your dependency on a service provided by other people.

I'm a bit confused as what are you trying to say, honestly.

All the advanced tools I mention (except WaveScan) are actually present on this inexpensive scope. That is why I think it is really a game changer. They don't exist on Rigols, some not even on many R&S and Keysight scopes.

And I also mentioned that WaveScan, while very nice and fancy and time saver is not strictly necessary.
It merely automates manual process.
I think you misunderstood what I meant by advanced tools. I didn't mean automated protocol verification applications and such. I call those specialized tools and they are not necessary most of the time. They are mostly used in industrial environment when you want to make sure process of verification is standardized, and when time saved testing and creating documentation will pay off.

As for triggers, I'm pretty sure you can not make single trigger that will catch all possible anomalies. But first you analyze signal and then you go through set (several) of triggers and verifications, that together serve to verify all practical combinations.

As for "servitude" and depending on advanced tools...
That is slippery slope, thinking like that. That is my opinion.

I understand your meaning (as for instance Altium users might sympathize with the sentiment, strongly), but how long you can go before you are simply creating unnecessary problems for yourself.
Shall we go back to pen and paper, if you get what I mean?

Thank you for interesting post.

Best,

[ebastler]

I understood njk to mainly say that there still is value in looking at the waveform (with the help of persistence, color grading etc.).

And I tend to agree; it is often the fastest way to get a first idea of what's wrong. Let's stick with the sine wave example from the demo board: If you didn't know whether it suffers from spikes or dropouts (at whichever levels), or maybe from sporadic phase jitter, I would argue that you can spend a lot of time thinking about the right set of measurements and histograms which will catch and discriminate the various types of potential glitches. While visually most of them will be very easy to make out -- maybe with the help of peak detection to get very short spikes.

Those devices are called oscilloscopes for a reason -- in addition to all the analytics, they are pretty handy for looking at wiggly lines. 

[2N3055]

I understood njk to mainly say that there still is value in looking at the waveform (with the help of persistence, color grading etc.).

And I tend to agree; it is often the fastest way to get a first idea of what's wrong. Let's stick with the sine wave example from the demo board: If you didn't know whether it suffers from spikes or dropouts (at whichever levels), or maybe from sporadic phase jitter, I would argue that you can spend a lot of time thinking about the right set of measurements and histograms which will catch and discriminate the various types of potential glitches. While visually most of them will be very easy to make out -- maybe with the help of peak detection to get very short spikes.

Those devices are called oscilloscopes for a reason -- in addition to all the analytics, they are pretty handy for looking at wiggly lines. 

Well of course you are looking at the screen. For sure you're not looking into your belly button....

But just staring at waveform is VERY limited in what you can do with it.
Trick is to reduce amount of just staring by getting insight into signal.

Of course, if you have something happening every 100 periods, that you will catch quickly just by watching.
Or shall I say you will notice something is there. Then you still have to correlate that thing you saw into physical world, to the reason why anomaly is there.

It is not "stare at your signal". More like "know your signal".
Of course , for obvious things, it will be, well, obvious....

[KungFuJosh]

Well of course you are looking at the screen. For sure you're not looking into your belly button....

Dagnabbit! Why do I keep making that mistake?! 🤦🤦🤦

[2N3055]

Well of course you are looking at the screen. For sure you're not looking into your belly button....

Dagnabbit! Why do I keep making that mistake?! 🤦🤦🤦

" You all wanna be looking very intently at your own belly buttons." ( Capt. Malcolm Reynolds )

[Njk]

My point was that no matter how many triggers are implemented, a waveform will come sooner or later that can't be captured as desired using any available trigger. And it's quite an accomplishment for average user to memorize hundreds of different triggers. So I wonder if any scope allows for user to define his own trigger through some kind of scripting. There must be something like that because it seems too obvious. Adjustable zone boundaries and loadable masks are nice features but that's not what I'm asking about.

And yes, I never been a big fan of a top-notch instruments. Too much instrumentation requirements can inflate the budget that can effectively prevent the project from start. And worse, provision of an instrument that is ten times expensive usually implies the provider's expectation that I'll do my job ten times faster. Of course, it's not so simple but the elements of social engineering are always there.

[pdenisowski]

My point was that no matter how many triggers are implemented, a waveform will come sooner or later that can't be captured as desired using any available trigger. And it's quite an accomplishment for average user to memorize hundreds of different triggers. So I wonder if any scope allows for user to define his own trigger through some kind of scripting. There must be something like that because it seems too obvious. Adjustable zone boundaries and loadable masks are nice features but that's not what I'm asking about.

Modern oscilloscopes are pretty flexible when it comes to triggering (although I'm not aware of any scope that has "hundreds" of trigger types ), so it might be helpful if you could provide an example of a waveform that you think would be difficult or impossible to trigger on. 

I'm not aware of any "scripting" for triggers, but on some of our scopes we do allow the user to trigger on a sequence of events:

https://www.rohde-schwarz.com/webhelp/MXO4_HTML_UserManual_en/Content/66d463be244c466b.htm

[KungFuJosh]

I think the next firmware update will include a "Psychic Trigger." Problem solved. 😉

On a slightly less unserious note, how long until AI ruins oscilloscopes?