Siglent SDS1104X-E and SDS1204X-E Mixed Signal Oscilloscopes

[masterx81]

Sorry for the question. Today is arrived this little baby (1104x-e), and i'm trying to zoom at maximum possible the second rising edge after the trigger of a 1khz signal (jitter analysis). But seem that there is a limit how far the screen can be from the trigger point, limit at 500us. I'm doing something wrong, or there is a better way to do it? Thanks!

[kcbrown]

Sorry for the question. Today is arrived this little baby (1104x-e), and i'm trying to zoom at maximum possible the second rising edge after the trigger of a 1khz signal (jitter analysis). But seem that there is a limit how far the screen can be from the trigger point, limit at 500us. I'm doing something wrong, or there is a better way to do it? Thanks!

The nature of how the Siglent does captures is that what you see on the screen is the entire capture.  So what you may want to do is to set your timebase such that at least two rising edges are visible, and then zoom in on the second one after you stop the scope.  Or you can use zoom mode while the scope is running (see below).

That said, you can actually set the trigger point location to be outside of the capture area.  If you rotate the horizontal position knob counterclockwise, you'll be positioning the trigger point earlier in the capture, and you can actually position it to well before the point where the screen begins.  So that would make it possible for you to see the second rising edge while triggering on the first rising edge.  Note that this would work best when the trigger is set up such that it would trigger on the first rising edge but not the second one, something that you can arrange using the holdoff feature of the edge trigger.

Also, the scope has a "zoom mode".  Press the horizontal scale button and it'll switch to zoom mode.  This makes it possible for you to capture both rising edges and zoom in on the second one while the scope is running.

[kcbrown]

Tautech and/or rf-loop, why isn't trigger holdoff available for all trigger types?  That seems to be something that should be a general property of the triggering system itself, rather than being something that is type-specific, no?  After all, it's just an artificial delay that is introduced prior to the trigger being re-armed.

[tautech]

Tautech and/or rf-loop, why isn't trigger holdoff available for all trigger types?  That seems to be something that should be a general property of the triggering system itself, rather than being something that is type-specific, no?  After all, it's just an artificial delay that is introduced prior to the trigger being re-armed.

Artificial yes and a necessary tool when dealing with non-repetitive waveforms where you need to have full control of trigger rearming so to be able to reliably trigger on your POI.
Holdoff is just not needed on all trigger types however without detailed analysis of each trigger type they may have their own specific holdoff value.

Arguably in the modern DSO the trigger suite is the most complex feature and certainly the feature that takes the most mastering when we depart from just simple edge triggering.

[masterx81]

The nature of how the Siglent does captures is that what you see on the screen is the entire capture.  So what you may want to do is to set your timebase such that at least two rising edges are visible, and then zoom in on the second one after you stop the scope.  Or you can use zoom mode while the scope is running (see below).

That said, you can actually set the trigger point location to be outside of the capture area.  If you rotate the horizontal position knob counterclockwise, you'll be positioning the trigger point earlier in the capture, and you can actually position it to well before the point where the screen begins.  So that would make it possible for you to see the second rising edge while triggering on the first rising edge.  Note that this would work best when the trigger is set up such that it would trigger on the first rising edge but not the second one, something that you can arrange using the holdoff feature of the edge trigger.

Also, the scope has a "zoom mode".  Press the horizontal scale button and it'll switch to zoom mode.  This makes it possible for you to capture both rising edges and zoom in on the second one while the scope is running.

Thanks! I've centered the second rising edge, zoomed and worked like a charm!
One more little question: there isn't also a vertical zoom?trying to increase the vertical gain obviously i get a distorted wave due to clipping of the input opamps...

[HendriXML]

I've created a script that advances trough wave forms of different frequencies (E12, 10 Hz - 1 Khz) and matching trigger hold times and horizontal timebasis.

They all have a different failure rate, but the posted one is very high. I dear to say it is the highest that can be managed. For every good capture, a bad one.

330 Hz
Slope time: 378,79 μs
Slope time range low: 340,90 μs
Slope time range high: 454,54 μs

The timings are quite tight 0.9 * Slope time .. 1.2 * Slope time

On other waves I can see that on wider timings more "non first high passes" are at the trigger location. However they then match the time window.

