Siglent SDS2000 new V2 Firmware

[nctnico]

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.

Calculate doesn't happen in the analog domain! But please explain how a digital trigger system should work...

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

Calculate doesn't happen in the analog domain! But please explain how a digital trigger system should work...

Here is an excellent application note on this topic:

https://cdn.rohde-schwarz.com/pws/dl_downloads/dl_application/00aps_undefined/Benefits_of_RTO_digital_trigger_system_2.pdf

Pico technology have introduced the digital trigger in 1991, using the same arguments as R&S (much later obviously).

[Performa01]

To solve the puzzle: what does a 500MHz signal look like, when acquired with 1GSa/s ?

Fist let’s have a look at the signal sampled at 2GSa/s, sin(x)/x reconstruction and vector display (500MHz_2GSa_vectors_fast_sinx)



Well, the waveform looks pretty unexciting, basically the same as 250MHz would look like at 1GSa/s. But we see that despite the low trigger level of 8mV, the trigger frequency display is not even close to the true value, whereas the automatic period measurement is spot on. The automatic measurements also indicate rise and fall times of 600ps, which is almost exactly the expected value and it is quite surprising to see this so accurately measured on a scope with a specified rise time of <1.2ns.

What if we lower the sample rate to 1GSa/s?
In this case, the signal frequency would be equal to the Nyquist frequency of the sampling system. Look what we get (500MHz_1GSa_vectors_fast_sinx)



It’s a nice amplitude modulated waveform, with a 500MHz carrier and a modulation frequency that is the difference between signal frequency and half the sample rate. This is unknown of course, but most probably less than 10kHz. The trigger frequency display is the same amount off as before, and even the automatic measurements for the transition times haven’t changed significantly.

If we use dots display, now having no interpolation whatsoever, we can see the true sampled data. It’s just 14 dots per trigger event, at random amplitude. At the exact nyquist frequency we would get steady amplitude, which in turn depends on the phase relationship between signal and sample clock (500MHz_1GSa_dots_fast_sinx)



Consequently, with vector display again, but this time sin(x)/x reconstruction turned off, we get another nice picture (500MHz_1GSa_vectors_fast_x)



Note that trigger frequency is off as always, but automatic measurements for period and transition times are spot on.

[Performa01]

Will you examine the Power Analysis option?

Probably not. I have purchased my scope with all available options from Batronix, who is my nearest distributor here in the EU, but Power Analysis hasn’t been available back then and still isn’t today.

Of course, I actually don’t really need that option, but still would have included it with my purchase, if it had been available at a reasonable price. Not sure if I would purchase it separately if it ever becomes available…

[tautech]

Will you examine the Power Analysis option?

Probably not. I have purchased my scope with all available options from Batronix, who is my nearest distributor here in the EU, but Power Analysis hasn’t been available back then and still isn’t today.

Of course, I actually don’t really need that option, but still would have included it with my purchase, if it had been available at a reasonable price. Not sure if I would purchase it separately if it ever becomes available…

Power Analysis is already installed in all new SDS2000 series units and is freely available for 30 trial uses.
It's in the Utilities menu on P2 and unless you've enabled it more than 30 times you should have some Trial cycles of the Power Analysis option remaining. 

On P3 of Utilities/Options/ Information will display remaining free trial cycles. 

[Performa01]

@ tautech

Yes, I have 28 trial cycles left, that’s a joke, because just accessing the menu counts as activation already. So guess how far I will get, if I actually start a review on this?

I will frequently have to access all the other menus, particularly  trigger, display, acquisition, measurements and cursors. Then when I go back to power analysis, another trial cycle is due.

I have done absolutely nothing with power analysis yet, but still already used up 2 trial cycles. No, that doesn’t much sense nor is it great fun to work under these conditions…

[tautech]

@ tautech

Yes, I have 28 trial cycles left, that’s a joke, because just accessing the menu counts as activation already. So guess how far I will get, if I actually start a review on this?

I will frequently have to access all the other menus, particularly  trigger, display, acquisition, measurements and cursors. Then when I go back to power analysis, another trial cycle is due.

I have done absolutely nothing with power analysis yet, but still already used up 2 trial cycles. No, that doesn’t much sense nor is it great fun to work under these conditions…

I quite agree.

I've already dropped hints  at the manufacturers for your great work, so if you'd be willing to go the distance we'll see what can be done. 

[Performa01]

 
@rf-loop

Since I had to find a document that saved me the effort to explain how a digital trigger system works, please have a look at figure 6 on page 7 of the R&S application note I have linked in on my reply #176. There is a little ‘upsampling’ unit in the trigger path.

