Siglent SDS2000 new V2 Firmware

[Performa01]

@Siglent

Thank you very much for the response, you’re welcome.

As long as I have faith in you trying to improve your products, I’ll gladly share my test results.

I think the SDS2000 series has a great potential, as the basic DSO functionality is really nice and solid, which makes this scope very attractive already. If you manage to make all the bells and whistles work equally well, this scope will not only be very competitive but even a killer in the low budget market segment.

From what I’ve seen so far, the new 2000X should be a step in the right direction too, regarding ergonomics and HW features.

[Performa01]

I’ve just upgraded to firmware SDS2000-V2.0-1.02.01.28R1 and will use that as a basis for any future reviews – until the next revision comes out, that is.

The update went well without problems, but the self cal after the restart would hang at 5% forever. After another restart it worked though, so I’m willing to look at this as just a glitch.

At this point I thought it would be helpful to make a list of all the bugs and flaws found so far for the previous SDS2000-V2.0-1.02.01.01.27 firmware. Here it is:

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.   No offset error correction at 1mV/div vertical gain setting. (fixed with V2.0-1.02.01.28R1)

3.   Automatic measurements disappear in roll mode.

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

5.   Clear Screen does not work.

6.   No memory available in Average acquisition mode.

7.   No memory available in Eres acquisition mode.

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

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

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

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

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

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


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.


As can be seen, I’ve divided the list into two segments.
Bugs should be fixed at any rate.
Flaws are – well, just 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.

I will not explicitly review any of these with every new firmware, unless there’s a corresponding hint in the release notes.

Just by now, I’ve reviewed the 1mV/div issue and think it is resolved, as I’ll demonstrate in a subsequent post.

[Performa01]

1mV Offset Error retested

With the new FW release V2.0-1.02.01.28R1 there’s a hint in the release notes that the 1mV/div vertical gain setting has been corrected. Let’s see…

The scope was running for >2 hours and then the firmware update plus a self-cal has been performed.

Setting for all channels: DC-coupling, bandwidth limit 20MHz, Probe x1, internal 50 Ohm termination.

Screenshots include cursor measurements to show the offset distribution.

Offset_2mV_28R1:
Run mode, all channels set to 2mV/div and adjusted the cursors in Y2-Y1 mode. Difference in offset voltage between all channels is 480µV, which is the same as in the first test.




Offset_1mV_28R1:
Run mode, all channels set to 1mV/div and adjusted the cursors in Y2-Y1 mode. Difference in offset voltage between all channels is 480µV again, which meets my expectations. This issue seems to be fixed.




EDIT: Yes, the magnitude of the offset error at 1mV/div is now consistent with the 2mV/div setting, but it still changes sign as can be seen from the screenshots. WHY? This seems a bit odd.

[Performa01]

Frequency Display

On several occasions, it strikes me that the frequency display is not accurate, see screenshot (Frequency_Display_1MHz), where an accurate 1MHz (< +/-1ppm) signal is displayed as 9.99982MHz, that is an error of 18ppm.



Yes, an error of 18ppm is still within the specified horizontal timebase accuracy of 25ppm, yet I was a little disappointed because even my old Rigol 1052E is way more accurate than that (in fact, it was spot on within the bounds of its 6 digit frequency counter). I even got it out of the “Not-used-anymore-but-still-too-precious-to-be-discarded-gear-cabinet” and powered it on, just to prove my memory didn’t fool me (Rigol_1MHz):



But then again, the SDS2000 also appeared to be spot on at 1kHz (Frequency_Display_1kHz):



Further investigations revealed the reason for this discrepancy: the SDS2000 does not have a modern reciprocal counter, like even the old Rigol does, but just a primitive standard counter with a gate time of 1s, which limits the resolution to essentially 3 digits at 1kHz. This way, the 18ppm error gets swamped of course. The display still shows 6 digits though, thus suggesting a much higher resolution (and accuracy). 

I consider this is a bit disappointing and would like to see a state of the art (reciprocal) frequency counter in an instrument like this, as well as a few cents more for a better internal crystal oscillator – or one that can be calibrated by the user, even though this probably would be a rather unique approach…

[Performa01]

Self Cal only works reliably after a restart.

Now I had it again. Started a Self Cal and the scope got stuck at 0%. Only after a restart, it worked as expected.

This odd behaviour has been newly introduced with the latest FW revision V2.0-1.02.01.28R1

[Performa01]

Trigger