This is important info. I don't now how it supposed to function but, to me it seems that first the "fastest" slope should be determined (thus last low pass, first high pass) and then it should check the time against the time window.

[HendriXML]

Btw. 33 Hz (10x less) gave very few failures. (I've seen only one)

[kcbrown]

Tautech and/or rf-loop, why isn't trigger holdoff available for all trigger types?  That seems to be something that should be a general property of the triggering system itself, rather than being something that is type-specific, no?  After all, it's just an artificial delay that is introduced prior to the trigger being re-armed.

Artificial yes and a necessary tool when dealing with non-repetitive waveforms where you need to have full control of trigger rearming so to be able to reliably trigger on your POI.
Holdoff is just not needed on all trigger types however without detailed analysis of each trigger type they may have their own specific holdoff value.

Arguably in the modern DSO the trigger suite is the most complex feature and certainly the feature that takes the most mastering when we depart from just simple edge triggering.

I'm not sure I buy this as an explanation.  The trigger conditions, i.e. when it fires, are obviously highly dependent on the trigger type and involve multiple considerations.  But that is completely separate from an additional delay that can be imposed.  The additional delay is what I'm talking about here, and I see no reason whatsoever that it can't be imposed in all trigger types.  After all, all it says is "the trigger shall not fire again until after the specified delay time has passed".

Who's to say whether a delay is needed or not?  The answer to that is simple: the user.  And only the user.   The manufacturer is in no position to make any such claim, because the manufacturer simply cannot know the entirety of circumstances in which the trigger will be used.

[tautech]

Tautech and/or rf-loop, why isn't trigger holdoff available for all trigger types?  That seems to be something that should be a general property of the triggering system itself, rather than being something that is type-specific, no?  After all, it's just an artificial delay that is introduced prior to the trigger being re-armed.

Artificial yes and a necessary tool when dealing with non-repetitive waveforms where you need to have full control of trigger rearming so to be able to reliably trigger on your POI.
Holdoff is just not needed on all trigger types however without detailed analysis of each trigger type they may have their own specific holdoff value.

Arguably in the modern DSO the trigger suite is the most complex feature and certainly the feature that takes the most mastering when we depart from just simple edge triggering.

I'm not sure I buy this as an explanation.  The trigger conditions, i.e. when it fires, are obviously highly dependent on the trigger type and involve multiple considerations.  But that is completely separate from an additional delay that can be imposed.  The additional delay is what I'm talking about here, and I see no reason whatsoever that it can't be imposed in all trigger types.  After all, all it says is "the trigger shall not fire again until after the specified delay time has passed".

Who's to say whether a delay is needed or not?  The answer to that is simple: the user.  And only the user.   The manufacturer is in no position to make any such claim, because the manufacturer simply cannot know the entirety of circumstances in which the trigger will be used.

Say for example we need trigger on one bit and as that bit is just one trigger parameter that's user adjustable within that trigger type would be a good example of when trigger holdoff is not required otherwise I broadly agree the user must have the control and not the instrument.

[kcbrown]

Thanks! I've centered the second rising edge, zoomed and worked like a charm!
One more little question: there isn't also a vertical zoom?trying to increase the vertical gain obviously i get a distorted wave due to clipping of the input opamps...

You'll get clipping if you increase the vertical gain while the scope is operating, but when the scope is stopped, the vertical zoom just acts as a standard zoom.  So try stopping the scope first and then zoom in using the vertical scale knob.

The scope converter only has so much resolution, however, so what you really want to do is to set the vertical settings so that the waveform fills as much of the screen as you can manage.  This will ensure that the opamps remain unsaturated while also ensuring that you have maximum use of the ADC resolution.  You can then zoom in from there with the scope stopped.   There may be limitations in terms of what you can do with respect to zooming in like that, but from what I've seen, you'll easily be able to zoom in vertically to the point where you can make out the individual value transitions within the number of bits per sample recorded.

[kcbrown]

Say for example we need trigger on one bit and as that bit is just one trigger parameter that's user adjustable within that trigger type would be a good example of when trigger holdoff is not required otherwise I broadly agree the user must have the control and not the instrument.

Well, to be clear, I'm referring to holdoff as strictly being with respect to the complete trigger itself.  The trigger either fires or it doesn't.  When it fires, and how long you give it before it can fire again, is all that matters with respect to the the holdoff.

Certainly, there are going to be subconditions that may have their own individual delay specifications, but that's an entirely different thing from what I'm talking about.

A perfect example here is the slope trigger type.  Why in the world isn't there a holdoff available for it?   I can think of no good reason whatsoever for that.  And the same goes for every other trigger type we have, including the serial decoding trigger types.   There are going to be situations in which you know for a fact that you'll want to wait at least some amount of time before the trigger fires again, and I can't think of any trigger type that is even theoretically an exception to that.

[kcbrown]

Got another question.

I noticed that in roll mode, the sample memory is cut by a factor of 10.  Why is that?  A factor of 10 seems excessive.  What's the rest of the memory being used for?  Certainly not history -- that's disabled in roll mode.

[tautech]

Got another question.

I noticed that in roll mode, the sample memory is cut by a factor of 10.  Why is that?  A factor of 10 seems excessive.  What's the rest of the memory being used for?  Certainly not history -- that's disabled in roll mode.

IDK for dedicated Roll mode however if max mem depth is what you need in Roll mode you're best to use Auto Roll mode where the full 14 Mpts is available.

[kcbrown]

Got another question.

I noticed that in roll mode, the sample memory is cut by a factor of 10.  Why is that?  A factor of 10 seems excessive.  What's the rest of the memory being used for?  Certainly not history -- that's disabled in roll mode.

IDK for dedicated Roll mode however if max mem depth is what you need in Roll mode you're best to use Auto Roll mode where the full 14 Mpts is available.

I see no mention of auto roll mode anywhere in the manual, nor any mention of a setting that would control that.  How does one enter it?   Merely increasing the time/div doesn't seem to do it on its own.  I could swear there's a setting that controls this but I can't for the life of me find it.

[masterx81]

You'll get clipping if you increase the vertical gain while the scope is operating, but when the scope is stopped, the vertical zoom just acts as a standard zoom.  So try stopping the scope first and then zoom in using the vertical scale knob.

The scope converter only has so much resolution, however, so what you really want to do is to set the vertical settings so that the waveform fills as much of the screen as you can manage.  This will ensure that the opamps remain unsaturated while also ensuring that you have maximum use of the ADC resolution.  You can then zoom in from there with the scope stopped.   There may be limitations in terms of what you can do with respect to zooming in like that, but from what I've seen, you'll easily be able to zoom in vertically to the point where you can make out the individual value transitions within the number of bits per sample recorded.

Thanks! So i suppose that there isn't a way to zoom with the scope running...

[rf-loop]

Got another question.

I noticed that in roll mode, the sample memory is cut by a factor of 10.  Why is that?  A factor of 10 seems excessive.  What's the rest of the memory being used for?  Certainly not history -- that's disabled in roll mode.

I see no mention of auto roll mode anywhere in the manual, nor any mention of a setting that would control that.  How does one enter it?   Merely increasing the time/div doesn't seem to do it on its own.  I could swear there's a setting that controls this but I can't for the life of me find it.

AFAIK, Roll mode can use with time scales 50ms/div - 100s/div and in Roll mode max memory is 1.4M (2x1.4M)
No trigger. It just roll like paper roll plotter. Its memory lenghth is 1.4Mpts. with 50ms/div it have its maximum samplerate what is 2MSa/s. This is also noted in Performa01 deep review and looks like these is still peoples who have not read these nearly 200 pages information. What ever question have read it first and if answer can not find there directly or indirectly...
 Peak detect is available also in roll mode of course. Average and ERES not.
New samples are plotted to display horizontal border and old samples are pushed like FIFO.
It is its limits, like or not. It is made that way. Period.
(Disclaimer, I have not used latest firmwares but I do not believe this thing change, it do not sell any more if it change. )


If need more memory and samplerate using 50ms/div - 100s/div then just do not use ROLL mode. Normal acquisition with Auto trig or Normal or Single shot. Max memory is then 14M with 2 channels on and with 50ms/div max samplerate naturally 20MSa/s.  Of course in then can live with les samplerate but need more history then just reduce memory length.
With 7k memory 2 channel in 1 group open, 100s/div it have 5 sample/s and it can save up to  3912 these 1400 second acquisitions sequentially. 5476800s data (63 days) plus (sadly too big) time cap between single acquisitions.

[kcbrown]

AFAIK, Roll mode can use with time scales 50ms/div - 100s/div and in Roll mode max memory is 1.4M (2x1.4M)
No trigger. It just roll like paper roll plotter. Its memory lenghth is 1.4Mpts. with 50ms/div it have its maximum samplerate what is 2MSa/s. Peak detect is available also in roll mode of course. Average and ERES not.
New samples are plotted to display horizontal border and old samples are pushed like FIFO.
It is its limits, like or not. It is made that way. Period.
(Disclaimer, I have not used latest firmwares but I do not believe this thing change, it do not sell any more if it change. )

I'm using the latest firmware, and it does behave like this.

Well, it is what it is.  I'd love to know why it's limited in this respect because it leaves a big pile of memory on the table.  But only the Siglent engineers can really say, I guess.  It just seems odd to leave that amount of sample memory (12.6M points!) on the table when you presumably don't really have to.

Thanks for confirming that.

If need more memory and samplerate using 50ms/div - 100s/div then just do not use ROLL mode. Normal acquisition with Auto trig or Normal or Single shot. Max memory is then 14M with 2 channels on and with 50ms/div max samplerate naturally 20MSa/s.  Of course in then can live with less samplerate but need more history then just reduce memory lenght.
With 7k memory 2 channel in 1 group open, 100s/div it have 5 sample/s and it can save up to  3912 these 1400 second acquisitions sequentially. 5476800s data (63 days) plus (sadly too big) time cap between single acquisitions.

Right, I realize that you can basically get what amounts to nearly arbitrarily long (in time) captures in normal mode (not quite arbitrarily long, but 63 days total is pretty hard to argue against!).  Roll mode has the distinct advantage that you can see it in progress.  And it looks cool. 

[kcbrown]

Thanks! So i suppose that there isn't a way to zoom with the scope running...

Without running afoul of the possibility of opamp saturation and other such issues?  No, not to my knowledge.  And that's because the knob controls both the interpretation of the ADC output for display purposes and the signal gain.  Which is almost always exactly what you want, really, because the purpose isn't just to show a different part of the waveform, but to show that part with as much resolution as the scope can bring to bear.   The latter requires changing the amplifier gain and offset so that what gets fed to the ADC meets its input requirements in such a way that its output has maximum resolution over the voltage range that would be visible on the display at that setting.

For instance, let's say that you've got the scope set up to display 4.0V to 4.8V, at 0.1V/div.  That means that the voltage fed to the ADC would have to be shifted so that 4.0V on the scope input would wind up being 0V at the ADC, and 4.8V on the scope input would wind up being whatever voltage the ADC would translate to its maximum converted value.   If the input voltage range of the ADC is 0V to 1V, then after subtracting 4.0V from the input, the remaining signal would have to be amplified via a gain of (1.0V/0.8V = 1.25). 

The above is, of course, a significant oversimplification (in reality, things seem to be arranged so that some of the waveform can extend beyond the screen edges, and there are likely many other considerations on top of that), and there are probably papers that rf-loop and others here can point at which would describe in detail the process that modern DSOs use to translate an incoming signal to something on the screen, but it should at least answer the question of why your vertical settings matter for things like the internal signal amplification.

You can see this in action by significantly decreasing the V/div so that the waveform in full extends well above and below the edges of the screen, then stop the scope, and then increase V/div.  There will be a bit of waveform that extended past the edges of the screen, but not terribly much.

[kcbrown]

Sigh.

Has anyone managed to get i2c triggering on 7-bit addresses working?  Triggering on message start works. 

With respect to triggering on 7 bit address + value:

* It works when I set everything to "don't care".
* It works when I set a data value that's present
* It works when I set the read/write attribute to match what's present (and it won't trigger if I get this wrong, which is good)
* It works with combinations of data value and read/write that actually match what's present
* It does *not* work with any combination where I set the address, at least with the signal that I'm using (an Arduino's output to an i2c display), even when the address value I set matches what the decoder consistently shows.

