Products > Test Equipment
Siglent SDS2000 new V2 Firmware
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:
--- Quote from: Performa01 on January 04, 2016, 07:37:09 pm ---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.
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
OK. You are correct, that I did need to look closer. Thanks.
--- Quote ---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…
--- End quote ---
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version