I’ve already mentioned that the trigger system on the SDS2000 is superb in my book, and now I want to back up this claim with some detailed test results.

The basic settings for the test to follow are:

Only CH. 4 active with DC Coupling, Full Bandwidth, Probe 1x, Impedance 50 Ohms.

Display type dots, persistence 1s.
Acquisition Normal, 28M Memory, Fast Acquisition.

Trigger Type Edge, Source Ch. 4, Slope Rising, Holdoff Close, DC Coupling, Noise Reject Off.
Unless stated otherwise, trigger level is auto-adjusted by pushing the trigger level knob once.


Trigger Bandwidth:

This used to be an important parameter on analog scopes, as it determined the absolute frequency limit for a stable waveform display. The same is to expect for DSOs, when analog trigger systems are used.
Like many modern DSOs, the SDS2000 has a digital trigger system, hence no explicit trigger bandwidth anymore. As a rule of thumb, just about any signal can be triggered regardless the frequency, as long as it appears on the screen with a peak to peak amplitude (minus noise) that exceeds one vertical division. This is true for any digital trigger system and the exact minimum trigger amplitude varies a little between different scopes, we’ll find out what it is for the SDS2000 right now.

Trigger sensitivity:

As stated before, trigger sensitivity is independent of frequency, but trigger hysteresis obviously has some impact. So we start the test with Noise Reject On, which supposedly increases the hysteresis to some fixed (and unknown) value. So there is no adjustment for the hysteresis, but only two settings, Noise Reject On/Off. As mentioned before, we start with Noise Reject On, hence high hysteresis and use a rather low frequency of 200kHz for this test. Reason is – apart from the fact that signal frequency should not matter – that I’m still able to accurately measure the actual signal amplitude at this frequency (rather than just relying on the signal generator setting).

Vertical gain setting for this test is 200mV/div. I don’t go any lower as I want to see the sensitivity of the trigger system alone, where noise of the analog frontend should have as little impact as possible.

With auto trigger level and noise reject, we get reliable triggering down to 310mVpp, which is about 1.5 divisions, see screenshot ‘Trig_NR_min_auto’:



Note that the automatic measurements suggests a level of  336mVpp, which clearly isn’t correct (+8.4%).
There is also the ‘Amplitude’ measurement, which should be essentially the same for an undistorted sinewave as this, but it reads only 296mV (-4.5%).
It seems that quantization noise takes its toll here.
But then again, an 8-bit scope is not a precision instrument, all the more so with a signal peak to peak amplitude that is less than 19% of  full screen (and less than 15% of full scale for the 8-bit ADC).

Also note the frequency display, which reads complete nonsense (remember, tsignal frequency is exactly 200kHz). AT the same time, automatic period measurement shows the correct value of 5µs.

With manual tweaking of the trigger level we can get down to just 150mVpp, equivalent to 0.75 divisions (Trig_NR_min_man).



Automatic amplitude measurements are off again and period shows a ridiculous number. Instead, now suddenly the frequency display has at least a remote similarity with the real value.

Now let’s repeat these tests with Noise Reject switched Off:

With auto trigger level, we get reliable triggering down to 120mVpp, equivalent to 0.6 divisions (Trig_min_auto).



Amplitude measurement appears correct here (other than Pk-Pk) and this is also true for the period, while the frequency display shows all kinds of street numbers, just not the true frequency of the input signal.

With manual tweaking of the trigger level we can get down to just 50mVpp, equivalent to 0.25 divisions (Trig_min_man).



Automatic measurements are totally off now, which indicates a major offset error. Despite the tiny amplitude, Period appears almost correct and even the frequency display is in the same ballpark at least.

Since we got inaccurate measurements as a side effect of this test, I’ll just verify that they do indeed work as expected, as long as the signal amplitude is high enough. It appears that we need to have a peak-peak voltage level of more than 2 div in order to get reasonable accurate measurements. This is also true for the frequency display (Trig_display_verification):





I’ll end this post to draw a conclusion on trigger sensitivity. And I still think it is just superb – clearly as good as it can get.

The automatic measurements and all the more so the frequency display on the other hand let us down, if the peak to peak amplitude of the measured signal drops below two divisions.

[Performa01]

Trigger Noise Reject.

We have tested trigger sensitivity with noise reject on and off and got quite different results, but now we want to see how noise reject works in practice.

For this test I’ve set up a noisy signal, that is just the familiar 200kHz sinewave at 500mVpp with a superimposed 150mVpp noise signal. Without noise rejection, we get the expected result: unstable triggering on both edges (Trig_Nois_NR_off).




