New Scope Demoboard from Batronix

[tautech]

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.

Sorry but 

The simplest solution is a single trigger with a appropriate level set then assign one or two Zone triggers and let the scope do the work.
When you have a scope with these features the rest is easy.

[RAPo]

Many thanks for your elaborate answer.
I don't have R&S MXO scope (yet (maybe )? the nearest R&S I have is a HMO1024)), but a video is always nice.

Please don't consider me unkind; maybe I didn't express myself well, but I'm looking for something more vendor-agnostic approach that incorporates the wisdom of people (like you or old hams).
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 .
  
• 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.

A scope demoboard could be a good 'add-on' to this trilogy.

It would indeed be nice for a relative newbie like myself.

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

[RAPo]

And if you need a real world signal for your video setup, buy a Fnirsi DMT-99, set it in capacitance mode and measure the signal. Here presented on a DHO942S with edge trigger and persistence to the max:

[2N3055]

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

[Performa01]

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.

Something like this would probably never be complete and several experts from different application areas could contribute to the tipps & tricks ("Art of Triggering") section.

Maybe someone (or even myself) will make a first attempt on this eventually, but until then you could have a look at the existing material:

https://www.eevblog.com/forum/testgear/siglent-sds1104x-e-in-depth-review/msg1371778/#msg1371778

Reply #2, the trigger section in the first attached document covers ome of your questions and gives examples for all the basic trigger types.

[Martin72]

Let me come back to the topic...
I've been working with the board again recently due to the new Scope.
It's almost bursting with signal possibilities, you don't even realize it at first glance, only when you read the relevant passages in the manual again and again does it become clear.
This also applies to the topic of decoder signals and this is where my point of criticism comes in, which I noticed earlier.
Maybe we'll get a few new ones through an update, the emphasis is on maybe.
But it already has a lot of decoder signals, but a few are not obvious at first glance and that bothers me.
Take CAN, for example...
For another topic in the forum I just wanted to show a CAN decoding on the SDS800X HD, look at the demo board, see directly only UART, SPI, I²C, otherwise J2 with the parallel outputs D0...D7.
Shit, then I look at my STB-3 demo board from Siglent, Ah, CAN-H, CAN-L, all right, I'll take that.
The Batronix board "naturally" has CAN, even CAN-FD, LIN and Manchester...
RTFM, it is shown on page 44, the signals are on the parallel port J2...
D7: CAN
D6: CAN with occasional bit errors
D5: CAN-FD
D4: CAN-FD with occasional bit errors
D3: LIN
D2: LIN with occasional bit errors
D1: Manchester
D0: Pulse
I would like to see the designations on the circuit board, next to D7/D5/D3/D1.
If it's obvious to the eye, you'll find yourself digging out the manual for more details.
Well, that would be an update that I wouldn't want, because I wouldn't want to buy it again for a print.
But in general and for new buyers it would be nice.

[Grandchuck]

The Batronix board can produce a 1kHz sine with about 5 mVp-p noise with switch 2 in position 1 .  In position 0, the added noise is zero. With the scope set for normal acquire one can detect the difference between the two; but only when switching back and forth between 1 and 0 (there is a very slight blurring effect with the noise on ... [screens below]).  The same is true in zoom mode. 

By using acquire ERES 2.0 the noise is easier to see, as shown below.

Ch 2 is filtered so the noise does not show up (until switch 2 is set higher).

The board also will provide a square wave with selectable noise and the noise is a bit easier to see then.

I hope more folks who have the board will try some ideas and post them here.

[Electro Fan]

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

[ebastler]

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.

[Martin72]

@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.)

[pdenisowski]

Where is parallel ASCII transmission still being used? Sounds very Centronics to me.

GPIB

[Electro Fan]

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

[2N3055]

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

Well, I can't speak officially as to what Siglent decisions are.

But I know that on SDS6000A eye/jitter is hardware accelerated, which is how you want it to keep it fast. Jitter/eye/bathtub diagrams are statistical analysis and they need lots of data and you need to be able to get enough data in relatively short time, so you don't have to let it sit there for weeks.
I know there is domestic Chinese SDS6000 version that cannot have jitter/eye because of difference in FPGA architecture, for instance. It is a 1GHz scope.

As for BW, I agree that low BW scopes with eye/jitter would apply to very limited market.
Most of the usage is for faster protocols..
And you need a healthy reserve in BW/risetime spec of the scope over signal you are measuring to get good data.
Also you probably will need some kind of active probing solution, meaning scope with active probe interface.
All of that stuff gets expensive fast, even with Siglent's good prices.
So it is available on 6000A/L and 7000A series.

But, new analysis options are being developed that are applicable for lower/mid range scopes. For instance, new SPI/I2C compliance test/report. That is something very interesting for embedded work, and that option alone on some A brands scope is so expensive, you can buy whole  SDS2000x+ for that purpose alone.

And for embedded work on SPI/I2C that is what is very useful.

[blurpy]

Where is parallel ASCII transmission still being used? Sounds very Centronics to me.

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.

@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.)

https://www.eevblog.com/forum/testgear/siglent-sds2000x-hd-missing-features-and-bugs/msg5175306/#msg5175306

And

https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/msg5175312/#msg5175312

[ebastler]

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. 

[2N3055]

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. 

WORD!! 

[Martin72]

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.

[ebastler]

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.

Frankly, that feels a bit backwards to me. Just because Batronix chose to implement a not-so-practical ASCII example for their "parallel data bus" demo, we are now asking Siglent to add a decoder option so we can run the demo nicely?

I would rather ask Batronix to revise the parallel transmission in their demo board. If they add an R/W and an Enable or Chip Select signal, it would be a more realistic demo of things going on on a data bus. I think it would be fine to sacrifice two of the data bits for that, leaving 5*data, CLK, R/W, /CS. Then mix two messages (bit patterns), one in Read access mode, one in Write access mode, interspersed with many other random bytes which have /CS not set.

Pulling out the relevant Read or Write data stream would be a nice challenge, and closer to a real-world data bus scenario. The 5 data bits could encode a running count, a Fibonacci sequence, Baudot letters, whatever. I don't expect Siglent to implement a Baudot display mode for the parallel decoder!

[blurpy]

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.

[Electro Fan]

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. 

01010100  01101000  01111000

(MSB, no start or stop bits, no parity bit, any bps)

[Electro Fan]

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.

+1
 

[axantas]

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.

I do not completely disagree - just a little bit...
Venturing into new projects also means mastering hurdles - so to say.

Houston, we have a problem.

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.

[blurpy]

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 agree that learning is valuable, but optional automation wont stop anyone from learning if they want, and at the same time it speeds up the task for those who already know or don't care.

Modern scopes are pretty amazing efficiency tools. All the nice measurements that Siglent have implemented for us are there because it saves us time, even if we know how to count divisions to get peek to peek voltage or know the math behind RMS. 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?

[ebastler]

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?

That's called a strawman argument -- nobody has ever suggested that. But serial protocols are quite commonly used to transmit ASCII data, while parallel buses are not (anymore). Hence I think there are many things Siglent could do which are more important than implementing ASCII output for the parallel decoder, even if that would be a limited effort.

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.

That would be really useful for working with parallel buses in my opinion. In contrast to ASCII-formatted output, where the key rationale seems to be a nicer demo with the Batronix board. 

[blurpy]

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.

Well you would learn much more by not having this feature I think