EEVblog #1320 - Premature Oscilloscope Triggering

[TheNewLab]

Turns out I hadn't updated the firmware on the scope; options are there Loving this scope - so many features for the cost; simply incredible.

I am terrible at keeping firmware up-to-date. Maybe dave could do a video explaining the importance of doing the updates..or add on to another related video

[SilverSolder]

Turns out I hadn't updated the firmware on the scope; options are there Loving this scope - so many features for the cost; simply incredible.

I am terrible at keeping firmware up-to-date. Maybe dave could do a video explaining the importance of doing the updates..or add on to another related video

If the equipment is obsolete, I usually install the latest firmware. 

For current equipment, I normally only update the firmware if I have a problem that is covered by an update...  on the theory that usually, no software is ever fixed without breaking or at least changing something about it that you liked!

[SilverSolder]

What happens to the sample rate on a 2 channel 1GSa/s scope when you use the EXT Trig, or even AC LINE as the trigger source?

Test it to find out;

I would if I could but I've only got the CML+ here, and that's different, it can certainly keep 1GSa/s RT (or even 10s of GSa/s ETS) on one channel while triggering off something else, - such as the channel that's switched off.

ETS implies that it does support analog triggering but that is not absolute and there are some alternative triggering implementation which have not been discussed here.  Low and even medium cost oscilloscopes for more than a decade now have largely lacked analog triggering completely simply because of economics; with increasing digital integration, digital triggering becomes essentially free.

I'm having trouble envisioning how external trigger could be supported by "hijacking" one of the data channels - the "hijacked" channel would have to lose some performance if you do that (interleaving, or something like that)?

[StillTrying]

I'm having trouble envisioning how external trigger could be supported by "hijacking" one of the data channels - the "hijacked" channel would have to lose some performance if you do that (interleaving, or something like that)?

Yes we'll have to wait for someone with a DS1202Z-E or SDS1202X-E who knows what they're doing to test the EXT Trig's quality and any effects it has on the 2 channel's operation.

[2N3055]

I'm having trouble envisioning how external trigger could be supported by "hijacking" one of the data channels - the "hijacked" channel would have to lose some performance if you do that (interleaving, or something like that)?

Yes we'll have to wait for someone with a DS1202Z-E or SDS1202X-E who knows what they're doing to test the EXT Trig's quality and any effects it has on the 2 channel's operation.

Why would it have any effect??  EXT is simply comparator going directly to trigger engine..
It has nothing with channels data stream..

[StillTrying]

Why would it have any effect??  EXT is simply comparator going directly to trigger engine..
It has nothing with channels data stream..

I'm beginning to think even the main channel(s) triggering is done with a fast comparator.

[2N3055]

Why would it have any effect??  EXT is simply comparator going directly to trigger engine..
It has nothing with channels data stream..

I'm beginning to think even the main channel(s) triggering is done with a fast comparator.

 

For crying out loud, how hard is to understand this, really...
Is this antivaxer site ??

Scopes today have digital trigger for analog channels and those that have separate trigger in have a separate comparator going directly into triggering engine...

All the information is there on manufacturers web sites..

[David Hess]

I'm having trouble envisioning how external trigger could be supported by "hijacking" one of the data channels - the "hijacked" channel would have to lose some performance if you do that (interleaving, or something like that)?

The external trigger is either analog, with its limitations of trigger modes and this leads to the problem of how to align the trigger to sample clock unless a time delay counter is implemented, or it is a simplified digitizer input which can take advantage of the same digital trigger logic used for the vertical inputs; the digitizer can be simplified because no acquisition memory is required for digital triggering.  The digitizer may or may not be shared with the digitizer used for the vertical inputs as would be the case with a 4 channel instrument.

What the external input cannot be is a comparator driving a logic input without some way to measure trigger to sample clock delay.  What happens when the logic inputs of a mixed signal DSO are used as an external trigger for the vertical inputs?

[2N3055]

I'm having trouble envisioning how external trigger could be supported by "hijacking" one of the data channels - the "hijacked" channel would have to lose some performance if you do that (interleaving, or something like that)?

The external trigger is either analog, with its limitations of trigger modes and this leads to the problem of how to align the trigger to sample clock unless a time delay counter is implemented, or it is a simplified digitizer input which can take advantage of the same digital trigger logic used for the vertical inputs; the digitizer can be simplified because no acquisition memory is required for digital triggering.  The digitizer may or may not be shared with the digitizer used for the vertical inputs as would be the case with a 4 channel instrument.