In the exact same situation, with noise reject turned on, we get a much nicer picture (Trig_Nois_NR_on).



Despite the strong noise, all the spurious triggering is gone and we get a totally stable picture.

Conclusion: Well done on that one! 

[tautech]

Self Cal only works reliably after a restart.

Now I had it again. Started a Self Cal and the scope got stuck at 0%. Only after a restart, it worked as expected.

This odd behaviour has been newly introduced with the latest FW revision V2.0-1.02.01.28R1

I can confirm this, however I've seen this ONLY once.

In this case, use of the scope from cold followed later by a Self Cal produced this freeze.
But once the scope has been restarted and Self Cal'd, no amount of control adjustment or use and further Self Cal's could replicate the initial freeze.

I'll run a few more tests to try and get it to happen again.......

[Performa01]

Trigger Stability and Channel Skew.

Another interesting aspect on a trigger system is its stability, i.e. the absence of excessive jitter, as well as that all channels are triggered synchronously so that we can make accurate time measurements between them.

Let’s start with the stability of the trigger point which actually means stability of the trigger level and in case of a digital trigger – as here – also the proper interpolation of samples to determine the exact trigger point.

First screenshot just shows the test signal – a very accurate and stable 10MHz signal derived from an OCXO – at the trigger point and minimum timebase of 1ns/div (Trig_Stability).



Apart from a tiny offset error, the trigger point sits exactly where it should and absolutely no jitter can be seen. Granted, this cannot be proven by a screenshot, even with persistence of 1s turned on, but I can tell you the trace on the screen looked absolutely static.


Next is the same signal, but with maximum trigger delay. I did a number of tests and this screenshot is just an example, with a timebase setting of 50ns/div and a 500µs delay. Generally, the trigger delays seems to be limited to 10000 times the timebase setting and honestly, I don’t know how that compares to other scopes as I’ve never ever had a situation where I would want the trigger point to sit far outside the visible screen area, hence I’ve never tried that before.

This time I did it, just because I remember some issues with trigger jitter in a similar setup with the Rigol scopes, so I wanted to see how stable the trigger delay on the Siglent is.

As mentioned before, I’ve tested this at various settings, of course also with 1ns/div and 10µs delay. In not a single case could I observe even the slightest trace of jitter though. The trigger system just cannot be faulted on this scope (Trig_Stability_Delay_500us).




The last test has not much to do with the trigger system, but a lot with overall system architecture and attention to detail in the entire signal path. It is the skew between channels, which should be ideally nonexistent of course.

I used a stable 100MHz signal (derived from an OCXO) to feed all four channels in parallel (Channel_Skew).



At the fastest timebase of 1ns/div, we can see the sight differences in the frequency response of the individual channels, as the amplitudes are clearly different, but there is barely any skew visible between channels. If at all, we are talking about a few tens of picoseconds(!) here, and as you’ve already guessed, I quite obviously don’t have the means to guarantee that all four signals actually arrive at the scope inputs at the exact same picosecond. However, this is an impressive result in my book. 

It goes even further, as this scope offers a means to correct any residual skew between channels. In the example shown before, it appears like all cannels are nicely aligned, except for channel 2, that is just a tad late.
A correction of 20ps for channel 2 solved this ‘issue’ (Channel_Deskew).




Conclusion:

The SDS2000 scope is a stable system indeed. Neither trigger level nor trigger delay time showed any noticeable jitter at all, and all four channels are nicely in sync and the ‘Deskew’ option will not see much use in practice, unless we introduce some error by mismatched cable lengths at the inputs. Once again, well done, Siglent! 

[Performa01]

But once the scope has been restarted and Self Cal'd, no amount of control adjustment or use and further Self Cal's could replicate the initial freeze.

I had my scope running continuously for at least 24 hours and done at least two self cals within the first few hours after initial startup.
Then when I stumbled across the rather high inaccuracies of the automatic measurements, I estimated that even for an 8-bit system under the given circumstances, an error of 8% was a bit high, so I decided to run another self cal. Then it happened and I knew that the very same problem, that I’ve already had immediately after the FW-update, was not just a glitch 

EDIT: Btw, this additional self cal did not reduce the measurement errors, so we just cannot trust them for signal amplitudes lower than two divisions.

[tautech]

Neither trigger level nor trigger delay time showed any noticeable jitter at all, and all four channels are nicely in sync and the ‘Deskew’ option will not see much use in practice, unless we introduce some error by mismatched cable lengths at the inputs. Once again, well done, Siglent! 

