Siglent SDS2000 new V2 Firmware

[Performa01]

MSO – Digital Channels

This is a short review of the digital channels that make for the SDS2000 MSO functionality, and there are two bugs right from the start:

1.   After enabling ‘Digital’, all digital channels appear at the same vertical screen position (as already shown in an earlier post). Only pushing the ‘Position’ knob in the vertical section where also the ‘Digital’ button sits, automatically aligns them in a way we’d expect it to be right from the beginning.

2.   The ‘Variable’ control in the vertical section where also the ‘Digital’ button sits can be used to select a specific digital channel, which is then highlighted in red. Turning this control should select the digital channels in a consistent order 0~7, but by en-/disabling individual channels in the soft menu we easily get into a state where channel selection has discontinuities or even goes all over the place, which is rather confusing.

The bugs mentioned above are still relatively easy to handle, so we can continue the test with some real signal.

It should be noted that with digital channel enabled, memory is generally restricted to 14Mpts maximum for both analogue and digital, except for 1ms/div timebase with only one analogue channel per group enabled, where we can get a combination 28Mpts for analogue and 7Mpts for digital. Maximum sample rate for digital channels is generally limited to 500MSa/s.

The signal is a 7 bit counter changing state every 200ns and stopping for about 1µs at every 19th edge, thus creating some interesting stream of bursts.
On top of that, the MSB (D7) is fed with an asynchronous pulse <10ns wide at a repetition rate of slightly more than 1µs.

The basic settings for my tests are maximum memory, peak detect acquisition, x interpolation, vector display.

Analogue channel 4 is hooked up to the LSB of the basic counter in parallel with the digital channel D0, in order to see the time skew between analogue and digital channels – but we have to expect some inaccuracies here due to the different signal path through the analogue probe and the additional capacitive load.

Trigger is set to the falling edge of the analogue signal on Ch. 4.

Digital bus decoding has been set to display all 8 bits at once, which should give some interesting pattern, when the short, asynchronous pulse on D7 appears at random positions.

A detailed view of the signals can be seen in the following screenshot (Digital_Signals_200ns)



As can be seen, everything looks fine so far. Digital channels appear blue when low or falling edge and green when high or rising edge, which I think is a great idea. The digital channel currently selected by the ‘Variable’ control next to the ‘digital’ button is displayed in red and I haven’t found a way to disable that, but then again it’s also nice to have one particular channel stick out.

The bus decoding on the bottom of the screen shows the correct results and at this timebase setting, space is way too narrow to display any values when the short pulses occur, as has been expected.

I should also mention that despite the bus decoding, screen update is as quick as it can get and measured waveform update rate is about 2500/s in this scenario.


The next screenshot shows a detailed view of the trigger point at a timebase setting of 5ns/div (Digital_Signals_5ns_Probe_D0)



As can be seen, there is a delay of precisely 6ns from digital channel D0 to analogue channel 4, so the digital channels have less trigger delay. But when talking about delay times of a few nanoseconds, it’s quite obvious that the digital and analogue probes cannot be exactly the same and I will repeat this test with a direct coaxial connection to the analogue channel in a subsequent post.

We also see a slight uncertainity at capturing the digital channels, as the transition of D3 occurs 2ns later compared to D0 and D1. Interestingly, we still get a valid bus decoding (0C) for that misaligned portion of the signal at the bottom of the screen.

In general, we cannot expect a timing accuracy of better than +/- 2ns at a digital sample rate of 500MSa/s.


Now let’s have a look at a huge amount of data. At a timebase of 2ms/div, digital and analogue channels both run at 500MSa/s with 14Mpts of memory and the picture we get is a little boring (Digital_Signals_2ms)




If we zoom in 1000x by lowering the timebase to 2µs/div (in stope mode), we get a good overview of what’s actually going on here (Digital_Signals_2ms_2us)




Bug: The bus decoding at the bottom of the screen is a fair bit misaligned though. The displayed values should be aligned with the gaps in the D0 burst signal, but the first one (7d) is already about 1µs late, and it gets progressively worse and ends up with a lag of some 3µs for the last value (49).


If we zoom in even further, 10000x at a timebase of 200ns/div, bus decoding gets well aligned again (Digital_Signals_2ms_200ns)




With a zoom factor of 200000 at 10ns/div, we find a serious mismatch between analogue and digital channels (Digital_Signals_2ms_10ns_Probe_D0)



Now D0 is about 44ns late with regard to Ch. 4, which doesn’t appear too bad at first, considering the huge zoom factor, but then again I still wouldn’t expect more than 10ns, as we saw a skew of 6ns earlier, where Ch. 4 was sampled at 2GSa/s and it now is at 500MSa/s, which might introduce another 2ns of uncertainty. Even more surprising, the skew has changed sign, i.e. the digital channels now lag the analogue one.


Finally let’s have a look at Zoom mode (Digital_Signals_2ms_Zoom_200ns_D40us)



While it certainly works for the signal traces, it does not for the digital bus decoding, which shows just nonsense. Bug alert!


Conclusion

Digital channels are basically working just fine, apart from the two bugs regarding initial channel position and slightly random channel selection mentioned at the start of this review.

Digital bus decoding is fine in many regards, especially its response to narrow pulses, but still has some alignment issues as shown in this review. A big issue is the zoom mode, where it’s just displaying nonsense.

The correlation between digital and analogue seems fine too, except when zooming into a long waveform, where the error can get surprisingly high at up to 50ns (from +6 to -44ns).

[Performa01]

MSO – Digital Channels Pattern Trigger

Now that we’ve seen digital channels basically working, we would like to know if we can trigger on a digital word by means of the pattern trigger. In particular, I wanted to know if the trigger reliably captures narrow pulses on the digital channels.

The setup is pretty much the same as in my previous post, but as triggering on narrow pulses is a major topic here, we want to examine these pulses a little closer and also repeat the channel skew test without the analogue probe.

I’ve now connected Ch. 4 to the pulse generator directly via a coaxial cable and activated the 50 ohms termination on the scope input. I’ve used a BNC T-adapter at the generator output to tap off another signal for the logic probe and fed it there over a coaxial cable of equal length. Of course this arrangement introduces a considerable mismatch and we will see a 2nd (reflected) pulse about 10ns after the initial one, which is double the time the pulse travels through 1 metre of coaxial cable with a velocity factor of about 0.66 (1m forward, then 1m return) and is because the end of the cable connected to the digital probe isn’t properly terminated. This reflected pulse is about 30% the amplitude of the initial one, so the return loss is still high enough to make reasonable measurements.