What the external input cannot be is a comparator driving a logic input without some way to measure trigger to sample clock delay.  What happens when the logic inputs of a mixed signal DSO are used as an external trigger for the vertical inputs?

You are thinking too simplistically. There is no triggering "chip" with physical "trigger now" input. It is all a logical block in acquisition engine.
Ext In is simply another variable in. Triggering engine digital block takes care of timing (and trigger point interpolation)

Keysight has Ext In implemented same as a digital MSO input, on logic side. On analog side it has 1M input impedance (like standard scope input, but unspecified capacity), provisions for variable probe attenuation and variable trigger level that is freely setable to +-8V, HF filter, DC/AC coupling, hold-off. 

For a user it provides most of the usual controls that an analog ch triggering would have.

Some simply have +-0,6 V (and +-3v with x5 attenuation) like Siglent for instance. Pico has 1M/14pF input, with +-5V range...

So every manufacturer will have different ways of doing it. For Keysight it is part of their Megazoom. For rest it is simply a logic block in FPGA bitstream, assisted with some analog parts to interface with real world. I guess every single one will be slightly different, depending on what was intrinsically easy to do on their architecture and priority how important it was to make it simple or not..

[maginnovision]

I guess the lower end R&S scopes have a leg up there. Limits for Ext In are the same as the analog channels themselves.

[David Hess]

You are thinking too simplistically. There is no triggering "chip" with physical "trigger now" input. It is all a logical block in acquisition engine.

Ext In is simply another variable in. Triggering engine digital block takes care of timing (and trigger point interpolation)

If you have a digital input, then how is the trigger point interpolation done?  Are they really going to implement a tapped delay line time delay counter in an FPGA just for this?  This is a pretty specialized structure and good performance is difficult to achieve compared to the alternatives.

This is why I asked about triggering on the logic inputs because we know they are digital inputs.  What happens then?  I have yet to see someone run that test but it would be very easy to do.  The other test I suggested earlier is whether the external trigger supports all of the same trigger modes as the vertical inputs; if it does, then it cannot be a digital input.

The other method I mentioned was used in early DPOs where a digital trigger input went through a pulse shaping network and was then digitized allowing transition midpoint or centroid timing.  The advantage of this method over earlier time delay counting methods is that it has a very short rearm time making it suitable for high record acquisition rates but it does not support advanced triggering modes.  With a little more cheap logic, the extra analog signal conditioning can be discarded and you end up with a simplified vertical input and no acquisition memory like I described and then it *can* support all of the same trigger modes as the vertical inputs.

[SilverSolder]

You are thinking too simplistically. There is no triggering "chip" with physical "trigger now" input. It is all a logical block in acquisition engine.

Ext In is simply another variable in. Triggering engine digital block takes care of timing (and trigger point interpolation)

If you have a digital input, then how is the trigger point interpolation done?  Are they really going to implement a tapped delay line time delay counter in an FPGA just for this?  This is a pretty specialized structure and good performance is difficult to achieve compared to the alternatives.

This is why I asked about triggering on the logic inputs because we know they are digital inputs.  What happens then?  I have yet to see someone run that test but it would be very easy to do.  The other test I suggested earlier is whether the external trigger supports all of the same trigger modes as the vertical inputs; if it does, then it cannot be a digital input.

The other method I mentioned was used in early DPOs where a digital trigger input went through a pulse shaping network and was then digitized allowing transition midpoint or centroid timing.  The advantage of this method over earlier time delay counting methods is that it has a very short rearm time making it suitable for high record acquisition rates but it does not support advanced triggering modes.  With a little more cheap logic, the extra analog signal conditioning can be discarded and you end up with a simplified vertical input and no acquisition memory like I described and then it *can* support all of the same trigger modes as the vertical inputs.

Just had a look at my older Megazoom MSO, a 54622D, and can confirm that it does not support anything other than edge triggering on the external input (with adjustable level, and various filters).  The external input is less capable than triggering off one of the digital lines D0-D15 as the external trigger does not support any pulse or pattern modes, for example.

[David Hess]

Just had a look at my older Megazoom MSO, a 54622D, and can confirm that it does not support anything other than edge triggering on the external input (with adjustable level, and various filters).  The external input is less capable than triggering off one of the digital lines D0-D15 as the external trigger does not support any pulse or pattern modes, for example.