AFAIK this feature is primarily used for nulling propagation delays between Current and Voltage probes especially when using the Power Analysis option to maintain accuracy of the various computed results in that mode.
Siglent produce a USB powered "Power analysis deskew fixture" especially for this purpose:
http://www.siglentamerica.com/prodcut-fjxx.aspx?fjid=1311&id=25&tid=1&T=2

The "small current loop" part of the PCB needed to be narrowed slightly to permit my Tek P6021 current probe to be attached and perform a Deskew operation.

[Performa01]

AC Trigger coupling.

Most of the time we use DC coupling for the trigger, and there is not much to tell about it, other than it works just as it should. We rather want to examine AC trigger coupling now.

Why and when would we need AC coupling for the trigger at all? Usually, we make that choice for the channel input and if we select AC coupling there, the trigger will inevitably be AC coupled as well. So there we already have the answer – we have the opportunity to force trigger into AC coupling, even when the corresponding input channel is DC coupled. This can be useful for AC signals that have a considerable DC offset and we want to see this offset on the screen. We have to use DC input coupling then and adjust the trigger level accordingly, so to get a static display of the AC portion of the signal. This certainly works without problems and we can even push the trigger level knob in order to auto adjust the trigger level (Trig_Offset_Auto).




We can even move the curve around by means of the position knob and the trigger level will follow nicely (Trig Level_Follow).




But that doesn’t work if the signal offset is not stable, but changes with time. The following test shows a 1Vpp 200kHz sinewave that is superimposed on a 2Vpp triangle at 100mHz, which acts as a variable DC offset here. With DC trigger coupling, we can set the trigger level wherever we want, we still cannot get a continuously triggered (hence stable in the time domain) signal. We will get just garbage on the screen periodically (Trig_Variable_Offset_DC).



It’s totally different if we alter the trigger coupling to AC. Even though the trigger level is at zero and therefore appears outside the signal amplitude range, we still get a nice waveform display. The waveform constantly changes its vertical position on the screen, but remains stable on the time axis (Trig_Variable_Offset_AC).




So this all works very nice, but now we finally have got some minor bug in the trigger system too. If we have a signal with a substantial DC offset and then push the trigger level knob, the scope does an auto adjust just as it would with DC coupling. The result can be seen in the next screenshot (Trig_Bug_AC_Auto):



Even though it looks like the trigger level is well within the signal amplitude range, it is actually not. With AC coupling, the trigger system always ‘sees’ the centre of the waveform amplitude as zero volt, but in this example the level is set to 416mV, which is clearly outside the 440mvpp == 220mVp amplitude of the signal (according to the automatic measurement).

So this is clearly a bug and pushing the trigger level knob in AC coupled trigger mode should just bring the level back to zero.


Conclusion:

Other than the minor bug regarding trigger level auto set, AC trigger coupling works as expected. I’ve also checked that there are no additional stability/jitter issues, so it is indeed well implemented. 

EDIT: Fixed some typos

[Performa01]

AFAIK this feature is primarily used for nulling propagation delays between Current and Voltage probes especially when using the Power Analysis option to maintain accuracy of the various computed results in that mode.

Oh yes, that certyinly makes sense - didn't think of this - but then again, in a (very) remote sense it could be viewed as some  form of mismatched input cabling that I've mentioned

[Performa01]

Trigger Coupling LF/HF-Reject.

Since the invention of triggered oscilloscopes some 70 years ago, filters have been used to aid in getting stable triggering on difficult signals.

The SDS2000 provides lowpass (HF-Reject) as well as highpass (LF-Reject) filters, and of course even plain AC trigger coupling also is just some form of LF-Reject – a highpass filter with a very low corner frequency. I will take a look at all three here.


AC Trigger Coupling

I was interested in the corner frequency of AC trigger coupling and found this to be about 8Hz (Trig_Pole_AC_2).



We can see that at first glance the trigger point does not match our expectation. Since the trigger is set to rising edge, we would expect it to be exactly at the zero-crossing of the rising edge, while it actually sits half way between that and the negative peak.
This is because the signal frequency is 8Hz, thus exactly at the -3dB corner frequency of the AC trigger coupling circuit. This in turn causes a 45 degree phase shift, which is what we see here.


LF/HF-Reject

We cannot determine corner frequencies for LF/HF-Reject in the way we did for AC trigger coupling, as these are quite obviously no analog-like first order filters, but digital with a fairly flat phase response. So I rather check the frequency where stable triggering on a signal with just one division peak-peak amplitude remains possible.