I've already tried things like using the 20 MHz bandwidth filter on the probes.  It makes no difference.  And frankly, if the decoder can find the address, why can't the triggering mechanism do the same?

What data would you guys like for diagnosis of this?

Here's proof that the address I'm having it search for is present in the signal:



And here's what happens when I set the trigger to use that address and hit "single" or "normal":

[2N3055]

Sigh.

Has anyone managed to get i2c triggering on 7-bit addresses working?  Triggering on message start works. 

With respect to triggering on 7 bit address + value:

* It works when I set everything to "don't care".
* It works when I set a data value that's present
* It works when I set the read/write attribute to match what's present (and it won't trigger if I get this wrong, which is good)
* It works with combinations of data value and read/write that actually match what's present
* It does *not* work with any combination where I set the address, at least with the signal that I'm using (an Arduino's output to an i2c display), even when the address value I set matches what the decoder consistently shows.

I've already tried things like using the 20 MHz bandwidth filter on the probes.  It makes no difference.  And frankly, if the decoder can find the address, why can't the triggering mechanism do the same?

What data would you guys like for diagnosis of this?

Here's proof that the address I'm having it search for is present in the signal:



And here's what happens when I set the trigger to use that address and hit "single" or "normal":

I would like to just add: There should be ( on any scope that does decode/trigger from serial protocols ) a button "copy this decoded frame to trigger".
You look around the list, find interesting packet , select and copy it to trigger.... That would be huuge timesaver...
Sorry for the tangent...