The HP 54622D is old enough though that it probably does use analog triggering separate from dedicated advanced triggering hardware which is common for DSOs of that era.  The question is how modern DSOs which implement digital triggering for the vertical inputs after the digitizer, typically in an FPGA now, handle triggering for their external and logic inputs.

On your HP 54622D, what happens when one of the digital lines is used as the trigger source for a vertical input?  I guess what I would do is multiplex all of the digital inputs to a single digital output, which is cheap and easy, to feed an external trigger input so only a single analog trigger path is required and all of the analog triggering hardware serves double duty.  That just leaves how modern MSOs implement triggering for their external trigger inputs if they do the same thing; I am dubious that they implement an analog time delay counter and this should be easy to verify.  The easy way for them is to digitize the external trigger signal and treat it as a vertical input with no or a limited acquisition record.

[SilverSolder]

Just had a look at my older Megazoom MSO, a 54622D, and can confirm that it does not support anything other than edge triggering on the external input (with adjustable level, and various filters).  The external input is less capable than triggering off one of the digital lines D0-D15 as the external trigger does not support any pulse or pattern modes, for example.

The HP 54622D is old enough though that it probably does use analog triggering separate from dedicated advanced triggering hardware which is common for DSOs of that era.  The question is how modern DSOs which implement digital triggering for the vertical inputs after the digitizer, typically in an FPGA now, handle triggering for their external and logic inputs.

On your HP 54622D, what happens when one of the digital lines is used as the trigger source for a vertical input?  I guess what I would do is multiplex all of the digital inputs to a single digital output, which is cheap and easy, to feed an external trigger input so only a single analog trigger path is required and all of the analog triggering hardware serves double duty.  That just leaves how modern MSOs implement triggering for their external trigger inputs if they do the same thing; I am dubious that they implement an analog time delay counter and this should be easy to verify.  The easy way for them is to digitize the external trigger signal and treat it as a vertical input with no or a limited acquisition record.

I suspect there is a separate trigger circuit for digital 0..7 and 8..15 on this scope, because these two groups can be set to their own trigger levels independently.

Your explanation makes sense, that all the trigger comparators lead to the same point inside the Megazoom brain, which takes control after a trigger event and looks at what happened across all the data streams and determines if the trigger is allowed to proceed or not (and adds support triggering on patterns, sequences, pulse width, and all the rest of the advanced triggers).  [Edit: this is not correct, see diagram(s) below]

[2N3055]

That just leaves how modern MSOs implement triggering for their external trigger inputs if they do the same thing; I am dubious that they implement an analog time delay counter and this should be easy to verify.  The easy way for them is to digitize the external trigger signal and treat it as a vertical input with no or a limited acquisition record.

Err... no, sorry. Like I said, it is not how it's done. And I'm not speculating or inventing how it might or should be done.



EXT input trigger doesn't take any resources from analog ch and adding separate A/D is expensive...

And that is Keysight who could have added something in Megazoom while they were at it... Other scope manufacturers have to buy A/D converters chip by chip and it costs real money..
Also, there is no need to overthink. I it is not a 5 or 21 ch scope,it is 4ch and Trig in, or 4+16 MSO+ext trig in. Ext trig in is very limited and digital channels will have their horizontal resolution aligned to sampling clock.  Whatever you're seeing on digital channels is quantized to scope sampling clock. It is not synchronous with input signal. There is not even attempt to realign digital edges with interpolated trigger point.

[SilverSolder]

There's a good article that covers the design of the MSO trigger circuits in the attached HP Journal from '97.

The analog trigger path seems to just parallel all the possible trigger sources:




Then, the digital trigger system appears to integrate analog and digital sources (that presumably feeds into a trigger mux similar to the above diagram)?



So, it looks like the External Trigger is completely "out of the loop" on the MSO and acts as an independent entity, and does not use any CPU resources here.

[thm_w]

I suspect there is a separate trigger circuit for digital 0..7 and 8..15 on this scope, because these two groups can be set to their own trigger levels independently.

That should just be the high speed comparator reference voltage. Useful if you wanted to monitor say 1.8V and 3.3V digital signals at the same time.
You are only limited by the number of DAC channels present, so two DACs in that case.

[David Hess]

Err... no, sorry. Like I said, it is not how it's done. And I'm not speculating or inventing how it might or should be done.