For LF-Reject, the lowest possible trigger frequency is 1MHz.

For HF-Reject, the highest possible trigger frequency is 700kHz.

To demonstrate the usefulness of these filters, I’ve set up a signal mix consisting of two sinewaves at 500kHz and 2MHz.

With AC/DC trigger coupling, as expected we can’t get a stable picture on the screen (Trig_500kHz_2MHz_AC).




When we use LF-Reject, triggering consistently occurs for the 2MHz portion of the signal and even though we get multiple traces due to the superimposed 500kHz signal, triggering always happens pretty much at the same point of the 2MHz waveform, so all traces are nicely aligned with respect to the time axis (Trig_500kHz_2MHz_AC_LF-Reject).




With HF-Reject, triggering consistently occurs for the 500kHz portion of the signal and despite the multiple positive going edges at the trigger level, we get a steady picture with absolutely no horizontal jitter (Trig_500kHz_2MHz_AC_HF-Reject).




I obviously chose the two signal components to be close to the respective corner frequencies of the filters in the trigger path - in order to demonstrate the selectivity of the filtered triggering. In a more practical scenario, the interfering part of the signal is usually weaker and also further off the signal frequency most of the time.

Of course, these filters won’t help us if we want to trigger say on an audio signal with strong mains hum superimposed, as we would need a LF-Reject filter with e.g. 200Hz corner frequency for that. It would be a very nice feature if the corner frequencies were configurable, but I honestly don’t know if there are any scopes on the market that provide such a feature, as I’ve never paid attention to this before.

But there are scopes that have programmable input filters for their regular channels (even the old Rigol DS1054E has this) and with such a scope the desired frequency separation could easily be achieved by using one of the input channels with proper filter settings for triggering.


Conclusion:

The LF/HF-Reject trigger coupling work as expected, absolutely no complaints here. 

Yet there are programmable filters (LP, HP, BP, BS) for the input channels on the wishlist though, as this would be the ultimate aid in triggering/viewing difficult signals.


EDIT: Fixed some typos.

EDIT2: COrrection on AC trigger bandwith estimation.

[Performa01]

Trigger Types, Holdoff

As can be seen from the number of posts related to triggering, there’s certainly a lot to be looked at – and I’ve not even touched the area of triggering on digital channels or digital signals in general (also on analog channels) yet.

The time spent for reviewing the trigger system is well spent though, as it is the most important part of any oscilloscope. We just cannot seriously analyse any signal that we cannot get a stable triggering on.

While I’ve concentrated on continuous signals so far, now moving over to discontinuous (gated) signals is the next logical step.

For the following test I use a simple burst signal, 8 pulses 1µs wide with 1µs spacing, that is repeated every 40µs (Burst_Overview).




With the usual edge triggering, we cannot get a stable trigger point, as the scope just triggers on the next best rising edge – witch might be associated with any pulse within the packet, whereas we only want to trigger on the first one (Burst_Trig_Std).




This exact situation could be handled even with an analog scope, by using the trigger holdoff. The SDS2000 also has this, and as it’s a digital scope, we can set it to exact values. We just need to determine the total timespan of rising edges within the burst which is exactly 14µs and then setup the holdoff time equal or slightly longer than that. So I’ve set it to 14µs and magically triggering works as expected (this is how I got the first screenshot).

Rant:
Adjusting the holdoff time is a bit of a pain, as the response of the Select knob is very poor. It is too sensitive for slow movements, but also way too slow when turned faster. In short, both the initial sensitivity as well as the acceleration parameters are far from optimum. This has already been a lot better with the former V2 beta, but quite sadly returned to the painful V1 behaviour with the first official V2 release.

Now what if the burst repeats every 20µs, thus leaving less than a 14µs gap between pulse packets? Does holdoff still help in that situation? Quite surprisingly it does (Burst_Trig_Holdoff).




On a digital scope with a wide choice of trigger types (as the SDS2000) there are other ways to get a stable triggering on our burst signal without having to use holdoff – and as long as we have a well defined digital signal we would normally not use holdoff at all.

We could use the pulse width trigger and set the trigger condition to a negative pulse width exceeding 1µs for instance (Burst_Trig_Pulse).




The selection of trigger types is very nice and seems fairly complete to me (note that there is an additional menu item ‘Serial’ that only becomes visible when scrolling down the pop-up menu) and I particularly like the help screens that automatically pop up, explaining the basic functionality for any selected trigger type except Serial (where it isn’t really required anyway).
The help text even considers your actual setting regarding rising or falling slope, brilliant! 

