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.
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).
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
The manuals nowadays describe the trigger itself (e.g. for the SDS800X: Interval Trigger: Trigger when the time difference between the neighbouring rising or falling edges meets the time limit
condition) but not when to use it.
After this post, my mind wandered away. Wouldn't it be nice to have a trigger trilogy (either in book, PDF or video like in the MXO5):
- Trigger 101: describing the real basics (trigger type, trigger mode, trigger level, when to use both rising and falling edge triggering, interplay with holdoff, etc.)
- Trigger SPY: a procedural approach to triggering based on a real-world question, as I indicated as an example, and some more high level: do we just capture data, trigger later (because the new scopes are so good at it) or does it pay off to think a bit more of the problem and use a trigger and then do a further analysis. A bit like the opening discussion in this video:
- The art of triggering: the wisdom of the masters in all detail (like in your answer, or maybe there are more clever solutions like filtering the initial 100kHz away) centred around the signal+question at hand.
I like this demo board, and I'm learning a lot about features I haven't explored much.
But when I got to step 3.5, to test the MSO parallel bus interface with my Siglent SDS2000X+, the scope seems to be lacking in capabilities.
If I'm understanding it correctly, the Siglent "decodes" parallel signals in the digital menu instead of the decode menu where it can decode serial signals.
And there is no option to see the decoded ASCII value:
(Attachment Link)
Converting the hex shown here, "42 61 74 72 6f 6e 69 78", to ASCII using any online converter produces the text "Batronix".
So it seems like an incredibly simple operation to do. Am I missing something perhaps?
I'm late to the party on this but here is another vote for adding ASCII decodes to parallel signal decoding in case anyone is reporting the vote count to Siglent in an effort to get Siglent to add this feature, or in case Siglent is listening directly to forum input. Thx
Where is parallel ASCII transmission still being used? Sounds very Centronics to me.
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
Agree.
Siglent also have logic triggers, qualified triggers, zone triggering (where we take any trigger and enhance it with go/no go zones).
All of these advanced trigger types (except zone that starts with SDS2000X+/XHD series) are present even in cheapest SDS800.
And add on protocol triggers on top of that.
And all of it is maybe 10 pages to read... Hardly more work than learning scripting language.
I have no problems triggering on something specific with scopes I have (Keysight, several 12 bit Siglents and several Picos) provided I know what to look for.
On Picoscopes I miss protocol triggers though.
As I said, if you are trying to verify clock for instance, you can simply use mask mode (because signal is very simple and repetitive) and just let it run. If you have no violation in some time (you decide what certainty you need, so it might be few hours or few days..) you are good.
But if scope has good measurements and statistics, even without Jitter/Eye packages, you can gather statistics on timing parameters, overshoot, risetimes, Cycle to Cycle jitter... And have a look at histograms to see how it behaves... And today you have that even with SDS800xHD ...
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
Agree.
Siglent also have logic triggers, qualified triggers, zone triggering (where we take any trigger and enhance it with go/no go zones).
All of these advanced trigger types (except zone that starts with SDS2000X+/XHD series) are present even in cheapest SDS800.
And add on protocol triggers on top of that.
And all of it is maybe 10 pages to read... Hardly more work than learning scripting language.
I have no problems triggering on something specific with scopes I have (Keysight, several 12 bit Siglents and several Picos) provided I know what to look for.
On Picoscopes I miss protocol triggers though.
As I said, if you are trying to verify clock for instance, you can simply use mask mode (because signal is very simple and repetitive) and just let it run. If you have no violation in some time (you decide what certainty you need, so it might be few hours or few days..) you are good.
But if scope has good measurements and statistics, even without Jitter/Eye packages, you can gather statistics on timing parameters, overshoot, risetimes, Cycle to Cycle jitter... And have a look at histograms to see how it behaves... And today you have that even with SDS800xHD ...
2N3055, can you tell us more about what keeps Jitter/Eye capabilities from being offered on lower/'midrange model scopes? Is it a fundamental assumption that lower bandwidth scopes don't need/justify Jitter/Eye capabilities, or is it the cost to implement, or something else? Thx
Where is parallel ASCII transmission still being used? Sounds very Centronics to me.
@Elekctro Fan:
Perhaps post with reference to this thread in a thread that siglent is more likely to know.
(I think we did that back then too, I'd have to look.)
Not sure where it's still being used (other than GPIB), but some people find repairing, restoring or exploring old stuff fun, as well as building new stuff with older technology, like following Ben Eaters videos
It didn't cross my mind that the feature would be missing when buying the probes and licenses for using the digital channels.
Not sure where it's still being used (other than GPIB), but some people find repairing, restoring or exploring old stuff fun, as well as building new stuff with older technology, like following Ben Eaters videos
It didn't cross my mind that the feature would be missing when buying the probes and licenses for using the digital channels.
If you are into that generation of technology (I am too!), you are fully expected to know all ASCII hex codes by heart.
This thread is about a demo board, so you use it for demonstration purposes, among other things.
People who are less involved in the ASCII table, i.e. anyone under 40 , might be more likely to understand an ASCII decoding of the Batronix lettering or the joke/countries in parallel decoding.
Hence the request for a corresponding extension to the Siglent scopes, in the appropriate threads.
we are now asking Siglent to add a decoder option so we can run the demo nicely?
Not sure where it's still being used (other than GPIB), but some people find repairing, restoring or exploring old stuff fun, as well as building new stuff with older technology, like following Ben Eaters videos
It didn't cross my mind that the feature would be missing when buying the probes and licenses for using the digital channels.
If you are into that generation of technology (I am too!), you are fully expected to know all ASCII hex codes by heart.
we are now asking Siglent to add a decoder option so we can run the demo nicely?Not really though. Siglent has already implemented the decoder for parallel signals. The hard part is getting the binary value from the signal, which works today. After that, you decide how to display the result to the user. Display as the original binary value, or something more humanly readable, like hex or ascii.
And the functionality to convert binary to ascii is already implemented for serial signals. So all the pieces are there already, we are just asking Siglent to add the required glue and menu element so we can use it. A demo board like this is just the first place many will experience this lacking feature, before venturing into real projects.
we are now asking Siglent to add a decoder option so we can run the demo nicely?Not really though. Siglent has already implemented the decoder for parallel signals. The hard part is getting the binary value from the signal, which works today. After that, you decide how to display the result to the user. Display as the original binary value, or something more humanly readable, like hex or ascii.
And the functionality to convert binary to ascii is already implemented for serial signals. So all the pieces are there already, we are just asking Siglent to add the required glue and menu element so we can use it. A demo board like this is just the first place many will experience this lacking feature, before venturing into real projects.
Finding the solution is not pushing button number 5 to get into the menue, but to find out and to learn. I sometimes like to run into a problem and then to search for the solution (including frustrating failures...), because it helps venturing future projects.
I don't see anyone advocating to remove features here, including the removal of ascii support for serial signals. Or is that what is happening?
For example, how about enabling pattern "trigger" for the Search function? That would enable us to capture and decode a long data sequence from a parallel bus including its handhake signals, then look for particular situations (patterns) on those lines and highlight them via search markers.