Siglent SDS2000 new V2 Firmware

[Performa01]

Another Trigger Jitter Test.

I just came across a scenario which I thought might be worth sharing.

Fast Acquisition, Peak Detect, Sin(x)/x, 35Mpts.
Display Type Vectors.

Ch. 3: 60 MHz Sine, 1.2 Vpp
Ch. 4: 1 MHz Sine, 1.2 Vpp

Edge Triggering on CH. 4, rising edge, 20mV.

The first time I've ever seen some jitter on this scope, but that is to be expected when triggering on a really slow edge like this (Trig_Sine_Vectors):



We see a jitter of about 5ns, which is still very impressive!

The trigger edge rises less than 17mV within 5ns, so that is also the uncertainty of the trigger level, which in turn causes the jitter observed on the Ch. 3 waveform. As the vertical gain setting is 200mV/div; that means the uncertainty is just about 8% of a division, which in turn corresponds to exactly 2 LSB of the ADC. That is about as good as it gets. 

Changing the signal on trigger channel 4 to a squarewave with a rise time of about 13ns, all the jitter disappears as expected (Trig_Square_Vectors):



This is just another proof  that the most important part of any scope – the trigger system – really is as good as it gets on the SDS2000. 

[tautech]

XY Display.......

Once the signals are properly set up in Y-t mode, we can actually get a nice Lissajous figure in X-Y mode (XY_Display_2):

Dots?
I ask because the waveform looks "grainy"

Couldn’t resist creating a new Siglent logo (XY_Display_3)

[Performa01]

History Display.

One of the really nice features on the SDS2000 is the history display. This is a very useful analysis tool as it allows the examination of not just the current screen but also a bunch of acquisitions that have been taken in the past. The good thing is it doesn’t need to be enabled explicitly, it’s just always there and can be accessed whenever it is needed.

Of course, for this feature to be useful we need deep memory, and that’s where the 35/70 Mpts now available with V2 FW really help. On the other hands, restricted acquisition modes like Average and Eres, where there is no memory available, are pretty much ruled out by that.

For this test I’ve just setup two arbitrary signals on channels 3 and 4 and used peak detect mode with max. memory.

Ch. 3: 50MHz, 1.2Vpp sinewave, 100% amplitude modulated at 1kHz.
Ch. 4: 10MHz, 1.2Vpp squarewave.

The first screenshot shows the signals in Run mode (Hist_Sig):



Once we hit Stop (or access the history menu, which also stops the scope), we can either manually scroll through the individual acquisitions or automatically playback the entire history buffer in either direction at almost any interval we like. In this scenario, we got 80000 history frames and we can turn on a list display that shows the history frames including number, timestamp and time difference of the respective acquisition.

In manual mode, we can just scroll through the list, which can be very time consuming if there are 80000 entries, just as in this scenario. The list as well as the screen display is updated accordingly.

Just two examples for manual mode:

First, I manually selected a random acquisition where the amplitude modulated signal on Ch. 3 was at a minimum (Hist_Display_Min).



Second is an acquisition where the amplitude modulated signal on Ch. 3 was at a maximum (Hist_Display_Max).



We can also start history playback in either direction and hit the pause button anytime, and then continue with manual mode for instance. Playback interval can be anything from 1µs up to 1s. This means the interval at which the individual history frames are displayed and of course 1µs isn’t a realistic number, as the scope just isn’t capable of displaying frames nearly as fast as 1 million per second. The fastest I could get was about 2000 frames per second, which means we can playback 80000 frames within some 40 seconds. The amplitude modulated waveform looks almost like in run mode, just the screenshot doesn’t exactly show that as the playback slows down a bit when hitting the print button (Hist_Playback).



BUG Alert: While playing with the history mode, I tried to playback the history buffer at maximum speed, i.e. with an interval setting of 1µs. Of course it wasn’t nearly as fast as that, and after several thousand frames, playback suddenly stopped and then scope would respond to keystrokes only with a lag of several seconds. History mode was not operative any more. See screenshot (Hist_Frozen).



After hitting the Run/Stop button, the scope came back to live after several seconds. I tried it one more time, and it happened again, even with an interval setting of 10ms. After several attempts I finally managed to get it to playback the entire history buffer at an interval of 10ms. I did not need to restart the scope to get there, but it happened again and again, so history mode certainly is not yet reliable in operation yet.


Conclusion:
Apart from the bug described above, I think history mode can be extremely useful in general and even though there is no means for quick navigation within the history buffer, i.e. a jump function or something similar, it is still very usable. 

[rf-loop]

BUG Alert: While playing with the history mode, I tried to playback the history buffer at maximum speed, i.e. with an interval setting of 1µs. Of course it wasn’t nearly as fast as that, and after several thousand frames, playback suddenly stopped and then scope would respond to keystrokes only with a lag of several seconds. History mode was not operative any more. See screenshot (Hist_Frozen).

I can repeat this with next notes.

I can not repeat this if trigger source is CH1 or 2.
I can repeat this error if trigger source is CH3 or CH4