It is much appreciated that each trigger type has its individual settings, so that you can set up different trigger types for the same signal and then switch between them without touching the parameters over and over again. Be aware that this also includes the channel selection – so when you change trigger type and fiddle with the settings to no avail, it’s most likely that you just missed that the trigger channel is back to the initial setting (Ch. 1), which might not be the channel you are actually working with.

For our little test, the Interval trigger could be used as well, if we set a range of >2µs for either the rising or falling edge (Burst_Trig_Interval).



In the help text, there should be a space between ‘rising’ and the parenthesis.


A very nice – and probably one of the most useful – trigger type, not usually available as a standard on many scopes (only after purchasing some ‘advanced Triggers’ bundle) is the Dropout trigger, which could also be called a timeout trigger, as it triggers at a specified time after the trigger condition has been met and state has not changed since then.

In this example, we can specify this in two ways:

1. State has to be low (setting: ‘Slope falling’) for more than 1µs - I've set it to 2µs (Burst_Trig_Dropout_State).




2. Edge (rising or falling) not detected for longer than 2µs - set to 2.05µs (Burst_Trig_Dropout_Edge).



In the help text, there should be a space between ‘rising’ and the parenthesis, but no space after ‘value’ and ‘lase’ should read ‘last’.

Note that the trigger point does not correspond with any edge in the Droput Trigger types, but happens ~2µs after the trigger condition has been met, i.e. level went low.


Conclusion:
I haven’t tested all possible trigger types, but so far everything worked just fine and I’m very impressed with the wide choice of really useful trigger types – including even video, which I assume not many will have a need for nowadays. But then again, one can never have too many choices when it comes to triggering of some weird signal. Well done, Siglent! 

EDIT: That said, the resposiveness of the 'Select' knob really needs to be addressed as it is just a pain to set time parameters to a higher value in the µs or even ms range, which is really tedious and can waste a lot of time.

EDIT2: Changed wording and some clarifications and additional explanations on Dropout trigger.

[tautech]

I’ve just upgraded to firmware SDS2000-V2.0-1.02.01.28R1 and will use that as a basis for any future reviews – until the next revision comes out, that is.

The update went well without problems, but the self cal after the restart would hang at 5% forever. After another restart it worked though, so I’m willing to look at this as just a glitch.

Have you seen this problem with the Self Cal again?

[Performa01]

@tautech

No I haven't. But that's no surprise, as I haven't done another FW-update since then.

I also haven't tried another self cal since my reply #79.

Siglent apparently already has found a way to reproduce the issue - it may have something to do with automatic measurements.

[9a4wy]

I’ve just upgraded to firmware SDS2000-V2.0-1.02.01.28R1 and will use that as a basis for any future reviews – until the next revision comes out, that is.

The update went well without problems, but the self cal after the restart would hang at 5% forever. After another restart it worked though, so I’m willing to look at this as just a glitch.

Have you seen this problem with the Self Cal again?

Mine did that once after FW upgrade(stuck at 0%) freezed...I had to restart it and then selfcal went well.
K

[Performa01]

Acquisition and Display

I thought I should take a closer look at the various combinations of acquisition and display settings.

For the following tests, I have channels 3 & 4 turned on, in order to limit the sample rate to 1GSa/s and make the test results valid for the universal case where all channels are in use (with twice the sample rate, results would be significantly better of course). I will only use channel 4 though, and channel 3 just sits there idling at the centre of the screen.

Test signal is a stable 300MHz 500mVrms sinewave, derived from an OCXO.

Let’s start with my preferred (default) settings:

Acquisition: Peak Detect, Sin(x)/x, Fast
Display: Dots

The screenshot shows a nice, clean and undistorted waveform. Even though there are only 14 samples available for the entire screen, the fast update rate of 6795Hz produces so many dots that this works almost like equivalent time sampling (Trace_Peak_Sinx_Fast_Dots).



If we assume that the display update rate is about 60Hz, then with fast acquisition we get about the following:

6795 waveforms per second x 14 samples per screen = 95130 samples per second. Don’t laugh. In ancient times, the ‘writing speed’ of digital scopes was actually specified that way!

95130 samples per second / 60 screens updates per second = 1585.5 dots per screen. Don’t ask where that half dot is hiding – I haven’t found it yet