[kcbrown]

I would like to just add: There should be ( on any scope that does decode/trigger from serial protocols ) a button "copy this decoded frame to trigger".
You look around the list, find interesting packet , select and copy it to trigger.... That would be huuge timesaver...
Sorry for the tangent...

No worries, that's a great idea!   Here's hoping Siglent will consider it.

Of course, it'll be even better in conjunction with a trigger mechanism that works completely correctly.   

[thaistatos]

With SDS1202X-E firmware revision 1.3.23 (or 7.0.1.3.23 seen on scope 'system' screen), the 'Link to Trigger' button on the DECODE page 2 has been changed to 'Copy Setting.'  This adds the ability to not only link the DECODE to the trigger ('Copy To Trig'), but to link the trigger to the DECODE (Copy From Trig).  Both options are on a submenu of 'Copy Setting.'

Does this help?

[2N3055]

With SDS1202X-E firmware revision 1.3.23 (or 7.0.1.3.23 seen on scope 'system' screen), the 'Link to Trigger' button on the DECODE page 2 has been changed to 'Copy Setting.'  This adds the ability to not only link the DECODE to the trigger ('Copy To Trig'), but to link the trigger to the DECODE (Copy From Trig).  Both options are on a submenu of 'Copy Setting.'

Does this help?

As far as I know that copies only setting (levels, channels etc). It won't copy address/data of the packet, would it?

[kcbrown]

Just in case the issue was with the signal and not with the trigger, I tested the address trigger problem with the digital channels.  I get the same result.  Triggering on i2c 7-bit addresses simply does not work at all.

Can someone here replicate this issue?  Seeing how i2c is a multi-address bus, it seems like a significant problem for address triggering to not work at all.

[kcbrown]

Aha!   Figured it out.

It wasn't a problem with the trigger, it was a problem with the decoder!

The actual address on the bus is 0x27, not 0x4e.

I reset the scope (hard powered it off and let it boot back up) and set things back up, and now it's working properly.  And so is the decoder.

I don't know why there was that discrepancy, but things like this can happen.

Anyway, please disregard the previous, unless you'd like me to supply the raw data (which I saved) so you can see it for yourself.  I guess next time I'm going to have to examine the signal properties myself to see if the decoder is doing things right.

Sorry for the false alarm.   


I suppose the moral of the story is: if you think you've found a bug in the scope, the first thing you should do is reboot the thing.  A soft shutdown and startup probably won't do the trick for that.  In this case, I pushed the power button until it turned off "hard" (works the same as it does on laptops), and then powered it back up.  The scope came back up in its default state, after which I configured it from scratch, and that pretty much took care of the problem.