Those diagrams are often simplified, and those HP DSOs are significantly more sophisticated than the entry level DSOs we are discussing.  Of course I expect HP to get it right in their custom Megazoom ASIC no matter how they implemented it.

EXT input trigger doesn't take any resources from analog ch and adding separate A/D is expensive...

But an external input trigger which is not digitized requires a delay time counter.  So where is it?  Your HP example shows it, or at least a block for it, but not details of its operation which is also important because it will limit trigger rearm rate.  Besides taking advantage of digital integration, digital triggering can operate in real time and some time delay counters operate in exactly this way.

And that is Keysight who could have added something in Megazoom while they were at it... Other scope manufacturers have to buy A/D converters chip by chip and it costs real money..

But they don't have to buy acquisition memory for it.

Also, there is no need to overthink. I it is not a 5 or 21 ch scope,it is 4ch and Trig in, or 4+16 MSO+ext trig in. Ext trig in is very limited and digital channels will have their horizontal resolution aligned to sampling clock.  Whatever you're seeing on digital channels is quantized to scope sampling clock. It is not synchronous with input signal. There is not even attempt to realign digital edges with interpolated trigger point.

That is why I suggested that someone with one of these DSOs test it!

If the digital inputs work like you suggest, then they cannot be used to accurately trigger the oscilloscope.  And if the external trigger works that way, then it cannot either.  Does anybody remember the triggering problem with Rigol when AC coupling was used?  That is exactly the problem I would expect.

In my previous post, I pointed out a very cheap way requiring only digital multiplexing for the digital inputs to be funneled into the external trigger and actually work just fine as external trigger inputs.  Incidentally, old analog oscilloscopes and DSOs which include word recognizers do exactly this and have no trouble triggering on their logic inputs.

[SilverSolder]

[...] If the digital inputs work like you suggest, then they cannot be used to accurately trigger the oscilloscope.  And if the external trigger works that way, then it cannot either.  [...]

Does the trigger have to be more accurate than the horizontal resolution being displayed on the screen, in order for triggering to work "well enough"?

[David Hess]

[...] If the digital inputs work like you suggest, then they cannot be used to accurately trigger the oscilloscope.  And if the external trigger works that way, then it cannot either.  [...]

Does the trigger have to be more accurate than the horizontal resolution being displayed on the screen, in order for triggering to work "well enough"?

No, but on a DSO, the horizontal resolution is normally much higher than the sample rate because of equivalent time sampling or interpolation.  Logic analyzer inputs typically have a resolution of a couple nanoseconds (100s of MSamples/second) (1) but oscilloscope trigger resolution is an order of magnitude higher than the sample rate of a DSO.  A 100 MHz (3.5 nanosecond) bandwidth oscilloscope cannot measure a 350 picosecond signal but it can measure the delay between two such signals.  Achieving 500 picosecond resolution which is reasonable on a 100 MHz instrument would require a 2 GSample/second sampling clock and there are just better ways to do it.

(1) I think some high performance logic analyzers have implemented time stamping with higher resolution than the sample clock similar to segmented memory on a DSO but this is not common and an interesting design puzzle.  (2) And as I have pointed out above, it is fairly easy to forward a single or combination of digital inputs to an oscilloscope's trigger circuit to achieve high resolution.  I would like to know if various low end MSOs do this; the last time I messed with one, the question did not come up.

(2) I know how to do it in the analog domain but I am not sure how to do it in the digital domain.

[SilverSolder]

[...] If the digital inputs work like you suggest, then they cannot be used to accurately trigger the oscilloscope.  And if the external trigger works that way, then it cannot either.  [...]

Does the trigger have to be more accurate than the horizontal resolution being displayed on the screen, in order for triggering to work "well enough"?

No, but on a DSO, the horizontal resolution is normally much higher than the sample rate because of equivalent time sampling or interpolation.  Logic analyzer inputs typically have a resolution of a couple nanoseconds (100s of MSamples/second) (1) but oscilloscope trigger resolution is an order of magnitude higher than the sample rate of a DSO. A 100 MHz (3.5 nanosecond) bandwidth oscilloscope cannot measure a 350 picosecond signal but it can measure the delay between two such signals.  Achieving 500 picosecond resolution which is reasonable on a 100 MHz instrument would require a 2 GSample/second sampling clock and there are just better ways to do it.