Looking at the screenshot above, it could very well be that it contains that many dots and the result is – well, pretty similar to what we’d get with ETS (equivalent time sampling). So this might be an excuse why a scope with reasonable fast ‘writing speed’ doesn’t need ETS.


With slow acquisition mode, the waveform update rate drops to 27Hz and we just get a bunch of jumping – and barely visible – dots. We still get an undistorted waveform – which is of course not visible on the screenshot, where there are actually just 14 dots (Trace_Peak_Sinx_Slow_Dots).



The same calculation as before yields quite different results:
 
27 waveforms per second x 14 samples per screen = 378 samples per second.

We need not go any further – as the data is delivered at a slower rate than what the display can take, the result is pretty obvious. As long as we don’t have more than 60 waveforms per second, we cannot get more than just 14 dots per display screen update.


Now let’s go back to fast acquisition and turn on vector mode instead. Screen update rate is now back to 6795Hz and the displayed waveform gets brighter and has no gaps, but it also gets a little blurred – just like an analog CRO where the brightness has been turned up (too) high (Trace_Peak_Sinx_Fast_Vectors).



The blurriness doesn’t come from peak detect – it looks exactly the same in normal mode. It should be obvious that peak detect cannot make any difference in situations, where memory depth is just 14 samples and all the data make it to the screen anyway.

But we do see a hint of ghosting at certain parts, particularly of the positive halfwave.


Now let’s turn off the Sin(x)/x reconstruction filter (Trace_Peak_x_Fast_Vectors).



Yikes – that doesn’t look pretty, does it? And dot mode doesn’t make it a whole lot better either (Trace_Peak_x_Fast_Dots).



I think this is a clear demonstration, why we need a reconstruction filter whenever the digital capture of analog signals near the nyquist frequency is to be converted back into some meaningful representation of the original signal.


Ok, so let’s turn Sin(x)/x back on and switch to slow acquisition, hence try our second setting again – but this time in vector mode:(Trace_Peak_Sinx_Slow_Vectors):



What we can see on the screenshot is a slightly distorted sinewave. What we cannot see is the ‘jumpiness’ of that waveform. Even display persistence does not help to make this effect visible, as for some strange reason the persistence doesn’t make it to the screenshot picture.

However, what happens here is that at a screen update rate of just 27Hz, the phase of the samples (thus the position of the dots) changes all the time and quite obviously the reconstruction filter isn’t perfect as it fails to produce the same results for different phasing.
I’m not an expert on digital signal processing, but my guess is that a reconstruction filter cannot be error-free if not only time but also signal level is quantised. As level quantisation is low resolution (8 bits) on top of that, a sin(x)/x reconstruction just cannot give accurate results. So I don’t consider this a flaw in the firmware, it’s just in the nature of the beast

In Dots mode, this error is far less obvious, but that’s not an option anyway as signal analysis would be very difficult with just 14 jumping dots on the screen

Hopefully I could demonstrate why I have chosen my favourite default settings just as shown at the start of this posting.

[Performa01]

Display Persistence

This usually works as expected, but I’ve still found two errors.

One of them has already been mentioned in my last post. The jumpy trace in the ‘Trace_Peak_Sinx_Slow_Vectors’ screenshot left a narrow shadow on the screen due to persistence mode, but the corresponding screenshot didn’t show that at all.

Just to make sure screenshots normally do show the persistence, I turned some modulation on and took another screenshot (Persistence_Test):




The second bug is that the ‘Display’ button toggles the persistence mode when the display menu is already displayed. So if for instance the Acquire menu is shown, I hit ‘Display’ in order to switch to the display menu, and this works as expected. But if I accidentally hit ‘Display’ again, the persistence mode changes from ‘Off’ to some random value (presumably the last one used before turning persistence off). Pushing ‘Display‘ one more time turns persistence back off again and so on.

[9a4wy]

first picture....ROLL MODE

second picture...ROLL MODE with measure function switched on

sometimes ROLL mode stops after "one screen aquisition"

new findings.....THIS HAPPENS ONLY ON CH3 AND CH4

this problem is still here in new FW...
K

[rf-loop]

The second bug is that the ‘Display’ button toggles the persistence mode when the display menu is already displayed. So if for instance the Acquire menu is shown, I hit ‘Display’ in order to switch to the display menu, and this works as expected. But if I accidentally hit ‘Display’ again, the persistence mode changes from ‘Off’ to some random value (presumably the last one used before turning persistence off). Pushing ‘Display‘ one more time turns persistence back off again and so on.