If you look at the explanations together with figure 7, it should be rather obvious, what this ‘upsampler’ actually does. It performs a sin(x)/x interpolation, otherwise the overshoot in their example waveform would have been missed by the trigger system.

So my fault was to think this might be also switched on/off by the sin(x)/x option in the acquisition menu, but of course it has to be in effect permanently and doesn’t affect displayed data at all, as it is in the trigger path.

Anyway, if you look at the whole document, many features and benefits do sound very familiar – even though a whole different class, there are many similarities with the SDS2000…

[rf-loop]

It looks (least for me) like primary trigger (or least counter trigger)  is generated from  one ADC 1GSa/s data  also  when there is 2GSa/s in use.  ADC is something like this   Because can not know exactly in what mode they run this chip it is bit difficult to make some special test what can suspect. Perhaps system is designed for 1GSa trig and not even tried generate trig from 2GSa/s data stream. If it is designed for 2GSa/s trig then there is perhaps some bug how they pick up data from ADC for produce primary trig flag.


In all images signal to CH4 is 375MHz good quality sinewave from HP8644B (Agilent)
Trigger normal, edge, rising, DC









2GSa/s, vectors, Sinc OFF. Trigger level as high as possible for correct and stabile freq counter.
Here 57mV





Changed only trigger level bit higher to 58mV and noted that freq counter start drop out.






Changed trig level back to 57mV and changed Sinc ON.  Frequency counter stabile and right.







Changed trigger level bit up, to 58mV and noted  that freqquency counter start drop.

After this point I want drop samplerate to 1GSa/s and do not change anything but turn CH3 on.
Note also that I have adjusted small amount signal level between 2GSa/s and 1GSa/s and between SincON and OFF so that scope give same result using p-p measurement (average)
This do not change anything but with this method trigger levels where counter drops or not stay same.


Input frequency of course same 375. It is now 0.75*(sampling frequency/2)!




1GSa/s, Sinc OFF, vectors. Trigger level 57mV and freq counter stay stabile and correct.





1GSa/s, Sinc OFF, vectors. Adjusted trigger level 1mV up to 58mV so that counter just start drop.


 



1GSa/s, Sinc ON, vectors. Adjusted trigger level to highest level what give stabile counter.  It happend at 57mV






1GSa/s, Sinc OFF, vectors. Adjusted trigger level higher until counter just start dropping. Noted that level is (agen) 58mV