(1) I think some high performance logic analyzers have implemented time stamping with higher resolution than the sample clock similar to segmented memory on a DSO but this is not common and an interesting design puzzle.  (2) And as I have pointed out above, it is fairly easy to forward a single or combination of digital inputs to an oscilloscope's trigger circuit to achieve high resolution.  I would like to know if various low end MSOs do this; the last time I messed with one, the question did not come up.

(2) I know how to do it in the analog domain but I am not sure how to do it in the digital domain.

Aaaah....  a flickering light appears in the darkness!

So if an example 100MHz scope screen has 1000 pixels horizontal resolution, and the time base is set to 5ns/div, it will display 50ns of data spread over 1000 pixels, or 50ns/1000 = 500 picoseconds per pixel.  Since one pixel is the minimum shift between two signals that can actually be displayed on the screen, it means the trigger has to reliably resolve a little better than 500 picoseconds.

Wouldn't the digital channels have to resolve phase exactly the same way for the MSO to function properly?


Going back to the discussion of cheap scopes:  If triggering is based purely off the digitized data stream, you could get reasonably close to the same performance (given a 100Mhz scope) with 1GSa/s by having less pixels horizontal resolution across the screen?  [Edit: in the sense that the display is the limitation, not the trigger, so the package as a whole "works as it should".  The performance overall is of course still lower than having a 500ps resolution trigger on a higher resolution screen.]

[David Hess]

So if an example 100MHz scope screen has 1000 pixels horizontal resolution, and the time base is set to 5ns/div, it will display 50ns of data spread over 1000 pixels, or 50ns/1000 = 500 picoseconds per pixel.  Since one pixel is the minimum shift between two signals that can actually be displayed on the screen, it means the trigger has to reliably resolve a little better than 500 picoseconds.

Oddly enough that is often exactly how it works at least for oscilloscopes where the processing record and display record are identical but see below about time delay counter resolution.  Sometimes the specifications do not give the timing resolution but it can be worked out from the number of horizontal pixels per division.  If the automatic measurements use histograms, then the actual measurement resolution is even higher.

Wouldn't the digital channels have to resolve phase exactly the same way for the MSO to function properly?

If they did not, then there would be considerable jitter between the MSO inputs and the oscilloscope trigger, and that is usually the case.  Usually the MSO timing resolution is limited to the logic input sample rate.  In the past, implementing a time delay counter on every logic input would be prohibitively expensive except for specialized applications but maybe someone manages it now with increased digital integration.  Most applications still do not need it though.

That is why I asked about triggering off of the MSO inputs to display a vertical input; they might have made special provisions to avoid jitter like I described earlier.  But working in the opposite direction by triggering off of the oscilloscope to display the MSO inputs should always reveal the relatively coarse sampling of the MSO inputs.

Going back to the discussion of cheap scopes:  If triggering is based purely off the digitized data stream, you could get reasonably close to the same performance (given a 100Mhz scope) with 1GSa/s by having less pixels horizontal resolution across the screen?  [Edit: in the sense that the display is the limitation, not the trigger, so the package as a whole "works as it should".  The performance overall is of course still lower than having a 500ps resolution trigger on a higher resolution screen.]

You could, but there is no need to, and it would look pretty bad.  If the sample rate is high enough, which it has to be to allow digital triggering to be used, then after the trigger occurs and the acquisition is captured, a second stage of triggering can be done on the interpolated waveform to align the acquisition on the display.  Or it can be done during triggering with some extra logic.

On older DSOs which do not support digital triggering, usually the time delay counter provides all of the alignment information.  The actual resolution of the time delay counter is much higher than the resulting horizontal resolution which allows for automatic calibration for each timebase setting as needed.  The time delay measurement circuit can be pretty crude yet deliver accurate results after calibration for zero, span, and linearization which is surprisingly easy.

[SilverSolder]

So if an example 100MHz scope screen has 1000 pixels horizontal resolution, and the time base is set to 5ns/div, it will display 50ns of data spread over 1000 pixels, or 50ns/1000 = 500 picoseconds per pixel.  Since one pixel is the minimum shift between two signals that can actually be displayed on the screen, it means the trigger has to reliably resolve a little better than 500 picoseconds.

Oddly enough that is often exactly how it works at least for oscilloscopes where the processing record and display record are identical but see below about time delay counter resolution.  Sometimes the specifications do not give the timing resolution but it can be worked out from the number of horizontal pixels per division.  If the automatic measurements use histograms, then the actual measurement resolution is even higher.