Is this useful feature really "bug"?  If it need some finishing this is other case but it, as some other shortcuts are welcome. (it is possible that SDS2000X FW is not optimally personalized to SDS2000 front panel - and also different users have different learning history from many different equipments so adaptation may take some time before learn optimal way to use UI)
Also it do not jump to "random" persistence time  or least I have not seen any randoms. It jump to what user have previously selected(as also your presumption) . This feature jump between on/off this preset persistence. But, of course different peoples feels different depemnding how they use scope. 
Personally I use often persistence on and off, so it is handy, just on/off with one button, without need frequently go through menu selections.

[Performa01]

Is this useful feature really "bug"?

Well, at least it is somewhat unexpected and not documented. At least not in the SDS2000 Users Manual - and I don't have any V2 FW documentation.

Even though I already wondered if this might be a feature – and I'm willing to accept it as just that, it might still be debatable. I for one didn't particularly appreciate persistence mode turning on and off randomly (as it appeared to me) when I had to switch between acquisition and display menus numerous times while performing my tests.

Granted, knowing about that shortcut makes all the difference, but then again it seems to be the only menu button that has such an extra functionality. So it isn’t nearly as consistent as i.e. the shortcuts provided by the knobs that include a pushbutton.

[tautech]

Is this useful feature really "bug"?

Well, at least it is somewhat unexpected and not documented. At least not in the SDS2000 Users Manual - and I don't have any V2 FW documentation.

Even though I already wondered if this might be a feature – and I'm willing to accept it as just that, it might still be debatable. I for one didn't particularly appreciate persistence mode turning on and off randomly (as it appeared to me) when I had to switch between acquisition and display menus numerous times while performing my tests.

Granted, knowing about that shortcut makes all the difference, but then again it seems to be the only menu button that has such an extra functionality. So it isn’t nearly as consistent as i.e. the shortcuts provided by the knobs that include a pushbutton.

It is one of the "shortcut" features that have been added with V2 FW, first mentioned with the release of the SDS1000X series and expressed by the blue arrows next to the selection button.
Of course the SDS2000 won't have these arrows but the newer SDS2000X HW does.

From the SDS2000X web page: http://www.siglent.com/ENs/prodcut-detailxx.aspx?id=1243&tid=1&T=2

10 types of one-button shortcuts, including Auto Setup, Default, Cursors, Measure, Roll, History, Display/Persist, Clear Sweeps, Zoom and Print

These shortcuts are enabled/disabled by toggling each specific button but just a single press enables each one's menu.





IMO there should be a short description in the manuals of how to operate the "shortcut" keys along with a brief description of exactly what each key does when toggled.

Siglent will be updating the SDS2000 series datasheet and manuals to include the changes brought with V2 FW. Yes, I've asked. 

[Performa01]

XY Display

On analog scopes, X-Y mode was straightforward. Just make sure that you have the right gain settings for the respective channels, that’s it. No worries about the timebase, as this was completely inoperative and irrelevant in X-Y mode.

Now I have to admit that I’ve never used X-Y mode on a digital scope before. Even with analog scopes, I used two channel Y-t mode to determine phase relationship between signals rather than X-Y mode Lissajous figures. And I’ve also long left behind the days where a scope in X-Y mode had to serve as a display unit for some homebrew gear. So I had to find out first how to do it on a digital scope when I decided to give it a try on the SDS2000…

That also means that I don’t know if there are any differences between V1 and V2 FW at all.

First thing to mention there is some redundancy, as we can select X-Y mode in the Horizontal menu (that was expected) and also in the Acquisition menu – I would rather have supposed to find it in the Display menu, as I don’t consider it to be a special acquisition mode.

But in some sense it is, as the memory is once again limited to 14k, and this time the other memory options are not just greyed out, but not even there at all. That once again means we have to carefully adjust our signals so that the screen shows at least one full period of each signal involved and no aliasing occurs (XY_Signals_2).



This step is necessary as X-Y mode can only work with the data captured in Y-t mode, that is clearly active in the background even when in X-Y mode. So this is a big difference to analog scopes, where we didn’t need to worry about timebase settings at all when in X-Y mode.

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):



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



Waveform update rate for the above tests was close to 4000Hz, so as a display unit, the SDS2000 would be just as responsive as any old CRO. And as I think X-Y mode is very special and will not see much use anyway, I don’t even complain about the memory limitation either.

Conclusion: X-Y mode is different to analog – a trap more for old- than young-players, I guess – and I think it works just fine on the SDS2000.