Independent of how many channels are acqured.
I'm not sure but looks like that also independent of history playback interval time setting.
Also looks like independent of if history playback display mode is dots or lines and Sin(x)/x on or off what also affect playback max speed.
Also looks like this problem is independent if math, including FFT or measurements or cursors are used in history playback mode or history is horizontally zoomed or horizontally shifted.
My rest life is not enough for test all possible settings combinations but strogly it looks this error is somehow connected to trigger source used in acquisition(?).
(also I have tested 1,2,3 or 4 channels on separately and 1+2 or 3+4 and also used every channel for trigger source. But every time if trigger source is CH3 or 4 in acquisition then history playback suddenly stop to random position and after then history freeze until run scope agen using run/stop or other things like default or autoset. (it looks like there is least less this problem if timestamp table is off during playback)


My version is
FW: 1.2..1.28.1
FPGA: 15.11.17-15.11.17-15.11.26
HW: 3-3
Model: SDS2304

[Performa01]

Dots?
I ask because the waveform looks "grainy"

Yes, it certainly was dots display, as this is my default setting.

I know, I could (should?) have changed it to vectors for the new Siglent Logo at least

In general, I don't mind a little 'grain' and only switch to vectors display if it really is required to aid in visibility.

[Performa01]

I'm not sure but looks like that also independent of history playback interval time setting.

Yes, that's what I found too. As I wrote, it also happened at 10ms interval, which is much slower than what the scope can do.

My version is
FW: 1.2..1.28.1
FPGA: 15.11.17-15.11.17-15.11.26
HW: 3-3
Model: SDS2304

So our firmware and FPGA program are identical, only the hardware differs (mine is 5-3).

[tautech]

I'm not sure but looks like that also independent of history playback interval time setting.

Yes, that's what I found too. As I wrote, it also happened at 10ms interval, which is much slower than what the scope can do.

My version is
FW: 1.2..1.28.1
FPGA: 15.11.17-15.11.17-15.11.26
HW: 3-3
Model: SDS2304

So our firmware and FPGA program are identical, only the hardware differs (mine is 5-3).

rf-loop's and mine are both pre-release dealer units model SDS2304 HW: 3-3 and are missing the MSO port and associated componentry, but same PCB AFAIK as the 5.3 HW.

[rf-loop]

rf-loop's and mine are both pre-release dealer units model SDS2304 HW: 3-3 and are missing the MSO port and associated componentry, but same PCB AFAIK as the 5.3 HW.

Yes. There mey be some tiny mechanical/HW "adjustments" in official marketing versions after pre-release version.
Example some pre versions may have extra noise in channels. This is because aluminium is not always easy material due to surface oxide layer.  If there is extra noise and unit is pre version, there may need tiny mod around internal aluminium chassis and input BNC's. Contact from inteernal aluminium chassis and BNC GND surface is not very good.

I have never seen this problem in official market versions after pre "demo"version.

[Siglent America]

Hello, Performa01.

I just thought I would let you know that the Siglent SDS2000(X) product engineering people have been reading your posts on this thread. They are currently working on the issues you have noted.

Thanks for your help.

[Marchello]

Hello, Performa01.

I just thought I would let you know that the Siglent SDS2000(X) product engineering people have been reading your posts on this thread. They are currently working on the issues you have noted.

Thanks for your help.

Hello!

When SDS2074X will be available for purchase?

Best regards!
Mark.

[Siglent America]

Hello, Performa01.

I just thought I would let you know that the Siglent SDS2000(X) product engineering people have been reading your posts on this thread. They are currently working on the issues you have noted.

Thanks for your help.

Hello!

When SDS2074X will be available for purchase?

Best regards!
Mark.

Hi Mark.
I can't speak for the areas outside North America but they are for sale here in N.A. now. The stock quantities will be small for awhile, however.

Regards

[Performa01]

Digital Channels broken.

I’ve briefly reviewed the digital channels with firmware SDS2000-V2.0-1.02.01.01.27 a couple weeks ago and found them basically working.

Now I wanted to take a closer look and thought about sharing my experiences here.
Quite sadly I found the digital channel function broken again with firmware SDS2000-V2.0-1.02.01.28R1, see attached screenshot (Digital_Broken):



Yes, decoding basically works and all the signals appear to be there, but all channels are at the same vertical position.

[Performa01]

Wave Gen.

I’ll start this review with some general thoughts.

As with most additional features that go beyond the core functionality of an instrument, we cannot expect them to replace dedicated gear, rather have to accept a bunch of limitations.

A DSO is just a DSO and just like the integrated trigger frequency measurement and the automatic measurements cannot replace (proper) frequency counter and multimeter, this is also true for the built-in waveform generator – but it could still be very useful when at a pinch.


The built-in Wave Gen of the SDS2000 is a single channel arbitrary waveform generator without sweep and modulation capabilities.

Many dual channel arbitrary waveform generators have been introduced during the last decade and these can be incredibly useful. Before that time, however, we had to make do with just one channel and this is still enough for the majority of applications today.
Even the old analog function generators provide internal/external sweep capabilities, i.e. frequency modulation. Nowadays we expect a complete set of modulation capabilities together with an internal universal modulation source, which means there must be essentially another DDS-generator per channel. The SDS2000 obviously doesn’t have a spare DDS generator to be used as modulation source and it doesn’t have the connectors usually associated with a fully-fledged waveform generator, like trigger/gate in, modulation in/out, sync out, which is no surprise, considering it is just a DSO after all.
However, a sweep function could have been easily implemented just in software.


According to the data sheet, it is a 125 MSa/s, 14 bits system with 1µHz of frequency resolution.

These specs sound good and would have been a big deal even just a decade ago. But the specs aren’t everything; what counts at the end of the day, is the actual signal quality.


The frequency range covers 25MHz for sine, 10MHz for square, 300kHz for ramps and 5MHz for arbitrary waveforms.

This is not too bad either. In the good old days, analog function generators were usually limited to 2MHz, and most early DDS function generators could not exceed 10MHz.


The output impedance is proper 50 ohms, but the maximum signal level is limited to 3Vpp into 50 ohms (6Vpp open circuit).

That’s a typical limitation of many built-in generators, as they lack a proper output amplifier that could provide 20Vpp open circuit and 10Vpp into 50 ohms. It should still be enough for a bunch of everyday tasks though.

 
Actual frequency resolution is just 2 or 4 digits

When reviewing the specs, the claimed frequency resolution of 1µHz is rather misleading. While the lowest frequency is indeed 1µHz, the default frequency resolution is exceptionally low at just 2 digits. This can be changed to ‘fine’ adjustment, where the resolution is 4 digits. That means that above 10MHz, the smallest frequency step is 1kHz, which might be too coarse for some measurements, such as determining the bandwidth of a 10.7MHz IF filter for instance. On the other hand, given the poor response characteristic of the select knob, this approach is still welcome as it would otherwise take hours to go through the entire frequency range.

The resolution for amplitude setting is 2 or 4 digits as well.


Waveforms

The Wave Gen provides all the standard waveforms including DC and noise, plus a few built-in arbitrary waveforms and 4 memories for user defined waveforms (AWG_Gauss)



I don’t know how well it works to create a user defined waveform and then transfer it into the scope memory. The manual suggests to use EasyWave, which didn’t come with the scope (there are just a couple PDFs on the CD). We should be able to download it from Siglent’s website, but since I wasn’t particularly interested in arbitrary waveforms right now I couldn’t be bothered.
Btw, the datasheet claims a maximum of 16k for the arbitrary waveform length.


Now let’s take a closer look at some waveforms:

Sine

Amplitude accuracy appears quite good. At 1kHz, a 2.8Vpp signal measures 1.00864Vrms, which is not too far from the expected value of 0.99Vrms, indicating an error of +1.8%. This really is not bad at all, given the fact that the actual resistance of my pass-through terminator is a bit high at 50.259 ohms.
The same experiment without pass-through terminator results in an output of 1.00596Vrms and the error is +1.6%.

No matter how many bits and what the sample rate is, what really counts is the signal quality. I don’t have a proper spectrum analyser right now, but I can make accurate THD measurements up to 20kHz and will use a properly implemented FFT on another scope to look at the frequency range above.

At 2.8Vpp into 50 ohms, the measured distortion levels from 20Hz to 20kHz are generally below 0.01%, thus would be well suited for quality audio measurements (AWG_THD)



As already mentioned, for higher frequencies I have to use the FFT on another scope, which doesn’t provide the dynamic range to measure distortion figures below 0.1%. In order to check the limits of my test setup, I measured 10kHz once again (AWG_Spectrum_10kHz)



THD is measured as 0.066% now, whereas the true figure is an order of magnitude lower. This test setup will still be useful, as the distortion figure inevitably rises at higher frequencies, hence will eventually enter the dynamic range available.

The sinewave remains nice and clean up to 5MHz, where distortion is still below 0.1%, but non-harmonic spurs touch the -60dBc mark (AWG_Spectrum_5MHz)



Distortion and spurs keep rising with increasing frequency and at 10MHz, THD starts exceeding 0.1% (AWG_Spectrum_10MHz)



At 25MHz, the signal shows all kinds of harmonic and non-harmonic content and THD is measured as 0.355% (AWG_Spectrum_25MHz)



All in all these results aren’t bad at all – at least the real thing appears a lot better in terms of spectral purity than what the rather unexciting specs in the datasheet would suggest.


Square

I’ve checked the square wave across the entire frequency range and could not find any flaws. Overshoot is next to non-existent and there particularly is no ringing, provided the scope input is properly terminated at 50 ohms. Rise- and fall times are both 24ns, which is still fast enough to produce a nice looking squarewave at 1MHz (AWG_Square_1MHz_2800mVpp)



At the maximum frequency of 10MHz the output doesn’t looks very square anymore, but that’s to be expected (AWG_Square_10MHz_2800mVpp)



So no complaints here either. The rise- and fall times are exactly as specified, and overshoot is actually much better.


Pulse

Minimum pulse width is 48ns, rise- and fall times are the same as with square. Again, the pulse looks nice and clean (AWG_Pulse_48ns_2800mVpp)




Ramp

Ramps are limited to a maximum frequency of 300kHz but the linearity looks still pretty perfect at that frequency in exchange. I chose a symmetry of 0% and as a big surprise, the leading edge has a risetime of only 12ns. So ramp can do twice as good as square and pulse (AWG_Ramp_300kHz_2800mVpp)




Noise

Noise at the maximum standard deviation of 225mV provides a reasonable flat spectrum up to 10MHz and submerges in the noise floor of my test setup (some -98dBV) at about 115MHz (AWG_Noise_225mV_2800mVpp)




Conclusion

The Wave Gen option on the SDS2000 is actually quite a useful signal source. Without any bells and whistles, particularly no sweep capability and limited output level, it still does the job for many applications and performs significantly better than specified in terms of signal purity.

[Performa01]

Noise Reduction

Just a few experiments with an extremely noisy signal.

Ch. 4 input: 1kHz, 500mVpp sinewave with 250mVpp white noise superimposed.
CH. 4 settings: DC coupling, full bandwidth, Probe 1x, Impedance 50 ohms.
Rising edge trigger on Ch. 4, HF-reject, Noise Reject on.
Display type dots.

With the above settings, I get a rock stable triggering despite the strong noise.
In normal acquisition mode, the trace (or should I rather say ‘track’ or even ‘field’?) looks like this (Noise_Norm)



In peak detect mode, we get the extremes only – because display type is dots! – so we effectively could call this ‘Envelope Mode’ – another reason why dots mode is a good default setting. Noise amplitude level now appears even higher a bit higher than it was set on the generator (Noise_Peak)



The same situation with display type vectors doesn’t look much different to normal acquisition mode – yet the envelope is still visible to some extent (Noise_Peak_Vectors)



But now we want to see the noise reduction of average mode. With just 4 averages, the effect is quite noticeable already. The original noise level of 250mVpp has been reduced to 125mVpp. The screen capture looks like there is even less noise, but this is only because now the waveform update rate is slow at about 5/s (one of the limitations in average mode), not showing all the scattered dots at once (Noise_Avg_4)



With 16 averages, the noise level halves again and is now 62.5mVpp (Noise_Avg_16)



With 64 averages, the noise level halves again to 31.25mVpp (Noise_Avg_64)



64 averages is about the sensible maximum; Not much can be gained with further increasing the averages. For instance, 256 averages do not halve the noise (as would be expected) – probably because we’re now in the realm of numerical noise introduced after the averaging process. Noise is now down to some 20mVpp (Noise_Avg_256)



For the reasons mentioned before, I did not test the 512 and 1024 averages settings, as they need very long to settle and still don’t reduce visual noise any further.

In this context, it would be interesting to see how strong the effect of the 20MHz input bandwidth limit is in this scenario. Yes, it does indeed affect the noise level, that is now down to 190mVpp (Noise_Peak_Limit)



The noise source for this experiment has a bandwidth of just 60MHz, so the reduction could be expected to be much stronger if the noise bandwidth were >300MHz.

[Performa01]

I thought it was a good time to provide a new list of all the bugs and flaws found so far for the SDS2000-V2.0-1.02.01.28R1 firmware, including all the bugs found in previous firmware versions, that have not yet been confirmed to be solved.

Bugs:

1.   Traces sometimes disappear when switching from Average or Eres acquisition modes back to Normal/Peak Detect and only can be brought back by toggling modes once again.

2.   Automatic measurements disappear in roll mode.

3.   Residual trace garbage on the screen and in the ‘Averages’ and ‘Enhance by bits’ menus after switching from Average/Eres to Normal/Peak Detect modes and using less channels.

4.   Clear Screen does not work.

5.   No memory available in Average acquisition mode.

6.   No memory available in Eres acquisition mode.

7.   Resolution enhancement in Eres acquisition mode doesn’t make it to the screen display.

8.   Memory depth selection is not restored when changing back from a restricted mode (Average, Eres) to Normal/Peak Detect.

9.   Sometimes a state is reached, where automatic measurements actually displayed on the screen don’t match the selection in the ‘Type’ menu.

10.   Automatic measurement for Vmax (and probably also Vtop and some others) gives nonsense readings for FFT trace.

11.   Strong spurious signals visible on FFT analysis with 70Mpts of memory.

12.   Trigger state ‘Arm’ and no automatic measurements update even though the scope is actually triggered, when Average/Eres acquisition modes are used and FFT analysis is active.

13.   Self Cal hangs and scope has to be restarted.

14.   Automatic trigger level for AC trigger coupling behaves the same as with DC coupling, instead it should reset the trigger level to zero.

15.   Display persistence doesn’t show on screenshots for small signal variations.

16.   History mode freezes during playback (probably only when trigger channel is 3 or 4).

17.   Digital channel display broken.


Flaws:

1.   Unexpected strong ghosting with peak detect in roll mode.

2.   Fast Mode has no effect on Average acquisition mode.

3.   Fast Mode has no effect on Eres acquisition mode.

4.   No resolution enhancement in Average acquisition mode.

5.   Low frequency resolution for FFT, apparently only 1024 points.

6.   Very slow update speed for FFT math.

7.   Offset error changes sign at 1mV/div vertical gain setting.

8.   Trigger Frequency Counter not reciprocal, thus very low resolution at frequencies <1MHz.

9.   Frequency counter accuracy considerably worse than competition.

10.   Automatic measurements very inaccurate for signals with pk-pk amplitude less than 2 divisions.


Bugs should be fixed at any rate.

For the flaws, some improvement would be appreciated, but it is also clear that for some (or even many) of them there might not be any reasonable improvement possible with the existing hardware.

[nctnico]

Still not going to return it? You have not gotten to protocol decoding yet...
BTW: did you try to move the digital channels? In an ancient firmware version you could move the digital channels individually.

[TheDefpom]

One thing I wish the firmware did is to not give a false impression of accuracy on the frequency display, it should reduce the number of digits to remove the trailing zeros, which make it look like it has a precise reading, when in fact it does not!

Maybe a way of adjusting the accuracy of the display could be added to the firmware also, to allow for the reference oscillator not being exactly on frequency, a calibration point, so it can be compensated for to give correct frequency display, at the moment it is of little use to me because it is so far out of accuracy.

[Performa01]

Still not going to return it?

Not me!

In general it’s a great DSO already, with exceptional low noise and a rock solid trigger system.

Granted, there is a number of bugs yet, but none of them is a show-stopper and I’m positive they’ll be fixed eventually.

Average acquisition mode suffers from the memory limitation, but then again, for the price I paid for the SDS2304, I might have got a WaveAce 2024 at best, where apart from the lower bandwidth and it’s not being an MSO, I wouldn’t have had to worry about memory limitations in certain acquisition modes, as there are generally not more than 12kpts per channel available...

Eres is even worse, as it doesn’t even do what it promises, but then again, how many scopes in this class do have a useful resolution enhancement in the first place?

FFT isn’t terribly useful, but this is also not uncommon in this class and quite obviously only manufacturers who offer scopes with 12 or more bits (where FFT starts to make really sense) go to the effort to implement it in a way such as to get the most out of it.

Only real annoyance is the trigger frequency counter, as it is low resolution, inaccurate and unreliable all at the same time. Where are the days, when we had analogue scopes with a Y-output, where we could hook up the frequency counter that had the resolution and accuracy that we needed for our task?

BTW: did you try to move the digital channels? In an ancient firmware version you could move the digital channels individually.

You are perfectly right – the bug I’ve observed is just about the initialization as it seems. Arranging the channels manually works, and even a nice auto arrangement (just as I’d have expected it right from the start and as it was in previous FW version) can be had by just one push on the position knob.

You have not gotten to protocol decoding yet...

Hopefully I will get to test the digital channels anytime soon. But what I can tell already, in principle everything seems to work – also parallel and serial decoding.

[Performa01]

Pass Fail Mode

This is an extremely valuable feature for finding anomalies in a signal – if it’s properly implemented, that is. On some scopes, the pass/fail test is dog slow and finding a glitch could take forever. So let’s see what the SDS2000 has to offer in this regard…

For this test, I use a basic square wave at 1MHz, 50% duty cycle, about 2.6Vpp amplitude and 12ns transition time for both edges. The automatic measurements indicate slower transition times, most likely because the signal generator doesn’t quite meet its specs at full amplitude of 10Vpp into 50 ohms and my test setup eats up a little speed too, with a total of 2 metres coaxial cable and a homebrew power-splitter (which is also the reason why only a fraction of the original amplitude makes it to the scope input).

Acquisition mode is peak detect and display type is dots (Waveform)




Now it’s time to prepare the mask for the test. I set the tolerances to 0.16 divisions for both x and y direction, that corresponds to 16ns and 80mV, or +/- 8ns and +/- 40mV, to be precise (Mask)



Please ignore the numbers in the Total/Pass/Fail display on the top right corner – these are just old values that will only be reset when a new test is started – which makes sense of course.

Now we can run the test for the first time – and nothing happens, other than the Total and Pass numbers count up at a rate of about 38000/s, which is – what do you know – exactly the waveform update rate for this setting. The Fail count stays at zero, as is expected for stable and undisturbed waveform.

Now we can make the waveform faulty – for instance by changing the square to a sine – but I didn’t want to be that uninspired. Instead I changed the rise time from 12 to 24ns on the signal generator, thus making sure the rising edge would violate the horizontal tolerance window by a few nanoseconds. I ran the test for 60 seconds, and sure enough, the result met all my expectations (Pass_Fail_SlowRise_60s)



The test ran 38000 times per second, resulting in a total of 2284039 inspected waveforms – and none of them passes the test. In other words, the SDS2000 generated some 38000 errors every second, which is quite impressive.

What is the real detection rate then? At 1MHz, we get one million faulty (slow) edges per second, and because of the trigger speed (waveform update rate) of 38kHz, the ‘examination rate’ is 3.8%. That means, if the fault is intermittent, statistically the test needs to run long enough for about 26 abnormal frames to occur, in order to detect the anomaly once. Not a bad prospect at all.


Now for the really tough test

I set up a second signal that can be superimposed on the basic waveform – it’s a nasty little positive spike, 100mV in amplitude and only 10ns wide at a repetition time of 100ms. Transition times are supposed to be a tad over 2ns and the scope says 3 – so my test setup isn’t that bad after all, considering the scope itself is supposed to have a rise time of about 1.2ns. Please note that both the vertical gain as well as the timebase settings are very different to the previous screenshot (Glitch)



Both signals mixed together provide the sporadic signal anomaly that I wanted to use for this test. Because of the low frequency of just 10Hz only one in 100000 waveforms gets disturbed and the deviation from the original is rather tiny. Please ignore channel 2 which is just a sync signal that was required for triggering in order to get a nice screenshot, as the glitch is not synchronized to the base waveform, i.e. it appears randomly anywhere on the trace (Waveform_Mix)




I did another 60 second pass/fail test with the signal shown before (Pass_Fail_Glitch_60s)



Because of the glitch just occurring once in 100000 periods of the base signal, we would expect a pass/fail ratio of just that. In fact, the scope detected almost twice as much abnormal acquisitions, as the ratio was 2298858 / 42 = 54700. I guess that’s just the pitfalls of statistics – if the test would run for a longer time, I expect it to converge to the expected ratio of 100000.

On a side note, when playing with the pass/fail test, a similar bug as already reported for the history mode can be observed. In rare instances, the scope stops showing a trace and only responds to keystrokes with a considerable delay. As with the problem in history mode, hitting Run/Stop twice brings the scope back to live. The bug happens much less frequently here than it did in history mode. According to the tests done by rf-loop, it might well be that it has something to do with the trigger channel. I consider it a good thing that I use channel 4 for the majority of my tests, as most folks – particularly firmware developers/testers – will probably just use channels 1 and 2 most of the time and expect 3 and 4 to behave the same – which isn’t always true, as we have learned by now


Conclusion

Apart from the little bug described above, the pass/fail test works just great – in fact much better than on many other scopes we’ve seen so far in this class. Well done Siglent! 

[rf-loop]

Note1: This test is old. From December 2014. At this time SDS2000 FW was some old V1 version.
Note2: Mask used in Siglent made using PC.
Note3: Images resized so that on the PC screen can note difference between 8" and 7" display.

In these tests SDS2k maximum wfm/s average speed was barely around 110kwfm/s. (highest burst speed of course more - inside one display update period)  Today with V2 FW versions average max 140kwfm/s.



First Rigol DS1000Z series oscilloscope.
Scope looks nice, rich of features, display looks nice and well finished and so on. 

First this is example how bad it can be.



In this test Mask test fails continuously (every acquire fail)
Speed is 1 waveform per second. Really, it can capture one waveform in one second in pass fail test in case that test result is fail. 



Then we can look how its speed go with Siglent.



Here with Siglent. Every acquired waveform fails in test. It capture 110000 waveform in one second ans also output signal tell "fail" for every captured failed waveform. (small image, made with other oscilloscope connected to pass/fail output BNC)






Here  every acquired waveform pass in test. It capture 110000 waveform in one second. (small image, made with other oscilloscope connected to Trig/out BNC (output mode changed for measure speed using trig out signal. In this case pass/fail do not give signal out)

Simply, with speed of Siglent this function is very powerful and useful as real tool for find signal anomalies.
As noted previously, I have  made full set of tests and it do all Mask tests with sama speed what it can capture without this function.

[nctnico]

Still not going to return it?

Not me!

In general it’s a great DSO already, with exceptional low noise and a rock solid trigger system.

Granted, there is a number of bugs yet, but none of them is a show-stopper and I’m positive they’ll be fixed eventually.

Average acquisition mode suffers from the memory limitation, but then again, for the price I paid for the SDS2304, I might have got a WaveAce 2024 at best, where apart from the lower bandwidth and it’s not being an MSO, I wouldn’t have had to worry about memory limitations in certain acquisition modes, as there are generally not more than 12kpts per channel available...

Eres is even worse, as it doesn’t even do what it promises, but then again, how many scopes in this class do have a useful resolution enhancement in the first place?

FFT isn’t terribly useful, but this is also not uncommon in this class and quite obviously only manufacturers who offer scopes with 12 or more bits (where FFT starts to make really sense) go to the effort to implement it in a way such as to get the most out of it.

Tektronix' TDS500/600/700 series are also 8 bit but they have a very usefull FFT feature (*) because there is no reason you need 12 bit for FFT to be useful! Same goes for Eres and averaging. Without long memory they are utterly useless because at some point you will want to zoom in on a long signal. You don't seem to perceive these as problems now but I'm quite sure you are going to see these limits as serious limitations of the SDS2000 in the near future when you are going to use it for real work. Having these limitations shows Siglent is still not on track with the firmware development of the SDS2000 and/or doesn't understand how an oscilloscope should work. The firmware update are just quick fixes to check items of the list and not to make the SDS2000 useful for any real work. The same goes for decoding: if that doesn't decode everything in memory then it is useless for any real work (been there, done that).

edit: (*) Tektronix' TDS500/600/700 have selectable FFT length and can average the FFT result making it ideal to look at the frequency response of a system or filter. More bits are only required if you need more dynamic range but for many measurements the 40dB range you can get from an 8 bit system is more than enough.

[Performa01]

Another observation regarding pass/fail mode:

When looking at the screenshots in my previous post, we can see where the last violation of the mask occurred. The violating part of the trace appears highlighted in front of the mask, and for the first test (with slow rise time) it can be seen on the screen during the test, which is no surprise since the violation happens permanently on every single positive going edge (Pass_Fail_SlowRise_60s_Hint)




It is different for the second test though. As the violation only occurs once every 100000 signal periods, we really need to look close to spot the glitch every now and then – if we’re lucky. Usually we don’t see it. But on the screenshot it is clearly visible (Pass_Fail_Glitch_60s_Hint)




The funny thing is that in this screenshot, the glitch occurred pretty much at the same spot where it was in the screenshot when I initially showed my test signal (by triggering on the sync signal of the glitch pulse generator).
Now I wondered if every screenshot during the mask test would clearly show the violation or if it was just a lucky coincidence. So I ran the test again and took a number of screenshots at random times. And sure enough, none of them showed any mask violation, so I just had a lucky moment when I got the violation visible on that particular screenshot.

I tried persistence mode, but this doesn’t appear to have any effect during pass/fail test. It would be a nice improvement if we could indeed have some persistence during the test. For instance, not updating the screen display after a mask violation for the time according to the display persistence setting would be great, as this would clearly show why the mask test has failed – so I will add that to my wishlist. Maybe Siglent could implement that eventually?

[Wuerstchenhund]

Granted, there is a number of bugs yet, but none of them is a show-stopper and I’m positive they’ll be fixed eventually.

Or so you hope!   Don't forget that this scope is on the market for almost two years now, and still suffers from bugs that make it pretty useless for any real type of work.

As nctnico said, Siglent is just ticking off boxes of bugs that are reported by users. It also appears that software testing is pretty much non-existent in Siglent (otherwise they would have found the problems before releasing the firmware, most bugs are hard to miss even if you tried!), and relies on users to do find bugs and report them back instead.

In short, you pretty much bought a half-finished (ok, 70% finished) scope and agreed to work as a beta tester for free. 

And people wonder how Siglent can be cheaper than other brands...

Average acquisition mode suffers from the memory limitation, but then again, for the price I paid for the SDS2304, I might have got a WaveAce 2024 at best, where apart from the lower bandwidth and it’s not being an MSO, I wouldn’t have had to worry about memory limitations in certain acquisition modes, as there are generally not more than 12kpts per channel available...

Yes, the WaveAce is shit (guess who made them?) but there are many other alternatives which aren't.

Eres is even worse, as it doesn’t even do what it promises, but then again, how many scopes in this class do have a useful resolution enhancement in the first place?

Most of them? The Keysight DSOX2k has a hires mode (10bit), as does the R&S HMO1000 (up to 16bit?). If I remember right even the Rigol DS2k/DS4k have some working hi-res modes.

FFT isn’t terribly useful, but this is also not uncommon in this class and quite obviously only manufacturers who offer scopes with 12 or more bits (where FFT starts to make really sense) go to the effort to implement it in a way such as to get the most out of it.

That's nonsense, sorry. FFT does not need 12bit vertical resolution to "make sense", and is a pretty useful facility even on 8bit scopes, assuming of course the implementation isn't crap (like Rigol's limit of a few thousand points only) and works correctly (which it does on other scopes).

And scopes like the DSOX2k or the R&S HMO1000 show that even in this class FFT doesn't have to be shit.

Only real annoyance is the trigger frequency counter, as it is low resolution, inaccurate and unreliable all at the same time.

Reliability is certainly an issue, but frankly what accuracy do you expect from a scope with a timebase that is spec'd with +25ppm? Without an external clock reference (i.e. GPSDO) the accuracy will be limited by nature.

Where are the days, when we had analogue scopes with a Y-output, where we could hook up the frequency counter that had the resolution and accuracy that we needed for our task?

Y out was pretty much only available in a few specific Tek scope models and was also bandwidth limited, so it was only really useful for very specific cases.

[Performa01]

Tektronix' TDS500/600/700 series are also 8 bit but they have very a usefull FFT feature because there is no reason you need 12 bit for FFT to be useful!

Well, yes, it depends on the requirements. When I reviewed the SDS2000 signal generator some posts earlier, I think I’ve demonstrated very clearly what a well implemented FFT can do even with just 8 bits, squeezing out an impressive dynamic range of more than 60dB by use of appropriate resolution enhancement techniques. But then again, this was still not enough to verify the spectral purity of the SDS2000 signal gen, and it is not enough for many other tasks as well.

But that wasn’t my point anyway. The point is that in my experience, only manufacturers that also make high resolution scopes have the inclination and experience to provide an FFT implementation that makes the most out of any existing hardware. Tektronix, as a well known manufacturer of RF gear, clearly have that experience. That’s probably why they knew that an 8 bit FFT wouldn’t cut it for many tasks, hence built a proper spectrum analyser into their MDO (mixed domain) series of scopes.

Same goes for Eres and averaging. Without long memory they are utterly useless because at some point you will want to zoom in on a long signal. You don't seem to perceive these as problems now but I'm quite sure you are going to see these limits as serious limitations of the SDS2000 in the near future when you are going to use it for real work.

Well, I think I have made very clear that having no long memory is a serious limitation and I really hope that Siglent is listening.

I don’t perceive it as a BIG problem now, because normal and peak detect work as expected, with up to 35/70 Mpts of memory, and my point was that there are still scopes in the market, at a similar price point or even more expensive, that don’t have more than just a couple of kpts of memory to begin with, no matter what acquisition mode. The WaveAce was just one example, Tektronix has similar offers.

And your assumption is wrong. I do use this scope for ‘real’ work (in my home lab), have used it even with the old V1 firmware, even though this wasn’t that great an experience.
Personally, I would even consider it for professional work, even though it’s not mature yet and operators need to be familiar with its quirks – and by now, not all quirks are even revealed. But then again, other scopes have quirks as well and we can never blindly rely on what a scope is telling us. For instance, the scopes of some particular A-brand gave us regular headaches with their intractable trigger system, which I consider much more a show stopper than any flaw on the Siglent.
 
Average acquisition mode is a nice feature to have, but certainly not essential for most tasks. Analogue scopes generally don’t have an average mode, yet engineers could make do with that for many decades.

Eres is a mixed bag anyway, because it inevitably limits the bandwidth depending on the actual sample rate. Sure, this might not be a problem in many cases if we had the full memory available, hence a constant high sample rate up to slow timebase settings, so I do hope Siglent will cure that eventually.
Still, if we really need high resolution, nothing can beat getting a proper 12 bit scope, which does not only give us the higher resolution, but also the accuracy, and the bandwidth doesn’t change with sample rate either.

Having these limitations shows Siglent is still not on track with the firmware development of the SDS2000 and/or doesn't understand how an oscilloscope should work. The firmware update are just quick fixes to check items of the list and not to make the SDS2000 useful for any real work.

Sorry, just because with the old V1 FW it didn’t meet your particular needs, claiming it isn’t useful for ANY real work is blunt bashing, since the basic functionality is sound. Only if I had paid two (or more like three with all the options) times as much to get a 300MHz/4Ch. mixed mode scope from some A-brand, I would complain loudly, but since I preferred staying cheap, I just have to be patient – as long as Siglent cares to improve their products based on user experience.

The same goes for decoding: if that doesn't decode everything in memory then it is useless for any real work (been there, done that).

Who says that it doesn’t?

All I can tell so far is that it works just like any other MSO or LA. It captures screen by screen at the chosen timebase, and if this results in thousands of packets per screen, one will of course not see any meaningful decoding without stopping acquisition and zooming into the acquired data.

This even works in history mode, which essentially is segmented memory anyway. There are 14 Meg available when using digital channels and as always with segmented memory, we can chose to have 14 Mpts and only one segment if we’re interested in lots of data for just one single trigger event, or e.g. 416 segments with 70kpts each if we’re interested in analysing lots of subsequent acquisitions (with still plenty of data for each trigger event).

[nctnico]

The V2 firmware doesn't look like it is much better than the V1 firmware. Just more things plastered over. If you want to use an oscilloscope's FFT function to check the spectral waveform purity of the signal generator than you are clearly using the wrong tool. Either way the value for money the SDS2000 offers just isn't good because a lot is severely limited at best. You can buy a used DSO for the same amount of money which has proper FFT and works as advertised. The added value of the SDS2000 is in the MSO, protocol decoding and advanced features but it is those that cause most of the headaches. If I didn't need protocol decoding I'd never bought the SDS2000 to begin with! Also your remarks about averaging and high res being OK with a short memory is nonsense. They are very handy to clean a signal up so you can make accurate cursor measurements. I made good use of that in one of my recent projects on a trace which was several seconds long.

Still I'd like to see how the protocol decoding works in the V2 firmware and whether you can zoom (using the s/div knob) into the bits of a message without losing the decoding. And does zoom mode work together with decoding in the V2 firmware?