First we look at the pulse delay from digital to analogue (Digital_Trigger_Delay)



As can be seen, the analogue channel is still late, but it’s only by 1~4 nanoseconds, which is within the range of expectations for a 500MSa/s LA and a casual setup like this. In particular, it should be way accurate enough for practical tasks, where we have to correlate analogue with digital signals.

This picture also shows the pulse width to be slightly under 4ns at the threshold level of 2.5V that I’ve set for the digital channels as well as for the analogue trigger.


Now for the actual triggering. The pattern trigger setup includes analogue and digital channels at the same time, which is exactly what we want. For this test, I leave the analogue channels alone and just use the simplest possible digital trigger word for a start (Digital_Trigger_Setup)



The trigger condition is very nicely displayed on the right info bar with don’t cares for all channels except D7, which is set to high.

It can be seen that the trigger shows some unexpected 20ns lag, but other than that it works reliably.

Now let’s try a full qualified trigger word HHHHHHLL and see what we get (Digital_Trigger_11111100_50ns)



Well, the result is similar to before, but now the trigger only fires when D0 and D1 are low and all others, including D7, which is connected to the narrow pulse, are high. The 20ns lag is still there.


Now let’s try that with a huge amount of data again at 2ms/div (Digital_Trigger_11111100_2ms)




As there is nothing much to see, we immediately zoom into the waveform 2000 times by lowering the timebase to 1µs/div (Digital_Trigger_11111100_2ms_1us)



At this timebase setting, triggering appears to be a bit early, but still accurate enough. The bus decoding only works occasionally and appears a bit misaligned, just as we’ve seen it before.


If we zoom in even further at 200ns/div, we can see the trigger is indeed almost 30ns early for a change. So there generally seems to be a uncertainty of that magnitude, which I don’t have an explanation for. At least the trigger condition is met correctly (Digital_Trigger_11111100_2ms_200ns)




Conclusion

Triggering on the digital channels works almost as expected, but I cannot think of any real reason why there has to be that rather high uncertainty of at least +/- 30ns, that I’ve observed in the test.

[Mark_O]

MSO – Digital Channels

This is a short review of the digital channels that make for the SDS2000 MSO functionality...

Nicely done coverage of the MSO section.

As can be seen, there is a delay of precisely 6ns from digital channel D0 to analogue channel 4, so the digital channels have less trigger delay. But when talking about delay times of a few nanoseconds, it’s quite obvious that the digital and analogue probes cannot be exactly the same and I will repeat this test with a direct coaxial connection to the analogue channel in a subsequent post.

One thing that may help there is if the analog channel menu has a Deskew Setting on Page 2 (as the 1000X does).  That could be used to bring the analog and digital channels back into alignment (at least initially).  Though it would do nothing to rectify the 50 ns shift in that relationship which you observed later.

One thing to keep in mind is that as clean and well-defined as the digital traces look, they are still based on a user-set threshold-level.  And that threshold is adjustable.  While your digital generator is "fast enough" in the context it's being used, your scope traces indicated an ~18ns fall-time (and presumably similar rise-times).  That throws a fair amount of uncertainty into the process, which significantly exceeds the 2ns you (correctly) attributed to sampling resolution.