Wouldn't the digital channels have to resolve phase exactly the same way for the MSO to function properly?

If they did not, then there would be considerable jitter between the MSO inputs and the oscilloscope trigger, and that is usually the case.  Usually the MSO timing resolution is limited to the logic input sample rate.  In the past, implementing a time delay counter on every logic input would be prohibitively expensive except for specialized applications but maybe someone manages it now with increased digital integration.  Most applications still do not need it though.

That is why I asked about triggering off of the MSO inputs to display a vertical input; they might have made special provisions to avoid jitter like I described earlier.  But working in the opposite direction by triggering off of the oscilloscope to display the MSO inputs should always reveal the relatively coarse sampling of the MSO inputs.

Going back to the discussion of cheap scopes:  If triggering is based purely off the digitized data stream, you could get reasonably close to the same performance (given a 100Mhz scope) with 1GSa/s by having less pixels horizontal resolution across the screen?  [Edit: in the sense that the display is the limitation, not the trigger, so the package as a whole "works as it should".  The performance overall is of course still lower than having a 500ps resolution trigger on a higher resolution screen.]

You could, but there is no need to, and it would look pretty bad.  If the sample rate is high enough, which it has to be to allow digital triggering to be used, then after the trigger occurs and the acquisition is captured, a second stage of triggering can be done on the interpolated waveform to align the acquisition on the display.  Or it can be done during triggering with some extra logic.

On older DSOs which do not support digital triggering, usually the time delay counter provides all of the alignment information.  The actual resolution of the time delay counter is much higher than the resulting horizontal resolution which allows for automatic calibration for each timebase setting as needed.  The time delay measurement circuit can be pretty crude yet deliver accurate results after calibration for zero, span, and linearization which is surprisingly easy.

I did some experiments on the 54622D, comparing the analog trigger with triggering from a Digital channel.

As you predicted, the jitter on the digital signal is much worse than analog - 5ns exactly - which corresponds exactly to the 200MSa/s sample rate:



However...  the trigger doesn't seem to be to blame!    As an experiment, I switched triggering between the digital channel and the analog channel, and the jitter looks exactly the same.

In a further experiment, I looked at the delay between the leading edge of the test signal and the trigger output (external connector on the back of the scope) with a HP 5335a Counter.  It seems that when the trigger is set to the same voltage on both Digital and Analog, the trigger performs exactly the same,  and there is no difference in the jitter on the trigger, whether using the analog or digital channel as the source.

It seems that unlike what happens with the Analog channels,  no attempt is made to re-align the displayed signal with the actual trigger point - instead, it is always aligned to the sample clock.  So the trigger itself appears to always a "precise" trigger...  it's just that the scope doesn't make use of the information, for whatever reason.  There are probably good reasons for it (e.g. can you trust all the pulses in a train to need the same adjustment as the one you happened to trigger on).


[Edit]  By switching off one of the analog channels, the scope switched to an interleaved 400MSa/s mode on the single digital channel, cutting the jitter in half to 2.5ns.  All other behavior was the same.

[David Hess]

In a further experiment, I looked at the delay between the leading edge of the test signal and the trigger output (external connector on the back of the scope) with a HP 5335a Counter.  It seems that when the trigger is set to the same voltage on both Digital and Analog, the trigger performs exactly the same,  and there is no difference in the jitter on the trigger, whether using the analog or digital channel as the source.

By default you cannot rely on the trigger output when triggering is digital because it is quantized with the same sampling clock as the digital inputs.  On oscilloscopes which use analog triggering, the trigger output is tied directly to the trigger comparator in one way or another.

[SilverSolder]

In a further experiment, I looked at the delay between the leading edge of the test signal and the trigger output (external connector on the back of the scope) with a HP 5335a Counter.  It seems that when the trigger is set to the same voltage on both Digital and Analog, the trigger performs exactly the same,  and there is no difference in the jitter on the trigger, whether using the analog or digital channel as the source.

By default you cannot rely on the trigger output when triggering is digital because it is quantized with the same sampling clock as the digital inputs.  On oscilloscopes which use analog triggering, the trigger output is tied directly to the trigger comparator in one way or another.

Looks like we may have a good test?   Inspect the jitter between a square wave input signal and the trigger output.

If the jitter is always a multiple of the sample rate on the analog inputs, the scope uses digital triggering.  Don't try this on the digital channels, though, since they may be sample aligned even with analog triggering.