Big question is:  why  it happend in same level independent of Sampling speed? 
It must not happend if trigger is really generated from 2GSa/s (2x1GSa/s interleaved  and when  interleaved ADC's are 180 degree phase shifted.) data because naturally there worst case lowest level samples are higher.


Then I want look History for these things because there can see waveform adjust to trigger position. But also because normal History function is same what we also use for looking Sequence mode captured segments. (frames)






This is just scope running for fill history memory.
1GSa/s, Sinc OFF, vectors (lines) And here also trigger level adjusted just bit over point where we get stabile correct counter.
So it is set for 58mV and we can see counter drop some amount from 375MHz (375.008 ~ 375.009 is right)





Just stopped and just for one example, looked frame number 4 (waveform, segment or what ever name we give)
There can see one case where it may not trig. If wave what top is around LIST OFF menu selection it do not trig, quite rare but occurs. If look nearly left side same kind of.. it still may trig.  (do not look line because scope do not look it, it look sample point ans only it!)





Then go forward and look bit more "frame" number 308.  There is interesting situation. With veector (line) it adjust horizontal position right and between sample points just where linear interpolation go over trigger level.





Frame number 308. Now Sinc ON. Note shit to right so that Sinc interpolated curve is positioned to trigger position.





Still frame 308. Now display dots but Sinc still ON. Note dot position near trigger position.





Still frame 308. Now Sinc OFF and dots. (now dots position iss same as with vectors (dots) display mode.





Still frame 308. Now back to Sinc ON and dots. Shifted back to as images p and also n.
Siglent keep original sample points and it do not produce its own fake processed sample points
independent of what is interpolation and/or display mode.

One feature what I hope is that there is selection for highlight real sample points (specially for Sinc ON but also for vectors (lines) mode.






Still stay in same captured History. Now Frame number 320.
Sinc OFF, vectors





Still frame 320. Sinc OFF, display dots.





Frame 320, now Sinc ON. Display dots. If look carefully there can see tiny shift to right (is it one pixel (20ps)?). Because in this  linear and Sinc interpolation is very near each others in trigger position.





Frame 320. Sinc ON. Display vectors.




It looks like primary trigger (or least counter trigger)  is generated from  1GSa/s stream also when there is 2GSa/s  interleaved mode in use. I can only suspect this, and with this method can not prove it with certainty.  But indirect one evidence is how frequency counter start drop out because it do not get pulses. If these pulses are generated from 2GSa/s stream there is samples over trigger level in every single signal cycle. But, with 2GSa and 1GSa it start drop out some cycles just exatly with same trigger level when signal level is around same. With 375MHz there need be big difference if look worst case for one cycle with 1GSa and with 2Gsa. Difference is big.  Also I do not  believe they have generated separate trig pulses for counter and for primary signal trig. And, because this believe, I think counter trigger is one acceptable evidence.


(I think most know there is one ADC for two channels group. This ADC have internally 2 ADC. They can work separately giving out separate data streams (both give out 2 8bit stream) or they can operate in 1 channel mode where these ADC's are interleaved by clock (180 degree phase shift what means just inverted clock). Still they both give out 2 x 8bit data bus and whole 2GSa/s is now 4x8 bit data bus. More is explained in ADC data sheet)




Ed: attached image what show fine adjust between images t and u
There can see it use 20ps fine adjust step for image. (20ps is also TFT resolution limit when 1ns/div. One div is 50pixel)

[rf-loop]

@rf-loop

Since I had to find a document that saved me the effort to explain how a digital trigger system works, please have a look at figure 6 on page 7 of the R&S application note I have linked in on my reply #176. There is a little ‘upsampling’ unit in the trigger path.

If you look at the explanations together with figure 7, it should be rather obvious, what this ‘upsampler’ actually does. It performs a sin(x)/x interpolation, otherwise the overshoot in their example waveform would have been missed by the trigger system.

So my fault was to think this might be also switched on/off by the sin(x)/x option in the acquisition menu, but of course it has to be in effect permanently and doesn’t affect displayed data at all, as it is in the trigger path.

Anyway, if you look at the whole document, many features and benefits do sound very familiar – even though a whole different class, there are many similarities with the SDS2000…

If we take this  nice well known  R&S application note.  Look there image 7.
It looks like SDS2k works more like this image left side.
Primary trigger is perhaps not generated at all using over sampling and sinc interpolation there before it look if there is detected signal level => trigger level  ref my images where trig start drop. (still I assume counter use generated trigger and there is not separate trig for counter and waveform capture. It this assuming is wrong, then I need push this my exercise to garbage or keep it just for fun)

Here (with 2GSa/s) it do not need even oversampling. Fisrt it need use all available true sample points and not half and even with this improvement is - huge.

[Performa01]

@rf-loop

Well, with combined efforts we have finally solved this puzzle.

Given all our test results and having a look at the ADC08D1020 data sheet (up to now, I didn’t know what ADC is working in the scope), it all comes together very nicely.

So I try to summarize the way this scope architecture works and will simplify things by ignoring the DEMUX option with its associated DXd output ports, as the actual configuration doesn’t affect the general working principle. I will also ignore the additional memory dedicated for the digital channels, that with V2 FW can somehow be attached to the analog channels to provide a total of 35Mpts per channel.

So I just say the ADC08D1020 has two ADCs, where each of them has an associated digital output port, which in turn is connected to a block of 14MB acquisition memory.
Both ADCs can work in parallel for any of the two analog input channels, and the interleaved data will be output by both ports at the same time, thus making the output data bus twice as wide. So we get twice the data but also twice the memory in interleaved configuration. For screen representation, we have to combine the contents of the two memory blocks, like all even sample numbers will be found in one block and the odd ones in the other.

The trigger system in contrast doesn’t care for that and is attached to the output port of the trigger channel. If this happens to be Ch. 1, the trigger system is connected to the output port of ADC1. If Ch. 2 is turned off, then its output port is providing data for Ch. 1 also, but that is not seen by the trigger system, as its data bus width remains constant. This is the same on the R&S RTO, which also uses ‘only’ 10GSa/s for the trigger system, whereas a single channel can have 20GSa/s in interleaved mode. So it is the exact same situation, except for the RTO sample rates to be 10 times higher…

And yes, Siglent couldn’t be bothered to implement an upsampling circuit in the trigger system, so the left part of fig. 7 in the before mentioned R&S application note applies. That sounds a bit disappointing at first, but isn’t all that bad after all. The RTO scope claims glitch detection <50ps, which would be equivalent to 500ps on the Siglent. But Siglent only specifies 1ns, which is perfectly fine for a scope in this class.

Which leads us back to the point where we started this discussion…

Since we could demonstrate that sin(x)/x reconstruction is not a signal processing in the main acquisition path, nor is it in the trigger path, it is indeed more like a display option and should belong in the ‘Display’ menu.

For Sequence Mode, sin(x)/x should not make any difference regarding waveform capture rate, and it should be possible to arbitrarily apply that after the capture, when we are viewing the history.

EDIT: ADC08D1020 appears to be a very nice chip by the way!

[rf-loop]

@rf-loop
.

Given all our test results and having a look at the ADC08D1020 data sheet (up to now, I didn’t know what ADC is working in the scope), it all comes together very nicely.

Oh. I forget add to my previous msg: "ADC is something like this"
(I'm not sure what it is exactly, it was only for thinking principle and how it give data out. I'm quite sure thät least it is "something like this")

[Performa01]

Oh. I forget add to my previous msg: "ADC is something like this"
(I'm not sure what it is exactly, it was only for thinking principle and how it give data out. This I'm sure thet least it is "something like this")

Oh - doesn't really matter, does it?

It is quite obvious that it has to be something like this, and this 'something' is a real nice piece of silicon!

[rf-loop]

Oh. I forget add to my previous msg: "ADC is something like this"
(I'm not sure what it is exactly, it was only for thinking principle and how it give data out. This I'm sure thet least it is "something like this")

Oh - doesn't really matter, does it?

It is quite obvious that it has to be something like this, and this 'something' is a real nice piece of silicon!

If think only this discussion no matter (here working principle matter)
But I can not confirm exactly if it is Ti ADC08D1020.

[Performa01]

Peak Detect:/Roll Mode revisited

Given the insights gained from our previous experiments, I wanted to look at this topic once again, particularly in order to see if the 1ns glitch detection works as specified.

First let’s try if we can reliably trigger on trigger conditions that are only valid for just one nanosecond. I’ve tried two different methods and used the trigger frequency display as a reference. As long as its displayed value does not drop, we aren’t losing any trigger events.

An easy way to check that was using a 300MHz sinewave again and adjusting the trigger level near the top of the waveform, where the positive halfwave is just 1ns wide (Trigger_1ns)



With these settings triggering is reliable and no events are missed (yes, trigger frequeny display is a bit off, but it has not dropped!). And just like all the previous tests already indicated, it doesn’t matter if we use sin(x)/x or just x as well as vectors or dots. The result is also the same regardless of the number of channels in use, it also works with a sample rate of just 1GSa/s.

Also tried this with a narrow pulse at a repetition rate of 1µs. Again, we don’t lose any trigger events as long as the pulse width at the trigger level is at least 1ns (PeakDetect_1ns_1MHz_1ns)



Now I change the repetition rate to 12ms, while leaving everything else just as before (PeakDetect_1ns_1ns)



At a timebase setting of 2ms/div we still maintain a sample rate of 2GSa/s and a total of three pulses are displayed on the screen. They are very faint, hence barely visible, but they are there (PeakDetect_1ns_2ms)



At 5ms/div, sample rate drops to 1GSa/s, but that’s no problem, as we can consitently see all five pulses (PeakDetect_1ns_5ms)



At 10ms/div and a sample rate of 500MSa/s, we still don’t lose any pulses, but the amplitudes aren’t stable anymore. The trigger system quite obviously still works on the full 1GSa/s raw data from the ADC as there is absolutely no hint for losing any pulses. But it becomes also obvious, that sample data is decimated to the current sample rate (500MSa/s in this case) before peak detect gets access to it. This explains the discrepancy between triggering and displayed data. If you look close, according to the display, the pulse at the trigger position doesn’t quite reach the trigger level, but the trigger still fires (PeakDetect_1ns_10ms)



At 20ms/div and a sample rate of 250MSa/s, we still don’t lose any pulses, but the amplitudes are pretty random (PeakDetect_1ns_20ms)




At 100ms/div, we automatically get roll mode, and there things change quite a bit. Current sample rate drops dramatically to just 2MSa/s, but at the same time peak detect mode quite obviously starts working based on the raw ADC data at 1GSa/s. So we not only don’t lose any pulses – except for the occasional drop out every now and then, as can be seen in the left of the screenshot – but amplitude levels are all near the maximum with only little variation (PeakDetect_1ns_100ms_roll)



Finally I want to push this to the limit and use 50s/div roll mode, which is the maximum we can get on the SDS2000. Sample rate now drops to the incredible low value of just 4kSa/s, but we still see a dense carpet of pulses that are only 1ns wide at the trigger level! (PeakDetect_1ns_50s_roll)



The question remains: does it really capture all the pulses without missing any? Short answer is yes, it does. When stopping the acquisition and lowering the timebase to 10ms, we can see all the pulses there, even at a fairly constant amplitude. Yes, I’ve shifted the waveform on the time axis a bit in order to find any missing pulse, but they were all there (PeakDetect_1ns_50s_H10ms)



I’ve also tried that in Y-t mode at 100ms/div and – surprise! – it behaves the same as roll mode, i.e. despite the sample rate now being 50MSa/s, we get all pulses at their full amplitude. So it quite obviously is possible to do the peak detect before data decimation, so that we can get the true peak data values based on the raw 1GSa/s ADC data, no matter what the current sample rate (that determines the time spacing of the samples in the buffer) is (PeakDetect_1ns_100ms)





Conclusion:

Peak detect works absolutely perfect in roll mode and generally for time bases >20ms/div.

Below that, it seems there would still be room for improvement. As it is now, the peak values are acquired from simply decimated data according to the current sample speed, instead of replacing the decimation by a peak detect mechanism.

As it is now, if we had a perfect 1ns wide pulse we would be able to trigger on it but still might not see anything on the screen.

Big question: Since it is possible to do it in an optimal way for timebases >20ms, why on earth has it to be different for faster timebases?

[Performa01]

Digital Trigger System, Peak Detect & Glitch Capture

After a little pondering and some more tests, I should provide some clarifications on the digital trigger system, glitch capture and peak detect acquisition mode, also with regard to the observations described in my recent postings.

First, I shall give an overview on how the SDS2000 works, see picture SDS_BD.



The input signal is conditioned by means of an attenuator and VGA /variable gain amplifier) to accommodate the dynamic range of the ADC.

The ADC is clocked at a constant 1GHz, hence provides a constant sample rate of 1GSa/s. To keep things simple, the block diagram doesn’t include interleave mode, where the ADC data of two channels are combined in order to yield twice the sample speed, because this has no impact on the basic operation and particularly the trigger system, which always works with 1GSa/s raw data from just one ADC – the one that is assigned to the trigger channel.

The ADC always has to run full speed, otherwise the fully digital trigger system as well as the 1ns glitch capture would not work. So I refer to the ADC output as the raw sample data here. These are fed into the trigger circuit and the first signal processing unit at the same time.

Proc. 1 refers to the first signal processing step, which serves (at least) two tasks:
1.   Compaction of the raw sample data according to the timebase setting, so they can fit into the available sample memory.
2.   Glitch capture, which is similar to peak detect, with the only difference that it works on the raw sample data instead of the already decimated data in sample memory.

Of course, compaction is only necessary on timebase settings, where the raw sample data for the full screen width don’t fit into the sample memory. For example, at the lowest memory setting of 7k no compaction is needed for timebases up to 500ns/div, because this results in a total recording time of 14 div. times 500ns = 7µs, which in turn yields 7k samples at 1GSa/s.

For slower timebase settings, the amount of data has to be reduced in order to fit into the memory. This could be done by simple decimation, i.e. writing only every Nth sample into memory. This way, a slower sample speed is simulated and I’ll refer to it as the effective sample rate as opposed to the raw sample rate, which is always 1GSa/s.

Since this scope provides glitch capture down to 1ns, a simple decimation would not cut it at all, hence a similar process as described below for the 2nd processing step in peak detect mode has to be applied in order to preserve narrow glitches and make sure they will make it to the sample memory.

Proc. 2 refers to the second signal processing step, which has to do one more data compaction in order to fit the display. As the display has 800 x 480 pixels, we can assume there are 700 horizontal pixels for the waveform. In normal acquisition mode, we can only sensibly display 700 pixels per waveform. Even if the sample memory is at its lowest setting of just 7k, this is still 10 times more than what the display can handle. In normal acquisition mode again, the 2nd signal processing step would just decimate the data by only passing every 10th sample to the display.

In peak detect mode, things are a little different. It should be obvious, that peak detect mode wouldn’t make any difference as long as all data in memory fit into the display memory. So at timebase settings of 50ns/div or faster, there are just 700 samples (or less) acquired for each trigger event (waveform), so no data compaction is required, no matter what the memory depth is set to.

If the sample memory contains more than 700 samples for a single waveform and data compaction becomes necessary, peak detect mode traditionally uses two data points, that is a minimum and maximum value, per horizontal pixel on the screen. So at a timebase of 100ns/div there are 1400 samples per waveform, and they all make it to the display in peak detect mode, as there is now a min/max data pair for each horizontal pixel position.

For even slower timebases, peak detect keeps providing the display with 700 data pairs, so it needs to do some data reduction too. But this time it isn’t just dropping superfluous data by a simple scheme without looking at them, but every cluster of samples that shall be displayed at just one horizontal pixel position is searched for the min/max values and the resulting data pair is sent to the display.

By now it should be clear, that peak detect and glitch capture together give an extremely powerful combination, which allows us to spot narrow pulses down to 1ns width even at very slow effective sample speeds, such as in roll mode, where it can be as low as just 10Sa/s at 50s/div with 7k memory.


So now let’s correlate the findings in my previous tests with the working principle described above:

Conclusion

1.   The trigger system works flawlessly on trigger events down to 1ns, no matter what the timebase and acquisition settings are, except for the minor flaw that it won’t trigger correctly on two narrow pulses spaced <30ns apart, as I’ve demonstrated in an earlier post.
2.   Peak detect mode works just as it should and I haven’t come across a single instance, where it had failed to do so.
3.   Glitch capture works beautifully on slower timebases, but doesn’t seem to work properly on faster ones. This needs some further investigation (coming soon).

EDIT: some typos...

[Performa01]

Glitch Capture

In all previous tests, triggering and peak detect worked absolutely fine, whereas glitch capture quite surprisingly only kicked in at timebases 50ms/div and slower, leaving two timebase settings (10 and 20ms/div) where the pulses had a pretty random amplitude, indicating that they were captured only with the effective sample rate of 500 and 250MSa/s respectively.

This behaviour gave me some headache, since it should be clear what would happen if we had a perfect 1ns wide pulse.

The scope risetime is specified at <1.2ns (it is actually more like 1ns), so the ADC in a SDS2304 would probably see something like this when a perfect 1ns wide pulse is applied to the scope input (Ideal_Pulse_1ns)



That means at a sample rate of 500MSa/s the minimum pulse hight on the screen would be just about 15% of the original amplitude. With 250MSa/s, it could easily happen that the pulse wouldn’t be visible on the screen at all, whereas the scope would still reliably trigger on it. That’s certainly not good – we always should be able to see the trigger event, i.e. the signal the scope has triggered on.

The test I am referring to has been carried out with the maximum memory length of 70Mpts. What if we select less memory, which would cause the sample rate to drop earlier? For example, with the minimum of 7k, sample rate would only be 25kSa/s at 20ms/div and glitch capture would not work for all timebases from 20ms/div down to 1µs/div! This prospect gave me some serious headache, so I had to investigate.

I set up another test with narrow pulses, but this time wanted to demonstrate glitch capture working independent of the trigger. So I let the scope trigger on a sync signal applied to Ch. 3, whereas the narrow pulses are fed into Ch. 4 with some 30ns lag with respect to the trigger edge. Peak amplitude is about 4.5V and pulse width is <4ns (Glitch_Test_Setup)



I’ve tested all possible memory sizes and will show a few examples only.

First 7k memory depth and 500ns/div, which still maintains 1GSa/s (Glitch_7k_1GSa)



Everything’s fine here, as the sample rate has not yet dropped. A little amplitude jitter is inevitable, given the fact that 1GSa/s isn’t fast enough to consistently capture the pulse peak. I’ve turned automatic measurements on, in order to document my observations and according to these, the pk-pk amplitude varied by just 240mV, equivalent to some 5%.

At 1µs/div and with 7k memory, sample rate drops to 500MSa/s and since the pulse is significantly wider than 1ns, the variation still doesn’t appear too bad, it is now 680mV or 15%. In any case, glitch capture has not kicked in (Glitch_7k_500MSa)



At 2µs/div and with 7k memory, sample rate drops to 250MSa/s and the amplitude variation gets really significant now – it is 2.48V or 54%. No glitch capture to be seen … (Glitch_7k_250MSa)



At 5µs/div and with 7k memory, sample rate is now down to 100MSa/s, but glitch capture has finally become active. The amplitude variation gets significantly better again with 1.12V or 24% (Glitch_7k_100MSa)



And it gets even better at slower timebase settings. As an extreme example, at 20ms/div and with 7k memory, sample rate is only 25kSa/s, but glitch capture is quite effective here. The amplitude variation is a negligible 120mV or 2.6% (Glitch_7k_25kSa)



As already stated, the behaviour is basically the same, no matter what the currently effective memory depth is. But there is one exception with the maximum setting of 35Mpts, because it allows a timebase setting, where the sample rate drops to just 125MSa/s (Glitch_35M_125MSa)



As can be seen from the screenshot, amplitude variation gets particularly bad here and we do indeed see some missing pulses (we can see that we can see nothing  ). So far this is no big surprise, as it seems obvious by now, that glitch capture only kicks in for sample rates of 100MSa/s and slower, and sampling a pulse that is less than 4ns wide at only 125MSa/s cannot yield any useful results of course.

Apart from that, the additional memory once again seems to cause some additional trouble as well (as I’ve already demonstrated when reviewing the FFT), as now the automatic measurements don’t show the true picture at all. According to these, the minimum amplitude would still be 3.76V, which is clearly not true as the signal trace indicates.


Conclusion

Glitch detect only kicks in at sample rates of 100MSa/s or slower, leaving a gap for the timebases where the sample rate is more than 100MSa/s, but still less than 1GSa/s. In this area it actually could happen that we might not see the trigger event on the screen. This is clearly a flaw, but is easily circumvented by avoiding this ‘grey’ range of sample rates when really narrow glitches can be expected to occur. Maybe Siglent could narrow or even close this gap?

Maximum memory enables us to get a sample rate that is just slightly faster than 100MSa/s (where glitch capture would kick in), with particularly bad results, but also causes the automatic measurement to apparently miss all peak amplitudes lower than 3.76V in my test setup, that is clearly a bug.

I can withdraw another complaint in exchange, namely the very striking double lines (I called it ‘ghosting’ back then), specifically in roll mode. This is simply the visual effect of glitch capture and naturally gets worse with increasing ratio of raw to effective sample rate. Since the effective sample rate drops dramatically in roll mode, this explains why the double lines become so obvious in this mode.

Well, one might still ask why the effective sample rate has to be that slow and why sample memory is limited to 1.4Mpts in roll mode. But that’s another story

EDIT: corrected prediction of the response to an ideal 1ns pulse.

[Mark_O]

In this area it actually could happen that we might not see the trigger event on the screen. This is clearly a flaw, but is easily circumvented by avoiding this ‘grey’ range of sample rates when really narrow glitches can be expected to occur.

One problem there is that sometimes I'm not expecting there to be any really narrow glitches at all.  However, that does not stop them from occurring.    And it's one reason I may be using a scope... to check to see if things are occurring that I don't expect.  As in, shouldn't be there, but are.  I'd rather not have to avoid a 'grey range', which hasn't even been defined by the manufacturer.

[Exceptional continuing analysis, BTW.   ]

[Performa01]

@Mark_O

In general, I agree with you – and that’s the reason why this topic gave me some serious headaches and kept me investigating.

Nevertheless I should try to explain a little better what I had in mind when talking about ‘expectations’ with regard to narrow glitches.

Glitch capture does not work at sample rates >100MSa/s, so in general a potential problem exists for pulses <10ns wide.
The lowest sample rate >100MSa/s we can actually get is 125MSa/s at 35Mpts, which corresponds to a pulse width of 8ns.
For all other memory settings, from 7k to 28M, the lowest sample rate >100MSa/s is 200MSa/s, corresponding to a pulse width of 5ns.
That means, for all possible combinations of timebase and memory settings but one, the pulse width has to be less than 5ns in order to be able to cause a problem. Yet there is one single setting, where this limit is 8ns.

So I just wanted to point out that there is a physical limit to how narrow a pulse can be produced by any circuit, be it by intention or by accident – and that’s the bandwidth / transition times of active components in use.

For example, for logic devices with slow transition times, like TTL and LS-TTL, as well as CMOS up to HC, it would be very unlikely for a narrow pulse <8ns to occur. Of course, it is not totally impossible and could still happen at a very low amplitude, but then we would miss it anyway, as long as the trigger level is set to the nominal threshold voltage of ½ Vdd for CMOS. And as soon as we need to set a specific trigger level in order to capture the glitch (which would be totally different depending on the initial logic state), we need to be aware that there is something going on, and if so, we can just as well set up the scope so that it uses its full sample rate – which should be easy, given the amount of memory available.

So this is basically a problem for high speed logic debugging only, as I cannot think of any mechanism causing sporadic narrow glitches in analog circuits, including HF designs and discrete transistors, and I’ve certainly never observed one in some 40 years. This is what I mean that we can indeed expect – let’s say ‘predict’ instead – whether or not glitches could occur and if so, what the minimum pulse width would be for a given circuit.

Btw. I have corrected the paragraph describing the effects of an ideal 1ns wide pulse in my previous post, as it is obvious that the rise time of the scope alone will prevent that pulse from disappearing completely at 500MSa/s. For the same reason, this whole topic wouldn’t be an issue on a 100MHz scope.

Apart from all that, it shouldn’t be impossible to fix this issue in the SDS2000(x) V2 firmware and I certainly hope that Siglent engineers will come up with a working solution.

[Performa01]

Visibility of narrow pulses

For several tests I’ve used narrow pulses and sometimes pointed out that they were barely visible in the screenshots. This might lead to the false impression that it would be generally difficult to spot glitches on the scope screen, which isn’t true. So I thought I’d elaborate on that a bit more.

Generally, it should be obvious that narrow pulses appear on the screen as lines that are only one or two pixels wide, hence visibility also depends on the absolute screen resolution. The screen on the SDS2000 has an absolute resolution of about 114dpi which corresponds to a pixel width of ~222µm. This is not awfully big…

My computer screen where I’m viewing the screenshots has only ~81dpi and the pixel width is ~312µm and visibility should be better, but that’s not actually the case. In fact, visibility is significantly better on the scope than the screenshot viewed on my computer monitor. The reason for this is in the monitor profile, including settings for brightness, contrast, gamma and color space, which are optimized for natural looking photos as I do a lot of picture processing. It is obvious that the scope uses a quite different profile, optimized for graph viewing.

So it comes as no surprise that visibility of glitches is not bad on the scope, whereas it might be considerably worse on the computer screen, depending on the monitor profile in use.

That said, I still did a couple of tests to determine how the display of glitches can be improved.

First I show a screenshot with the default settings on the scope. Depending on your particular monitor settings, visibility of the narrow pulses on channel 4 as well as the edges of the squarewave on channel 2 might be somewhere in the range of fair to poor (Glitch_Intensity_Grade_50%)



Of course, the narrow pulses and steep edges are so dim because of the intensity grading and in situations like this, one might wish to be able to turn it off. Intensity grading simulates the behaviour of an analog scope, which gives us a lot more information about dynamic signals, but also has the disadvantage of poor visibility of fast edges, if not quite as bad as it used to be in the CRT era.

We cannot turn off the intensity grading.
Persistence doesn’t help either.
We can only turn up the intensity of the trace display (Glitch_Intensity_Grade_100% )



Visibility has clearly improved and might be all you’d ever want on the scope screen, but might still not be enough for the screenshot image. Even when the monitor picture is acceptable, one might still want better visibility when including screenshots in printed documents – without the need to post process the images, that is.

This is a situation where color grading as an alternative to intensitiy grading comes in really handy (Glitch_Color_Grade)



Yes, it might not look as pretty as before, but it maintains all the information of the 3rd dimension (intensity) without visibility problems. Even when I’ve stated some time ago that I don’t care for color grading, I’ve been disabused and by now be grateful that Siglent has implemented this display mode. 

[Mark_O]

Re: narrow pulse visibility on various screens...

My computer screen where ... visibility should be better, but that’s not actually the case. In fact, visibility is significantly better on the scope than the screenshot viewed on my computer monitor. The reason for this is in the monitor profile, including settings for brightness, contrast, gamma and color space, which are optimized for natural looking photos as I do a lot of picture processing. It is obvious that the scope uses a quite different profile, optimized for graph viewing.

So it comes as no surprise that visibility of glitches is not bad on the scope, whereas it might be considerably worse on the computer screen, depending on the monitor profile in use.

I noticed exactly the same behavior, while I was evaluating the SDS1000X series.  On-scope visibility fine, but visibility of traces on my PC screen substantially worse.  The way I dealt with this was simply to run my screen shots through IrfanView [a free PC app], and apply an Auto-Color Adjust to them (which I can easily do in batch-mode).  This was a quick one-step process, which improved screen captures significantly.

Attached is an example of your initial screenshot, adjusted:





[Updated to put a copy of your original underneath, to avoid having to scroll back and forth to compare.]

On my PC screens at least, this looks better than even your 100% Intensity version.  Plus a side benefit is the fact that it also brings up other areas of the DSO screen, like the shading on the buttons, top bar, and side boxes, which tend to vanish on the raw snapshots (which also don't look as good as they do on the scope itself).

[Performa01]

@Mark_O

Oh yes, this looks a lot nicer indeed! 

Actually I have to batch process all screenshots anyway, in order to convert the big bitmap files to PNG. I'm using Photoshop for this - next time when I have to convert some screenshots, I will see what can be done to resemble the look of the scope screen on an average computer monitor...

[nctnico]

Why do you save them as bitmaps? PNG is lossless for these kind of images!

[Mark_O]

Why do you save them as bitmaps? PNG is lossless for these kind of images!

   We are saving them as PNGs.  At least that's what I've always done, after conversion. 

But they come out of the 1000X only as BMPs, and I assumed that was true of the 2000 as well.  Perhaps not.

[nctnico]

Why do you save them as bitmaps? PNG is lossless for these kind of images!

   We are saving them as PNGs.  At least that's what I've always done, after conversion. 

But they come out of the 1000X only as BMPs, and I assumed that was true of the 2000 as well.  Perhaps not.

The SDS2000 screendumps I have are BMPs indeed! I forgot about that and naturally assumed a scope from this day and age uses JPEG or PNG for screendumps and not an ancient and inefficient format like BMP and not even using (RLE) compression.