In addition to that, the digital channels will have a certain amount of hysteresis built-in (if they're any good), which will contribute to the uncertainty.  On a rising-edge the digital state will be delayed, as will the state-transition on a falling edge.  They generally balance out fairly well (assuming similar rise & fall rates), so the pulse-width itself isn't impacted too badly, but the pulse position will definitely be affected.

NB:  But just by adjusting your digital threshold level, you should be able to watch the skew between the A and D channels shift.

[Performa01]

Trigger puzzle

In preparation of another test I stumbled across some funny phenomenon with the trigger system.

Have a look at the screenshot (Trigger_Puzzle_10ns)



Yeah, nothing special – just a pair of narrow pulses spaced some 10ns apart – and the SDS2000 shows a rock stable triggering here, no worries whatsoever. I use rising edge trigger without any specialities and the trigger level is somewhere near half the signal amplitude, but that doesn’t matter anyway. The curious thing is that the scope reliably triggers on the 2nd pulse, whereas I’d have thought there should be a bigger chance to trigger on the first one.

Why is it so?

Just out of curiosity I adjusted the pulse spacing and at 24ns I finally got this (Trigger_Puzzle_24ns)



Now we got like a 50% chance to trigger on the first pulse. Still not quite what I’d expected, yet a fair bit closer. And in this case, no amount of trigger holdoff would change the picture either, which is also rather surprising.

Pulse and Interval triggers didn’t work either.

With the minimum holdoff time of 100ns, I had to increase the pulse spacing to 30ns, in order to get a stable triggering again (Trigger_Puzzle_30ns_H100ns)



Without holdoff, the occasional triggering on the 2nd pulse can still be seen as a faint image (Trigger_Puzzle_30ns_HC)




So I’ve finally found a case, where the scope proved unable to trigger on a signal.

To sum it up:
With a pulse spacing > 30ns we can get stable triggering by means of the trigger holdoff.
With a pulse spacing 19 ~ 29ns we can’t get a stable triggering.
With a pulse spacing < 19ns we get stable triggering on the 2nd pulse unexpectedly.

Granted, that’s no big deal, it is just the very special case of a pair of narrow pulses that have a spacing in the range of 20.to 30ns (triggering on the 2nd pulse for a spacing below 20ns is certainly acceptable).

[Performa01]

One thing that may help there is if the analog channel menu has a Deskew Setting on Page 2 (as the 1000X does).  That could be used to bring the analog and digital channels back into alignment (at least initially).  Though it would do nothing to rectify the 50 ns shift in that relationship which you observed later.

I’ve already demonstrated the deskew option to work fine in one of my earlier posts in this thread, and yes, I’ve actually tried it in this situation as well – and it worked a treat.
I still didn’t mention it in my review, as I thought it was ridiculous to try to compensate for a few nanoseconds, when we already have a sampling uncertainty of 2ns for digital and at least 500ps for analogue.

One thing to keep in mind is that as clean and well-defined as the digital traces look, they are still based on a user-set threshold-level.  And that threshold is adjustable.  While your digital generator is "fast enough" in the context it's being used, your scope traces indicated an ~18ns fall-time (and presumably similar rise-times).  That throws a fair amount of uncertainty into the process, which significantly exceeds the 2ns you (correctly) attributed to sampling resolution.

Look closer. The automatic measurement of the fall time is not valid in the screenshot you’re regarding to, as it takes some 10ns for the last 20% of signal amplitude to actually reach the ground level. Actually, it takes less than 5ns to approach the 2.38V trigger level. In later screenshots you can see even the automatic measurements indicating rise and fall times between 8 and 10ns.

In addition to that, the digital channels will have a certain amount of hysteresis built-in (if they're any good), which will contribute to the uncertainty.  On a rising-edge the digital state will be delayed, as will the state-transition on a falling edge.  They generally balance out fairly well (assuming similar rise & fall rates), so the pulse-width itself isn't impacted too badly, but the pulse position will definitely be affected.

That's certainly true and also the reason why I didn't look further into it when I observed a channel skew of just about 2ns in my digital trigger test. By this result I was convinced that initial matching between channels on the time axis is not an issue

NB:  But just by adjusting your digital threshold level, you should be able to watch the skew between the A and D channels shift.

That’s the reason why I explicitly set the digital trigger level to 2.5V and yes, I failed to make the analogue trigger level exactly the same for the first test, but 2.36V should still be close enough, especially considering that the analogue and digital triggers would most likely be very different in their nature.
We know that the analogue trigger is digital, based on the sampled data. This cannot be the case for the digital channels, as there is just one bit per channel, so it has to be analogue…

[Performa01]

Sequence Mode

There is one item under the Acquisition menu still unexplored – the sequence mode, which is supposed to give us an immense boost in waveform update rate. Well, let’s try that.

I’ve set up a double pulse that’s repeated every 100ns (Sequence_Signal_Overview)




The scope was set to peak detect mode with x interpolation, dots display and 14Mpts of memory, as this should be sufficient for up to 100000 segments of 140 point each..

Then I tried to set the number of segments, but gave up after several minutes with hurting fingers at 50001. This is another instance, where the ‘Adjust’ knob is just useless – nobody has the time or patience to sit there for minutes in order to wind up some value – or maybe we should use our Proxxons or Dremels in order to spin that knob? Okay, later on I discovered that I just needed to turn the knob counter-clock-wise a tiny bit in order to get to the maximum value of 80000, but what if you really want 40000 for some reason. Anyway, my test was done with 50001, for I was only able to dial in odd numbers for some odd reason (Sequence_Menu)




I had to figure aut how the sequence mode is intended to work. First I just hit the ‘Acq. Mode On’ button and watched the screen, where we can see a counter reporting how many segments have been captured (that doesn’t make it on the screenshot for some reason). In my scenario, the entire process is lightning fast and the 50k segments are captured several times per second.

I eventually hit the Run/Stop button and examined the history menu, but found just a couple thousand entries there. Of course not – it is all about filling the buffer at max. speed, and once it is filled, rearm and start over again – it is not a ring buffer. So I changed over to single shot trigger mode and sure enough, that finally worked. Hitting the ‘Single’ button once starts the sequence and fills the buffer, then there is a short break where some post-processing is going on and after that the scope goes into stop automatically. Now we can examine the history.

There we have the first 7 captures in in the history list (Sequence_List_1)




And here’s the last 7 entries, ending with 50001 (Sequence_List_50001)




Looking at the timestamps, it took 172434µs to capture 50001 waveforms; that is 3.4486µs per waveform or 290k waveforms per second – more than twice as fast as the maximum waveform update rate in normal operation. Not bad at all.


Now things certainly slow down a bit when we use vector mode and some might not like the appearance of just dots on the screen when there are just a few samples available. But that’s not an issue, as we can change the display mode to vectors after the capture if we really want to (Sequence_Display_Vectors)




Conclusion

Sequence mode is a nice feature – pretty much a single shot capture of many trigger events at the highest possible waveform capture rate. Of course we will still miss lots of trigger events, just as in my scenario at least 10 million waveforms per second would be required in order to capture everything. Nevertheless a nice complement to the history mode! 

[Performa01]

Channel Skew and the Impact of analogue probes

By reviewing the digital channels, I attached great importance to the time skew between analogue and digital channels and repeated the test without the analogue probe in my digital trigger review, where I finally ended up with a skew just over 2ns. The effect must have something to do with the internal signal processing in the scope, as the digital channels were always faster in these tests. Even in the digital trigger test, the transition on the digital channel can be seen at a point, where on the analogue channel the signal has not even begun to change its state.

It seems clear to me, that all channels will be deliberately delayed quite a bit within the scope and the firmware just tries to balance those delays in a way that all channels are reasonably in sync on the time axis. This is the only way to get digital and analogue channels in sync, and without it, the ‘Deskew’ option for individual analogue channels would not be possible – and this has an adjustment range of +/- 100ns!

After drawing that conclusion, there’s still one question left.

What impact does the analogue probe have on a fast signal?

To answer that question, I’ve set up a little test with a BNC-T-adapter directly at the generator output, that connects Ch. 4 directly via 1m RG58 coaxial cable whereas Ch. 2 is hooked up using the analogue probe and the BNC probe tip adapter (Probe_Impact_2ns)




We see three versions of the same narrow pulse in this screenshot.

The blue reference waveform is the undistorted original pulse with the analogue probe not connected.

The green Ch. 4 trace shows the same pulse with the analogue probe connected. We see that the rising edge gets a bit slower and the peak amplitude is slightly decreased, as well as a bit more pronounced ground level disturbance right after the pulse. All these effects come from the additional capacitive load introduced by the probe.

The magenta Ch. 2 trace shows the same pulse as it is seen by the analogue probe, and the difference is quite obvious now. In particular, we have a lag of 640ps, a more flat top with reduced amplitude and way more disturbances after the pulse.

The same situation again, but without reference waveform and cursors and at a slower timebase of 5ns/div in order to show the differences and particularly the disturbances more clearly (Probe_Impact_5ns)




This little experiment shows (at least) two things.

1.   The probe introduces about 640ps time delay compared to a straight coaxial connection. This is insignificant on a 300MHz scope.
2.   Nothing beats a properly terminated coaxial line. There are very little disturbances after the pulse compared to the signal delivered from the oscilloscope probe.

[rf-loop]

About Sequence mode speed.
It is bit complex to show every things about its speed.
Bit about memory. Example: 500ns/div  and 1 channel used.
Segment lenght is 14000 points. Inside one Sequence max count of segments is 6468. It use 90552000 points of memory.

When user want use this Sequence mode it need know how equipment works and how to do optimal settings for different aplications.
DSegment maximum speed is only one thing what is not meninful in many applications, say example quite low repeating radar pulses.

One use for Sequence mode is case where is qquite slow repeating fast pulses and we are not interested of mean time. If example have 50ns pulses repeating 100ms period and we want inspect these pulse shapes.
With 80000 segments we can capture 80000 pulses ans this recording take 8000 seconds.  If take continuous record with big memory it need 16Tera points memory. Ok, Sequence mode we have only small slices of time... true, but scope is also wakeup in mean times and if there happend trigger events (example extra pulses/glitches what trig we can also get these! if they happend after trigger recovery time what is down to 2us)



Some day I hope I can finish better table but before this work I will wait least next or second  FW upgrade so that things are more mature.

[Mark_O]

I’ve already demonstrated the deskew option to work fine in one of my earlier posts in this thread, and yes, I’ve actually tried it in this situation as well – and it worked a treat.

My apologies for missing that.  I have read all your findings, but I found them late, and tried absorbing them all over the last week.  Obviously, I went too fast on some.

I still didn’t mention it in my review, as I thought it was ridiculous to try to compensate for a few nanoseconds, when we already have a sampling uncertainty of 2ns for digital and at least 500ps for analogue.

It was 6 ns, and I didn't feel it was ridiculous to try to compensate for that.  But it's OK if you did.

Look closer. The automatic measurement of the fall time is not valid in the screenshot you’re regarding to, as it takes some 10ns for the last 20% of signal amplitude to actually reach the ground level. Actually, it takes less than 5ns to approach the 2.38V trigger level. In later screenshots you can see even the automatic measurements indicating rise and fall times between 8 and 10ns.

OK.  You are correct, that I did need to look closer.  Thanks.

We know that the analogue trigger is digital, based on the sampled data. This cannot be the case for the digital channels, as there is just one bit per channel, so it has to be analogue…

That sounds a bit ironic.  Analog channels having digital triggers.  And digital channels having analog triggers. 

[Performa01]

Sequence Mode Speed reviewed

When looking at the table published by rf-loop, the maximum waveform update rate for 5ns/div timebase (140 points/segment) ahould be 440k, whereas I’ve never seen more than 290k in my tests, so I thought I’d take a closer look at that discrepancy.

First I  want to share some general thoughts about sequence mode. It should be obvious that this mode is meant for situations where we have periodic events with considerable idle states (that are of no interest) between them. Segmented memory (or Sequence Mode, as it is called here) is the ideal tool if we want to capture as many events as possible without wasting precious memory by recording the idle phases as well.

This is also the reason why I’ve set up my previous test the way I did:
I created some interesting signal event – the double pulse – at a repetition rate of 10MHz, i.e. the event repeats every 100ns. This is about the limit where sequence mode in general starts to make sense, because at 5ns/div, one segment already covers a time span of 70ns.

At a sample rate of 2GSa/s and with 70Mpts of memory, we could cover a total time span of 35ms, so we could capture a total of 350k events with one traditional single shot recording.
With segmented memory and 70ns = 140 points per segment, it could be 500k events, which is only slightly more.
So while my test setup would generally be the limit case where segmented memory starts to give some benefit, this is not true for the SDS2000, as it is limited to 80000 segments maximum. But of course that doesn’t make the test pointless, as it could still show how sequence mode works and what kind of speed is to be expected. And of course one of the motivations to use 5ns/div was that the SDS2000 shows the highest waveform update rate at this timebase in normal operation.

Even though my test wasn’t meant to show the absolute maximum speed that could be achieved, it is still puzzling why it only yielded 290k as opposed to the 440k that rf-loop has measured.
The obvious difference is the signal frequency – 50MHz sine as opposed to 10MHz double pulse. Of course signal frequency has an impact. In a worst case scenario, the freshly re-armed trigger just misses an edge and has to wait for the next one, and this lost time gets shorter with higher signal frequencies.

On the other hand, a 50MHz sine isn’t a realistic test scenario, as no one would use segmented memory for a signal like this. 10MHz should be fast enough and it really shouldn’t make any noticeable difference as long as we’re talking about waveform update rates well below 1000k. Yet I had to try and use a 50MHz sine in order to see what I get. Guess what – it was exactly 290k again. So the signal frequency was not the critical parameter here, just as predicted.

What else could it be?

There’s nothing left but trying all possible combinations of acquisition and display parameters in order to see what makes the difference. I did not try different trigger modes, just DC-coupled edge triggering without any specialities. I also kept using the 50MHz sinewave as the signal source. Other common settings are single channel (4), fast acquisition and 80k segments.

I never managed to get more than 292709 waveforms per second at 5ns/div timebase. As was to be expected, display type (dots/vectors) and acquisition (normal/peak detect) didn’t make the slightest difference, but sin(x)/x reconstruction does, reducing the update rate to just 129k.

So I didn’t get there. Would the initial selected memory depth make any difference? That would be simply a bug, as the actual amount of memory used doesn’t change as long as there is enough available to fit the specified number of segments. So I tried different memory settings also, but as expected, it didn’t change anything.

Finally I tried the fastest setting, according to rf-loop’s table, i.e. 50ns/div. It was indeed a little faster, about 315800 waveforms per second, but nowhere near the claim of 500k.

So what the heck is going on?

Finally, in a desperate attempt to solve this puzzle, I changed the input channel from 4 to 1.
And what do you know – at 5ns/div. I got a waveform update rate of 444483.95 frames per second!

Big Question: Why is channel 4 so much slower than channel 1?

I have tested all four channels and sure enough, channels 1 and 2 show the speed as indicated by rf-loop. Channels 3 and 4 are significantly slower.

I couldn’t be bothered to check any other timebase settings, as I’m pretty confident that rf-loop’s table will be valid for channels 1 and two, whereas channels 3 and 4 will be about 2/3 of that speed – at faster timebases at least, maybe they catch up at the slower ones.

See attached table for the complete results (Sequence_Mode)




EDIT: Replaced the table with correct size

[Performa01]

It was 6 ns, and I didn't feel it was ridiculous to try to compensate for that.  But it's OK if you did.

Sorry, my response on this was sloppy and 6ns would indeed justify the use of the deskew option in certain situations.
The true reason why I didn’t mention it in my review was because I thought it’s just too obvious and goes without saying that one could use the deskew to align the channels, and the fact that the sample uncertainty adds some jitter that makes it pointless to try to compensate for better than +/- 2ns.

OK.  You are correct, that I did need to look closer.  Thanks.

What I forgot to mention was that if you look close, you can see that the digital edge is at a time where the analogue channel has not even started slewing, so apart from the fact that the transition times aren’t as bad as 18ns, the traces on the screen clearly indicate that they cannot play a role for the amount of lag observed.

That sounds a bit ironic.  Analog channels having digital triggers.  And digital channels having analog triggers. 

Well, that’s what I thought too when I wrote this
But then again, nothing wrong with an analogue trigger when we expect fairly fast transitions. Every single logic gate has an analogue (sometimes Schmitt) trigger built in after all

[rf-loop]

Sequence Mode Speed reviewed

When looking at the table published by rf-loop, the maximum waveform update rate for 5ns/div timebase (140 points/segment) ahould be 440k, whereas I’ve never seen more than 290k in my tests, so I thought I’d take a closer look at that discrepancy.

First I  want to share some general thoughts about sequence mode. It should be obvious that this mode is meant for situations where we have periodic events with considerable idle states (that are of no interest) between them. Segmented memory (or Sequence Mode, as it is called here) is the ideal tool if we want to capture as many events as possible without wasting precious memory by recording the idle phases as well.
----
On the other hand, a 50MHz sine isn’t a realistic test scenario, as no one would use segmented memory for a signal like this. 10MHz should be fast enough and it really shouldn’t make any noticeable difference as long as we’re talking about waveform update rates well below 1000k.

Yes, this is also what I think but for finding maximum speed I have used this signal. (also searched wide span of frequencies and there is big freq band where I can get same result, not only 50MHz what is some kind of middleway compromise)

Why it is also important that segmented memory acquisition is fast. As you tell mostly this function is used for - just as you tell.  But still it is important it can capture fast agen if there happend some spike or extra pulse, high glitch etc. This is why also Hewlett-Packard (so sorry it is today Keyshit after Fiona catastrophe when it was destroyed to Agilent)  argument for segmented memory speed (trigger recovery time).

In different aplications user need find optimal settings for just this individual case and for this, there ismportant thing: "Know your equipment".

----

This whole case need bit more inspections because in FW there is something wrong and/or not optimal.
Example why heck Sinc is mixed there in sequence mode for timebases 1ns/div to 20ns/div. Segmented memory cquistion do not need anything but push as fast as possible raw ADC data to memory and nothing - nothing else. When scope is stopped for analyzing captured segments there user can use Sinc and/or vectors or what ever he want. (and tools for inspect these segments need develop better. There is not even  possible stack segments over segments in playback (or select buffer how many is stacked (overlayed) for better finding anomalies, no persistence available, etc. But first acquisition need work without any problems and - please Siglent - do something for this multifunction knob useability/ergonomy)

There is also some other mystery with wfm/s speed (time ago I have also informed Siglent about some problem with scope wfm speed in some "semirandom" cases). Some times it go only bit over 70kwfm/s and then suddenly after some playing with knobs/buttons and then it reach full 140kwfm/s.  I have not find "logick" how this happend. And do this have also something to do with second channel group (CH3 and CH4) speed. Next I will check what maximum I can find with CH4 (or 3). Limiting factor is some lack of time for this...


Add:

---------

Finally I tried the fastest setting, according to rf-loop’s table, i.e. 50ns/div. It was indeed a little faster, about 315800 waveforms per second, but nowhere near the claim of 500k.

I can confirm this. (Measured)  If CH3 or CH4 alone on, just this.
If both, CH3 and 4 are open, just around 10kwfm/s more.

But after then I find also more interesting things related to CH on off combination and also together with t/div settings that this need check better. Question is how much is wise to do investigations if next FW agen change things (and hope remove difference between channel groups)

Also there is intersting finding for rare glitch hunting if think average wfm/s speed.

But here two of these intersting findings (but only for 1GSa/s speed)

1. I find in Sequence mode setting what give max  segment speed around  545ksegment/s
(measured with second scope and calculated also from history timestamps.

2. Case where CH1 and CH2 are both on and Sinc off and display dots etc.   timebase 10ns/div and Sequence mode.   Sequence repeating interval is more short what I have find before.

Add agen:

There is one open question.
Example. Sequence mode. If example in one sequence is 80000 segments. After these are acquired then acquisition of course stop and scope start do many things including display update for show waveform before it start new sequence. Question is, how many segments it display overlayed on the display before it start new sequence. It is least some hundreds in this case but how much really?  I do not believe it stack all segments. If I change amount of segments from 1 to hundreds it clearly give more and more intensity grading when I rise number of segments.

I found it intersting because with some settings and Sequence mode in use it can capture  over  300ksegment/s continuously (10s average). Checked using second scope for analyzing trig out signal and also using simple trig out signal pulse counting. For this I use HP53131 counter in pulse count mode with 10s gate time. Second oscilloscope triggercounter and HP give same result, over 300kwfm/s. In this case inside one sequence segment speed is 545ksegment/s.  This amazing speed is reached using CH1 + CH2 on, 10ns/div (segment lenght is 140pts and sampling rate 1GSa/s) , 50MHz signal in and Sinc off, display dots.  Of course display update speed is not high but intersting is how many segments are stacked for display in every turn.

[Performa01]

@rf-loop

Regarding the number of segments used for a single display update I’ve tried a little experiment.

Display dots, peak detect, 70Mpts, fast acquisition, x interpolation.
Sequence mode, 5ns/div == 140 points.

Used my darling channel 4 again (even though it's slow), sorry

I fed the scope with a 50MHz sinewave, 100% amplitude modulated with a 10kHz sawtooth and tried to count the individual traces on the screen, but it were still too many  (Sequence_RT_50MHz_Mod_10kHz)




In a 2nd attempt I increased modulation frequency to 40kHz (Sequence_RT_50MHz_Mod_40kHz)




We can clearly see 7 individual traces, with nice and evenly spaced amplitudes due to the ramp modulation.

Without sequence mode, we get a little more under otherwise same conditions (Standard_50MHz_Mod_40kHz)




The full range of amplitudes is run through 40000 times per second and we can see 7 traces. And despite dots display, all 7 traces don’t show any gaps.
At 10kHz modulation frequency we can assume it would be four times as much traces, hence 28 – and we still don’t see any noticeable gaps.

So this won’t get us very far. But what if we just reduce the modulation frequency to the point were we don’t get a nicely filled sinewave anymore, but observe some discontinuity instead?

Down to 300Hz everything looked just fine. At 200Hz the picture suddenly changed (Sequence_RT_50MHz_Mod_200Hz)




First we need to remember that we need about 300ms to fill the memory with 80000 segments (for Ch. 4 that is). So even a low modulation frequency of just 300Hz yields about 100 full modulation periods in memory. And this is about the lowest frequency that gives a correct modulation display without vertical gaps.
In normal mode, we don’t get any gaps even with just 100Hz of modulation frequency.

So while this doesn’t answer your question as how many waveforms make it to the screen, it is certainly a proof that not all waveforms are displayed, hence sequence mode cannot serve as a secret trick to have a very high waveform update rate that would not miss anything despite the slow screen update of just about 3 per second…

[Mark_O]

...with some settings and Sequence mode in use it can capture  over  300ksegment/s continuously (10s average).

...In this case inside one sequence segment speed is 545ksegment/s.  This amazing speed is reached using CH1 + CH2 on, 10ns/div (segment lenght is 140pts and sampling rate 1GSa/s) , 50MHz signal in and Sinc off, display dots.

So let me check that I'm following correctly.  At 545k segs/s, that means 1.83 us/segment.  Since each triggered acquisition runs for 140 ns, it doesn't trip again for 1.69 us afterwards.  That's the inter-segment dead-time, where the trigger hasn't been rearmed yet.  Even though your 50 MHz signal is providing another trigger event every 20 ns.

Then at the end of the segment burst, there is a second time gap, where it sets up to grab the next burst (clear and reset).  With 330k segs/sec, that means the  average time between segments has increased to 3.03 us, from the 1.83 us, or a 1.2 us delta/seg.  Since each burst here is 80k segments, that means the inter-burst gap is 9.6 ms.


Of course, as Performa01 said, we don't use Sequence Mode to look at rapidly repeating, continuous signals like this in real life.  However, tests such as these are useful in determining the capabilities of the test instrument.  The most interesting from my perspective being the dead-time that occurs between segments, while the unit re-arms to catch the next trigger.  Which has been demonstrated here to be ~1.7 us.  Which isn't bad performance at all. 

If the events you're trying to capture are always spaced further apart than that, even if they only occur maybe once per millisecond, or even once per second, then ALL of them will be captured if no two are closer together than 1.7 us.  That's good to know.  Plus a big win for Sequence Mode.  And conversely, if not, then they all won't, and some will be missed.

[rf-loop]

Perhaps this explain better what is going on.

(it need of course also note that dead time inside sequence burst phase between segments is much higher what is example with 50ns/div where segment lenght is 700ns or 1400ns depending samplerate. If look maximum 500ksegm/s speed previously measured using CH1 and 50ns/div. There is (quite exactly) 2000ns interval in burst phase. There segment time is 700ns and between segments dead time 1300ns.)

But here this case where long time average go over 300ksegment/s speed and speed during Sequence mode segment acquisition burst over 540ksegment/s. (here 80000 segments, CH1+CH2 open, 10ns/div)

Images tell more.



Snap shot during Sequence acquisition, running continuously over and over (not one shot at this time).
Just at snap shot random time there was going segment number 48659 and display waveform is from previous Sequence. (Settings: Sinc OFF, Display Dots, Trig normal, rising edge, Holdoff closed)






Here second scope (SDS1202X) CH1 is connected to scope under test (SDS2304) Trigger Out signal.
There can see Sequence segment acquisition burst and then scope busy time when it processes all nessessary things before it start next period (visible in top window right side).  SDS1202X trigger event based counter show around 310kHz frequency. (I do not know how this counter exactly work but freq display is jumping around between 300 and 325kHz  but mostly near 310kHz.   Because this, I also check it using HP 53131 for counting pulses over 10s gate time (not as frequency calculating mode but just as simple pulse counter, what is better mode for this case. Result certify this result in image if we tell average speed is ~310ksegment/s.

Whole period time here is 258ms.   80000 segments acquisition burst time is  141.5ms and oscilloscope busy time is 111.5ms.  This busy time is valid only for this instance.







And here scope stopped for looking captured seqments. Segment number 1. Also to image cloned segment number 80000 timestamp.




Still even with long busy time between Sequence periods it give over 300ksegment/s average speed  and here inside segment acquisition phase (80000 segment burst) speed is ~545ksegment/s.

I believe here is reached some of this SDS2000 series some upper possible limit values.
(with current FW)

Segmented Memory Acquisition for
InfiniiVision Series Oscilloscopes

Number of segments
1 to 2000 (5000, 6000, and 7000 Series)
1 to 1000 (3000 and 4000 X-Series)
1 to 250 (2000 X-Series)

Re-arm time
(minimum time between trigger events)
5000, 6000, 7000: 6 ?s
3000 and 4000 X-Series: 1 ?s
2000 X-Series: 20 ?s

Data sheet: Agilent 5989-7833EN

[Performa01]

This whole case need bit more inspections because in FW there is something wrong and/or not optimal.
Example why heck Sinc is mixed there in sequence mode for timebases 1ns/div to 20ns/div. Segmented memory cquistion do not need anything but push as fast as possible raw ADC data to memory and nothing - nothing else.

Well, I might have an explanation for that. While vectors and dots really is just a matter of screen representation, sin(x)/x is an actual signal processing step required to recover the original signal. This in turn is required by the digital trigger system in order to determine the exact trigger point on the time axis.

If this option is set to just ‘x’, the scope will just use a linear interpolation and introduce some noticeable jitter by that. I’ve demonstrated some of the odd effects on a fast sinewave in absence of sin(x)/x reconstraction in an earlier post, where we could consider the width of the trace area for any given (trigger) level would be the amount of jitter (Trace_Peak_x_Fast_Vectors)

There is one open question.
Example. Sequence mode. If example in one sequence is 80000 segments. After these are acquired then acquisition of course stop and scope start do many things including display update for show waveform before it start new sequence. Question is, how many segments it display overlayed on the display before it start new sequence. It is least some hundreds in this case but how much really?

I might have finally found a way to estimate this. After several experiments I believe that the scope just displays any (the first  - or last – or whatever?) 750 +/-50 waveforms for every filled buffer.

I got these results rather consistently for 80000 segments at timebases from 1 to 10ns/div (used Ch. 4 again, but that probably doesn’t matter in this case). Not tested anything else yet.

[rf-loop]

If this option is set to just ‘x’, the scope will just use a linear interpolation and introduce some noticeable jitter by that.

Yes I know but...
In Sequence mode  trigger position interpolation between samples is possible to do later when user is looking acquired segments and it can do linear or with Sinc curve as user make his settings. Of course if we look Sequence mode continuously running over and over Sequences it is image "cosmetics".

(when we look at the entire oscilloscope all the functions, perhaps  should be noted that this is only one fairly small nuance if some thing may give some % more abs max speed)
When look History (Sequence history) it do trigger position interpolation. It do not need do in runtime. (I have not yet checked it with SDS2000 but least SDS1000X can do it and if SS2k can not it need repair. Btw, SDS1000X do not change Sequence segments acquisition burst speed if turn Sinc on or off.)

My findings about displayed (and overlayed) segments  between sequences is weird.  But your around 750 is inside 500 - 1000 what I have tested but weirs it is because some things there looks nearly like random least because can not quess all variables.  I have tried with 2 channel method where other channel just trig segments forward and other channel is slow sawtooth ramp.
Other method was ARB squarewave (2000 50% square cycles and some cycles have signature what I can regognize on the scope screen after acquired 2000 segments and displayed somehow randomly... it was frustrating test due to lack of handy tools for edit this kind of ARB (yes, 524krow csv with notepad for maake some signatures to some pulses ). In continuous Segment mode these "signatures" some times blink on the screen but never when I run single shot from ARB gen. I do not (least yet) know how SDS2000 select segments for overlay on the screen  after sequence ready. (Is there even any significance. In particular, because this can not be used to better glitch hunting than the normal mode of operation.)

[Performa01]

Yes I know but...
In Sequence mode  trigger position interpolation between samples is possible to do later when user is looking acquired segments and it can do linear or with Sinc curve as user make his settings.

You are certainly right for lower frequencies, up to about 100MHz at 1GSa/s.

If you look at my picture (Trace_Peak_x_Fast_Vectors) again, then at 300MHz @ 1GSa/s there is also a fair amount of uncertainty regarding the pk-pk amplitude. While triggering would still work as you described at a trigger level of 0V, we certainly would miss trigger events if the trigger level is set to >60% of the peak amplitude.

The same situation as for the picture in my last post, but this time with trigger level set to 66% of the signal peak amplitude (Trig_Peak_x_Fast_66%)



Doesn’t look like a stable and reliable triggering anymore, does it?

For a periodic signal, this wouldn’t be a big deal, as every missed trigger condition just means 33ns wasted time. So even if we frequently miss 10 in a row (which is rather unlikely), it would only decrease waveform update rate by some 10%.

But what about sporadic events, like the glitches you mentioned and that are the reason why a high segmented memory trigger rate is so important according to HPeysightilent?

If we have the odd narrow pulse that has been acquired by less than 4 samples, its amplitude will most likely be too low without sin(x)/x reconstruction – except when we are lucky and a sample just hits the peak, but there is only so much chance that would happen.

The essence of what I’m saying is, that a trigger condition that we’ve missed because of the lack of proper signal reconstruction, cannot be ‘repaired’ or ‘fine-adjusted’ afterwards, simply because recording has never even stopped (and post processing started) due to a trigger condition.

But then again, up to some 100MHz we’re good without sin(x)/x.

Below there is a borderline case with a 4ns wide pulse, which corresponds to a fundamental frequency of 125MHz. Without reconstruction it looks like this (Pulse_4ns_Peak_x_Fast)



There is a fair bit of uncertainty visible, but the scope still wouldn’t miss any trigger events as long as the trigger level is kept below some 93% of the peak amplitude.

With reconstruction filter active, everything is fine. Also the automatic measurements for the transition times get instantly more accurate (Pulse_4ns_Peak_sinx_Fast)

My findings about displayed (and overlayed) segments  between sequences is weird.  But your around 750 is inside 500 - 1000 what I have tested but weirs it is because some things there looks nearly like random least because can not quess all variables.  I have tried with 2 channel method where other channel just trig segments forward and other channel is slow sawtooth ramp.

My test results are in fact even more consistent than what I wrote, according to the following table:

1ns/div      732
2ns/div      784
5ns/div      771
10ns/div     796

My test was simple: I used the setup as described in an earlier post and tweaked the modulation frequency until I just got one full modulation period, i.e. no gaps on the screen.
Since the peak amplitude of my signal was less than 3 divisions, the ADC would resolve this in only less than 70 different levels, which gives an uncertainty of nearly 1.5% already. Then add the difficulty to recognize just one single missing value, i.e. 1/25 of a division, all the more so since there is also a bit of noise, obscuring tiny gaps, the total uncertainty is considerably higher, but obviously still better than 5%, according to my results, that could also be expressed as 763 +/- 4.33%.

I didn’t look any further into this though, as it already has become clear that it wouldn’t be the secret weapon for glitch hunting. Without this prospect, it just doesn’t matter, how the signal actually is displayed in sequence mode.

If, on the other hand, we would have actually found that we could get a complete signal representation on the screen at a higher waveform capture rate than in normal mode, then this would just have been a hint for a bug, because then sequence mode would have done exactly the same work as normal mode, just in bigger blocks, so to speak. So it really shouldn’t be faster in this case.

[rf-loop]

Do you believe primary trigger is generated after interpolation?
I do not.

But there is also signs about bug or even design error in trigger "box".  (At this time this is just only suspect, not at all enough tested and this is so "deep inside engine" thing and because it can only test indirectly it is better to do with other peoples with some other test idea...for avoid faulty reasoning - fallacy. )

It looks like (and this is NOT confimed, only light suspect until more real evidence) trigger is not generated from interleaved 2GSa/s data. More it looks like trigger look only one ADC data and so 1GSa/s. (or there is some other things wrong)

This is old case but I have forget it totally. Long time ago I wonder why trigger counter drops out so easy where trigger level is not even near signal top. Image on TFT looks like all is ok and stabile trigger
(of course it looks ok because scope is enough fast for eyes and there is enough well trigged waveforms and because  captured waveform position adjustment works good),
 but counter start drop out specially if look with 2GSa/s and use lines and then Sinc on or off signal is far over trigger level. 
But, surprice. With same signal turn to 1GSa/s (take other channel on) and look now signal with lines  and Sinc on or off. Surprice is that there is easy to see what is level where trigger counter start dropping out. Because worst case one signal cycle samples are just around trigger level. 
If it use 2GSa/s stream,  worst case data points are still far over trigger level. So why counter start dropping.  At this time I think it is "only" this counter...   so not so much for it and I forget it from more testing. 
 
I think counter do not have other source but just this primary trigger signal. I do not believe there is arranged to some other things just for this counter so perhaps this can use here.

It is more easy to test with over 300MHz sinewave. Around 375MHz is some kind of "sweet pot" for visual inspection so that this can see extremely clearly. (if then use measurements so that adjust input signal level so that with  2GSa/s scope show same p-p level what it show using 1GSa/s . In all cases of course 1ns/div. 
There can find, using 2GSa/s, trigger level where trigger counter just barely do not drop anything.
Then turn to 1GSa/s and adjust input signal level for same averake p-p value. You find this point in trigger level is exactly same.
Turn Sinc off. Look where is trigger level related to 1GSa/s worst case samples. Also this can nice inspect more if stop now scope and search wfm history slowly. 
Why it is same for 1 and 2GSa/s.  Perhaps due to design error, bug in FW or this is only way for this speed?
Why it is same for Sinc on or off is perhaps clear. There is not any Sinc interpolation before it generate primary trig from data stream.

[Performa01]

Do you believe primary trigger is generated after interpolation?

Yes, I did believe that, simply because I could not think of any other way to get reliable triggering at high frequencies – and as we all know, I think the trigger system of the SDS2000 is hard to fault and certainly one of its strongest points, but…

… after reading your reply and performing some  more experiments, I stand corrected. Well, that’s the beauty of having discussions with other engineers, as this prevents us from flogging a dead horse…

 I can see why you call 375MHz a ‘sweet spot’

There are numerous others, 388MHz for instance. Still I thought I’d stick with just 300MHz as I didn’t want to go far outside the bandwidth specification for this scope.

I’ll show my experiments first and discuss it in more detail afterwards.
Common settings are dot display, no sin(x)/x reconstruction and fast acquisition.

First there is my test signal: a 300MHz (<50ppb), 500mVrms sinewave. At a trigger level near the centre, the trigger frequency counter of the SDS2000 shows the correct value at its usual poor accuracy and low resolution, i.e. an error of -20ppm. So the trigger frequency display of 299.994MHz shall be the reference for the following tests. Note that the sinewave looks reasonably undistorted in this screenshot, despite no sin(x)/x interpolation has been used (Trig_12mV_2GSa_300MHz_dots_fast_x)



At a sample rate of 2GSa/s and a trigger level of 348mV, the distortion becomes much more evident. The frequency display still shows the reference value, but would start to drop if we set the trigger level any higher (Trig_348mV_2GSa_300MHz_dots_fast_x)



By reducing the sample rate to 1GSa/s, the picture changes dramatically – doesn’t look like a sine at all, does it? What strikes me is the peaks at the trigger point and on top of the first and last negative halfwave – these look somewhat artificial. The trigger counter has now dropped from the reference value, and even though it might be less than expected, it still shows that there is a difference if the sample rate is cut in half (Trig_348mV_1GSa_300MHz_dots_fast_x)



Now the same experiment at an even higher trigger level of 500mV. At 2GSa/s, the distortion is even worse now and peaks on top of the wave become visible even at that sample rate now. The trigger frequency counter has dropped dramatically to just 196.923MHz by now, indicating that more than 33% of the trigger events get lost (Trig_500mV_2GSa_300MHz_dots_fast_x)



If we reduce the sample rate to 1GSa/s again, the pivture does not even show a waveform anymore. Instead, we get some funny curved lines plus even something that looks like a flat oval at the trigger point. Trigger frequency has dropped even further to 178.324MHz, once again the difference is less than expected, but there is a difference after all (Trig_500mV_1GSa_300MHz_dots_fast_x)




Now what does that tell us?

First I want to quote the datasheet, which says that glitch detection works down to 1ns. That indicates that there is always some monitoring going on, which has to be independent from the main acquisition sample rate. Remember how I demonstrated peak detect working even in roll mode at very low sample rates <1MSa/s, where the scope still didn’t miss a single 4ns wide pulse. This would not be possible at sample rates <250MSa/s, if the main acquisition system was the only mechanism in effect.

So my current guess is that the ADC always runs at full speed and the current sample rate displayed on top of the info bar only determines the amount of data to be stored in sample memory. At this point, the decimation mechanism (normal or peak detect) has to sit – and also the primary trigger system.

For me this would be a satisfactory estimation on how this scope works, if it weren’t for the surprisingly small difference between 1 and 2GSa/s.

[nctnico]

Do you believe primary trigger is generated after interpolation?

Yes, I did believe that, simply because I could not think of any other way to get reliable triggering at high frequencies – and as we all know, I think the trigger system of the SDS2000 is hard to fault and certainly one of its strongest points, but…

The trigger system in any DSO works by detecting whether a threshold has been crossed. The values of the samples where the threshold crossing occured are stored and used to calculate (interpolate) the exact trigger point and required shift to adjust the time reference of the samples so subsequent acquisitions overlap eachother perfectly and the signal is properly aligned with the trigger point.

[tautech]

First there is my test signal: a 500MHz ................

Typo?

[Performa01]

The trigger system in any DSO works by detecting whether a threshold has been crossed. The values of the samples where the threshold crossing occured are stored and used to calculate (interpolate) the exact trigger point and required shift to adjust the time reference of the samples so subsequent acquisitions overlap eachother perfectly and the signal is properly aligned with the trigger point.

What you describe is the traditional analog trigger architecture.

We are talking about the SDS2000, which incorporates a fully digital trigger system.

[Performa01]

First there is my test signal: a 500MHz ................

Typo?

Yesss

Can you imagine what the 1GSa/s recording would have looked like at 500MHz?

[tautech]

First there is my test signal: a 500MHz ................

Typo?

Yesss

Can you imagine what the 1GSa/s recording would have looked like at 500MHz?

Will you examine the Power Analysis option?