Siglent SDS2000 new V2 Firmware

[rf-loop]

Limiting memory depth do not reduce noise. All noise is still there. ...
With slow update mode, we just only reduce collected data. ...

Nobody has claimed anything else. I thought it was clear that we were just talking about visible (perceived) noise on the screen.

Yes, and sorry, only add for many other readers (not for you) due to fact that things around DSO signal "noise(s)" have so much commonly misunderstooded.

When look offset drift with 2 - 5mV/div it need also note auto-cal function and if it is enabled, it some times do automatically offset corrections.

Ok, I've never tried auto-cal. yet. Should definitely give it a try next weekend, even though I am a bit skeptical that auto-cal. can do some additional magic when self-cal. has failed already.
As I've mentioned before, the offset error is tiny and absolutely insignificant at 2mV/div, whereas it gets quite large on some channels at 1mV/div and changes sign on top of that. Almost looks like the firmware just multiplies the RAW ADC values by 2 without taking the offset correction value into account (that is clearly in effect at 2mV/div, as there is barely any offset error visible).

Siglent autocal is perhaps not yet fully mature and not well finished.  (I have not tested official V2 FW)

I have not tested added 1mV/div at all.
 
Also I do not know if HW solution for 1mV/div is exatly same in SDS2000X and SDS2000.

In analog front end + ADC there is perhaps some differencies.

Perhaps your suspect about offset correction "bug" is right. 

IF SDS2000 new FW is just modification from SDS2000X FW for SDS2000 different HW, then many things are possible.

[Performa01]

I have not tested added 1mV/div at all.
 
Also I do not know if HW solution for 1mV/div is exatly same in SDS2000X and SDS2000.

In analog front end + ADC there is perhaps some differencies.

Perhaps your suspect about offset correction "bug" is right. 

IF SDS2000 new FW is just modification from SDS2000X FW for SDS2000 different HW, then many things are possible.

Oh - seems like I've missed something there. Did not know about a new SDS2000X.
So is this a new HW-revision?
Does it actually exist somewhere (obviously not in Europe yet)?
Does it mean I already have some outdated piece of gear by now? 

[tautech]

Yes the 2000X does exist, one was shown to Dave yesterday and they appeared on the Siglent websites on Nov 30.

[timofonic]

Yes the 2000X does exist, one was shown to Dave yesterday and they appeared on the Siglent websites on Nov 30.

What are the differences?

[tautech]

Yes the 2000X does exist, one was shown to Dave yesterday and they appeared on the Siglent websites on Nov 30.

What are the differences?

See first page in this thread:https://www.eevblog.com/forum/testgear/siglent's-new-product-sds2000x-series/
And link to recently released data sheet ~p3 or 4.

[cidcorp]

Does it mean I already have some outdated piece of gear by now? 

Along those lines, I'm still curious if this SDS2000X will be replacing the SDS2000 models, or is this to
be similar to the Rigol DS1000Z vs DS2000 (co-existing, but different).  From what I see there aren't enough
differences in the new 'X' model for them to co-exist.

As long as any improvements/fixes on the new SDS2000X firmware (over time) get trickled down to my SDS2000, I'm happy.

Chris

[tautech]

Does it mean I already have some outdated piece of gear by now? 

Along those lines, I'm still curious if this SDS2000X will be replacing the SDS2000 models, or is this to
be similar to the Rigol DS1000Z vs DS2000 (co-existing, but different).  From what I see there aren't enough
differences in the new 'X' model for them to co-exist.

As long as any improvements/fixes on the new SDS2000X firmware (over time) get trickled down to my SDS2000, I'm happy.

Chris

Distributors have know this HW revision of the SDS2000 series has been planned for some time, although there have been a few pleasant surprises by it being released as another X series product along with the move to a 16 channel MSO and the new V2 FW that has I believe taken a year in development and unleased further enhancement of the existing HW well beyond the advertised specs of when these DPO's were first released. That the new V2 FW and UI can also be shared with the existing 2000 series will be of great benefit to current SDS2000 owners as it seems more stable and vastly more bug free.
The price we've had to pay has been slow V1 FW development but hopefully that should be behind us with 3 series of DSO's now using similar FW.
So yes cidcorp I'd be surprised too if both series coexist, although we'd expect developments and bug fixes to benefit all models that share V2 FW or variants of it.

[9a4wy]

I can find weird things on the screen in ROLL mode and measure function switched on...

[tautech]

I can find weird things on the screen in ROLL mode and measure function switched on...

Please don't be scared to share them with as much detail as you can manage.

[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

[Performa01]

Offset Problem at 1mV/Div:

Here is a more detailed demonstration of the problem.

The scope was running for >12 hours and a self-cal has been performed about 2 hours after power on. Quick-cal is also turned on, but that apparently only kicks in on major vertical gain changes and doesn’t affect offset at all.

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

Screenshots including cursor measurements to show the offset distribution are provided for the situations listed below.

Offset_2mV_2:
Run mode, all channels set to 2mV/div, then stopped and adjusted the cursors in Y2-Y1 mode. Difference in offset voltage between all channels is 480µV, which I consider quite acceptable.



Offset_2mV_zoom:
In stop mode the vertical gain was changed to 1mV/div for all channels, i.e. a vertical zoom after the acquisition. The result is exactly what is to be expected, the visual offset doubles, but the difference remains the same in terms of absolute voltage, i.e. 480µV.



Offset_1mV:
Run mode, all channels set to 1mV/div, then stopped and adjusted the cursors in Y2-Y1 mode. Difference in offset voltage between all channels is now 1mV, which is double the amount we have seen before. This is clearly a bug, as the absolute offset cannot change regardless of the vertical gain. The expected behaviour would have been exactly the same as with the vertical zoom in the 2nd step of this test sequence.

[Performa01]

Frequency Response:

Even though not normally a firmware topic, since to the best of my knowledge nothing has been published about this before, I thought I’d share some test results for the frequency response of the SDS 2304.

I’ve tested all vertical gain settings in the range 1mV/div to 500mV/div at a peak to peak level of roughly 80% of the screen height. The signal generator was connected directly to the scope input via 1m of RG58 coaxial cable and internal 50 ohms termination was used, which, by the way, gives far superior results compared with a traditional external 500MHz pass through terminator.

The attached images show the test results.

Frequency_Response:
Amplitude accuracy is generally quite good at <1% error at 10MHz, except for the new 1mV range which is a little on the high side.

-3dB bandwidth is well within spec. ranging from 320MHz at 100mV/div up to 353MHz at 500mV/div.

Of course these test results are just exemplary to give an idea what can be expected. In practice, all four channels behave slightly different and even bigger differences between individual scopes can be expected.



F_Response_Limit:
The internal bandwidth limiter was just exemplary tested for 50mV/div as there are no significant differences to expect between various gain settings. The measured bandwidth was 20.9MHz and the attenuation increases quite nicely up to at least 300MHz (not tested beyond that, as the signal was pretty much a straight line already).



As a conclusion, I could not find any flaws regarding bandwidth, except maybe the lack of ETS (equivalent time sampling). Even so, this scope is clearly capable to handle frequencies up to the specified bandwidth even when all four channels are in use (hence the sample rate is limited to 1GSa/s). This wasn’t quite true for the initial V1 firmware and so this is indeed a firmware related improvement and should therefore fit the topic of this thread.

[Performa01]

Peak Detect:/Roll Mode

One of the announced improvements for the V2 FW is peak detect acquisition mode now working. Well, to be honest, I thought it already worked (kind of) with V1, but then again, I did not test it thoroughly back then, particularly not in roll mode, as I rarely ever need timebases that slow. But today I decided to take a closer look.

This is by the way one occasion, where vector display mode is useful (other than what I’ve stated before) to aid visibility. This generally applies for situations, where we’d also need to turn up the brightness of an analog scope full throttle in order to see anything (if at all) on the screen

Attached screenshots document my findings.


PeakDetect_10ns:
This is what the test pulse looks like. It is a positive 4.72V high and 4.1ns wide pulse with a repetition rate of about 65ms. Rise- and fall times are both 2.2ns.



PeakDetect_10ms:
For this test, the scope memory depth was set to 70Mpts. Timebase setting was 10ms/div. Despite vector mode, the narrow pulses are barely visible, particularly the one on the trigger point at the center of the screen, obscured by the graticule. One really needs to look close – but they are there. Intensity level was set to 50%.

Note that sample rate has dropped to just 500MSa/s and automatic time domain measurements show nonsense (as is to be expected, when we can get just one single sample for each pulse). Nevertheless, all pulses are reliably captured and steadily displayed, other than in normal mode, so peak detection clearly works as it should here.



PeakDetect_100ms_Roll:
Same situation as above, but now the timebase was set to 100ms/div and roll mode has kicked in automatically. The visibility of the pulses is a bit better, as there are now more on the screen and surprisingly, they are all there (remember, the repetition rate is about 65ms). Sometimes one pulse could get missing in the screenshot though, but that happens just when the ‘Print’ button is hit. In general, changing any settings during acquisition may cause missing pulses, which shouldn’t be a problem for most of us, who – other than Dave – don’t permanently change settings while observing a signal on any instrument.



Somehow we get ghost images now, which were to be expected on a noisy signal, where we just see the extreme levels in peak detect mode. In normal acquisition mode, the signal doesn’t appear that noisy and at 10ms/div, we did get double lines too, but they were close together and far less striking.

The sample rate has dramatically dropped down to 2MSa/s. There is a huge drop between 20ms/div (250MSa/s) and 50ms/s (where roll mode kicks in, 4MSa/s). At the same time, recording length drops to 2.8 Mpts, which remains constant for all timebases slower than 20ms/div when in roll mode. For instance, the slowest setting possible is 50s/div with 4kSa/s and still 2.8Mpts of memory.

Automatic measurements are gone, which seems to confirm an objection recently raised in this thread.

The main thing is: despite the low sample rate, we don’t lose any pulses. There is a line every 65ms and that represents the real situation quite nicely.


PeakDetect_100ms:
Even though roll mode automatically kicks in at 50ms/div, we can still force the scope to do a normal y-t acquisition using the “Horizontal’ menu.



As can be seen, the ghosting has completely vanished on the sync signal (Ch. 2) and is far less pronounced on the main channel 4 now.
So the ghosting appears to be mainly an undesirable ‘feature’ of the roll mode. But then again, with V1 FW, peak detect mode has generally been very prone to produce ghost images, so we can see a clear advantage here.

Automatic measurements show even more nonsense, at least it’s consistent with the timebase setting, as the times are an order of magnitude longer compared with the 10ms/div capture.


PeakDetect_1s_Roll:
Just for kicks I also tried 1s/div in roll mode. Sample rate is a meagre 200kSa/s now and ghosting is bad as always, but all the pulses are still there.




Conclusion:
Peak detect mode works quite nicely in general. The observed flaws are either inevitable (the nonsense results from the automatic time measurements at slow timebases) or something, one should be able to live with (the ghosting issue - which isn't actually a flaw after all).
The problem with automatic measurements disappearing in roll mode is not related to peak detect and is considered a serious bug though.

EDIT: For all timebase settings that result in sample rates < 1GSa/s, the reason why we can still see pulses is because of the glitch capture feature – peak detect alone would not help in these situations.
Also the double lines (‘ghost images’) are caused by the combined effect of glitch capture together with peak detect and get worse with decreasing effective sample rate. As the sample rate drops dramatically in roll mode, this explains why this effect is so striking there.

[Performa01]

Intensity Grading:
With V1 FW, intensity grading did not work too well in many situations. This has been improved radically with V2.

The scope was fed with two signals:
Ch.4 is a 500mVrms / 10MHz sinewave, 100% amplitude modulated with 1kHz sine.
Ch.2 is the sync signal that correlates with the zero-crossings of the modulation signal.

An amplitude modulated signal can be displayed in two ways and the attached screenshots show the test results for both.

IntensityGrade_LF:
The scope is triggered from the modulation signal (1kHz) – in this particular test setup it is the sync signal fed into Ch. 2.
Waveform update rate is only 4.5 per second in this scenario, due to the relatively slow timebase and complex signal. At least by now we should get suspicious about claims that a high waveform update rate is required to get a nice intensity graded display…




IntensityGrade_HF:
The scope is triggered from the carrier (10MHz) and the sync signal appears out of sync
Waveform update rate is now 32k per second and the displayed result depends on the trigger settings. Here the trigger level is 78mV and has been manually tweaked to give a nice looking picture.




IntensityGrade_HF_Auto:
Same scenario as above, but with auto trigger level (by pushing the trigger level knob). This results in a trigger level of 4mV and the picture looks less smooth. Thanks to a working intensity grading we can make a guess though, that we’re capturing certain amplitude levels more frequently than others.



Maybe this is a good place to (once again) praise the trigger system of this scope. How many scopes have we seen so far, that are capable of providing a rock-stable triggering on a 100% amplitude modulated signal at pretty much any trigger level we desire, and even auto trigger level works a treat?


IntensityGrade_HF_Color:
Same as above, but this time with color graded display. As someone who has used analog scopes for decades, I cannot appreciate this approach and intensity grading has much more appeal to me.




Conclusion:
Other than with V1 FW, Intensity grading works great on this scope now and gives me all the information I could ask for. As a side note, the rock-stable trigger system was both a great help and a joy to use for this test.

[tautech]

@Performa01
Thanks very much for taking the time and trouble to go through the V2 FW in this way. 
It reads much better coming from you. 

You could make it even better to read if you did an "Insert Image" and pasted the uploaded image's URL's  between each block of text. You will have to copy the image URL first and use the "Modify" but it will look tops if you want to go to the trouble.
To see the syntax used "Quote" somebody elses post that has embedded images.

[Performa01]

Acquisition modes:
Even though at a first glance, only ‘HiRes’ has been replaced by ‘eRes’, almost everything has changed in this area, compared with earlier firmware versions, except normal mode maybe.
Since peak detect mode has been reviewed already, I thought I’d concentrate on the average and eRes modes. But then I found so many flaws in this area that I thought the entire menu deserved a dedicated post – dedicated on its general bugs alone, that is.

Bug #1: Trace disappears
This already has been mentioned before and is clearly to do with the 'Acquire' menu, particularly with the acquisition mode. Sometimes, when altering the acquisition mode, the trace disappears. Again, sometimes it can be brought back by just turning the corresponding vertical gain knob one notch – but most of the time this doesn’t help either. Then it is necessary to alter the acquisition mode again, to bring the trace and the acquisition system back to live.

Bug #2: Residual trace garbage on the screen
When switching from normal to average acquisition mode, some trace residues suddenly appeared. See attached screenshot ‘ResidualTrace_01’, where the residue can be seen in blue color.



When switching back to normal mode, the residues would go away, but reappear as soon as I select average mode again.
The probable cause was Ch. 2 that I had used before and switched off in the meantime. Turning Ch.2 on revealed that there was still an old acquisition stored, even though the scope has done a lot of acquisitions witch Ch. 2 turned off since then. See attachment ‘Residual_Trace_02’.



Turning Ch.2 on and off several times finally deleted the trace residues from the screen.
Note that the trace residue was in blue, later on also in grey, whereas Ch.2 is originally pink.


EDIT: Even later on, (other) residues from Ch. 2 would appear whenever I open the ‘Averages’ menu in average mode or the ’Enhance by bits’ menu in eRes mode. It’s now mostly single dots and the color is yellow for a change. What’s even weirder, trace residues have become part of the selection menu itself (in some dark color) – and these consequently disappear together with the menu. Again, turning Ch. 2 on and off deletes the residues on the screen, but not in the menu, where they seem to be permanently burned in. See attached image 'Menu_Residual', where a dark line crosses the 1.0 setting for the resolution enhancement.



Bug #3: Clear Screen doesn’t work
While battling with the trace residues I thought “hey, didn’t I see a ‘Clear Display’ button in the ‘Display’ menu? Let’s try that!”
Well, what can I say – this button does absolutely nothing. Tried the online help and it stated that this button was to clear the waveform on the screen. But it did nothing. In stop mode, it did neither clear the current trace nor the trace residues.

EDIT: See attachment 'Clear_Display'

[Performa01]

Average & Eres Acquisition Modes:

These are the mystery modes, as they both do something, and they are different, but especially eRes (Eres in the menu, but somehow I cannot get used to this form) does not meet my expectations at all.

Common  oddities for both average and eRes acquisition modes:

Memory depth is limited to 7/14k when either Average or eRes is selected and the original setting is not restored when acquisition mode is switched back to normal or peak detect. At the same time, Fast acquisition mode becomes ineffective, i.e. we can still toggle between ‘Slow’ and ‘Fast’, but the waveform update rate is limited to <10 either way, and the timebase setting doesn’t have any noticeable effect as well.

The big question here is: WHY?
I’ll discuss this later, as I want to summarize my findings first.

Average mode does not reduce the bandwidth, but significantly slows down the response time for displaying signal variations, as can be demonstrated by the first two screenshots.

First (Normal_BW_50ns_2) shows the test signals in normal acquisition mode.
Ch. 2 is fed with a steady squarewave, 2Vpp, 10MHz.
Ch. 4 is a 500mVrms / 10MHz sinewave, 100% amplitude modulated with 1kHz sine.
The display is in dot mode.




Second (Avg_BW_50ns_2) shows the same signals in averaging mode, with the number of averages of just 4.




What strikes immediately is the strong noise reduction effect, which becomes even more evident in dot mode, as shown here.
Other than that, the squarewave isn’t affected at all, whereas the sinewave on Ch. 4 has just a random amplitude somewhere between zero and two times the unmodulated magnitude, depending on the time of the screen capture. In other words, the display can’t follow the modulation anymore. Instead we get random amplitudes within the modulation range at a screen update rate of about 8.9 per second (but visual changes appear much slower).

Even though this test was done at only 10MHz, just believe me when I say that the bandwidth is not affected by the averaging. A steady state 300MHz sinewave has the same amplitude on the screen, no matter if we use normal, peak-detect or average acquisition mode.


The third attachment (Eres_BW_50ns_2) shows a very similar picture for eRes. The main difference is that the displayed variation of the modulated signal is considerably faster, even though a high resolution enhancement of 2.5bits was set and the screen update rate was still only 8.9 per second.




In contrast to average mode, eRes does affect bandwidth, and as expected, the effect depends on the number of bits set for the resolution enhancement and sample rate. The maximum number of bits of resolution enhancement available depends on the timebase setting, according to the following list:


Timebase   Max. number of bits for resolution enhancement
<5ns       1.0
<20ns      1.5
<50ns      2.0
<500ns     2.5
>200ns     3.0   

For 2GSa/s, the bandwidth is affected by the resolution enhancement in the following way:


eRes bits   Frequency   Attenuation
0.5         300 MHz     -1 dB
1.0         212 MHz     -3 dB
1.0         115 MHz     -1 dB
1.5         105 MHz     -3 dB
1.5         45 MHz      -1 dB
2.0         52 MHz      -3 dB
2.0         28 MHz      -1 dB
2.5         26 MHz      -3 dB
2.5         15 MHz      -1 dB
3.0         13.5 MHz    -3 dB
3.0         8 MHz       -1 dB

CAUTION: The table shown above is only valid for a sample rate of 2GSa/s!

Because the memory is limited to just 7/14k, sample rate drops very quickly for slower timebase settings. 2Gsa/s can only be achieved in interleaved mode for timebases of 500ns/div and faster.
There is a linear relationship between sample rate and eRes bandwidth. Based on the table above, half the sample rate (1GSa/s) would mean half the bandwidth, i.e. just 4MHz for -1dB error at 3 bits of resolution enhancement. In the same scenario it would be only 800kHz for a sample rate of 200MSa/s.


Resolution enhancement.
Both Average and eRes use some form of averaging, so a resolution enhancement could be expected for both modes. To verify this, I’ve applied just a triangle wave, see attachment ‘Resolution_TestSig’.




It is a 100kHz ramp with a peak to peak amplitude slightly higher than the screen. I then switched to the AMUT (Acquisition Mode under Test ), hit the Stop button and zoomed in vertically ten times (by turning the vertical gain down to 10mV/div). In dot mode (as most of the time) I thought I could just count the dots per division in order to determine the resolution.

As we already know, in normal mode we have 25 dots/division, so when zoomed in 10 times we expect so see 5 dots per 2 divisions, see attachment ‘Norm_Zoom_x10’.




Yes – that’s exactly what we see. So we know there are 200 points per screen height in normal (and peak detect) acquisition modes.

Now let’s take a look at attachment ‘Avg_Zoom_x10’.




Please ignore the blue residual trace that I’ve already covered in a previous post.
Sadly, nothing has changed at all. Despite 64 averages have been set, which could give a theoretical resolution enhancement of 6 bits *), we see absolutely nothing. Oh well, quite obviously, the average mode is just meant for noise reduction and the extra resolution is deliberately thrown away.

But now we take a look at the eRes mode, which carries the words ‘enhanced’ and ‘resolution’ in it’s name already – we sure would see the promised increased resolution of 2.5 bits, that I’ve set for this test, wouldn't we? Unfortunately, attachment ‘Eres_Zoom_x10’ only shows some residual trace, but not the slightest improvement in terms of resolution at all.




Discussion.

There are a number of oddities with these two modes and they don’t quite meet the expectations.
I understand that average mode just takes an average of the specified number of subsequent acquisitions. I don’t know what the idea behind eRes is, but it appears obvious to me that it is some form of averaging within a single acquisition, which in turn acts as a lowpass filter. If I were to implement such an acquisition mode, I would make it a moving average over up to at least 64 subsequent samples (for 3 bits of resolution enhancement).


Question #1: Why is memory limited to just 7/14kpts?

In Average mode, if it’s a segment-wise averaging, we just need an accumulator for each sample and since the maximum number of averages is 1024 (who the hell will ever use that many?), we need 18 bits per sample. In practice this would be 24 or even 32 bits. Okay, this would eat up 3 to 4 times the original sample memory, consequently the size would decrease to 1/5 at worst, but this is still several Mpts.
If average mode uses a moving average of several acquisitions – well, for an averaging of 1024 this would divide our memory by that number, but we’d still get 14k/28k and the maximum record length should increase accordingly when we select a lower number of averages.

In eRes mode, we are working within the normal acquisition buffer, so virtually no additional memory should be necessary at all.

All in all, it is no fun to work with just 7/14k, as we run into aliasing problems all the time and almost lose the ability to zoom into a waveform – in short, we feel reminded of all the barely usable scopes in the past (and even today) where manufacturers held the view that users generally should make do with tiny sample memories.


Question #2: Why is no hardware acceleration available?

Well, there’s lots of calculations with lots of data and if the hardware isn’t designed to support these operations right from the start, it might indeed not be possible to implement that as an afterthought. And yes, I think we really can live without fast waveform update rates in these special cases where we need extremely low noise and or high resolution. It’s just the combination of no hardware support and no memory, that leaves the uneasy feeling of a firmware leftover from some ancient entry-level scope that has had neither the one nor the other in the first place.


Question #3: Why does eRes not enhance the resolution?

As stated before, average mode could show a resolution enhancement already, but ok, since it doesn’t promise anything like that, we have to accept when it is just a means for noise reduction.

eRes, on the other hand, carries the promise in its name already and the corresponding parameter is the Resolution Enhancement in bits. What is the use of an acquisition mode, that takes away hardware support, hence speed, takes away all the memory, takes away bandwidth, with no benefit other than a noise reduction for non-periodic waveforms? A DSP lowpass filter with configurable roll-off for the input channels would do a better job for this, as we would immediately know the bandwidth limit instead of having to calculate it based on the sample rate and number of bits of alleged resolution enhancement.

I’m sure, the extra resolution is there originally, but somehow gets lost at some point on its way to the screen.


Question #4: Why does memory depth stay at 7/14k when we switch back to normal mode?

If (sad enough) the memory is limited to 7/14k for the averaging and eRes modes, it would be very much appreciated if it would return to its original value when we switch back to normal or peak detect. As it is now, we have set the memory to say 28Mpts and then switch to average mode for a short period of time. When we go back, the memory size stays at 14k and we need to access the memory size menu once again to wind it up, which is rather annoying.


Conclusion:
As it is now, Average Mode could be useful if we want to remove noise or calm down an unstable signal. It would be much more useful, if we had a little more memory available though.

As far as the eRes mode is concerned, I’m sorry to admit that in the way it is implemented right now I cannot think of too many useful application for it, other than noise reduction for non-periodic waveforms, where the sample rate dependant roll-off has to be estimated separately for each combination of ‘resolution enhancement’ and timebase setting. The latter once again due to the lack of memory.

EDIT: Clarification and additional info on eRes bandwidth limiting.
EDIT2: Typo correction, 800kHz instead of 500kHz for 200MSa/s and 3 bits eRes.

EDIT3:
*) Theoretical, two averages would increase the resolution by two as well – but only under very special conditions, for a ramp signal with well defined amplitude and frequency synchronous to the sample rate superimposed on the input signal.
In practice, we have just random noise available, so in order to get a sufficient statistical probability for the averaging result actually being close to the actual intermediate value, for a resolution enhancement of factor N, we need to have N² averages for boxcar and moving average filters and it could be even more for FIR filters optimized for a particular response characteristics.
We also need this many averages in order to increase the signal to noise ratio to a point, where the additional resolution can be exploited in practice.

[nctnico]

Is there no way to increase the memory size in Eres/average mode? It seems so silly to me that the memory is limited to 7kpts/14kpts. I have never used a scope which had that limitation.

[Performa01]

Memory Menu.

As I failed to show the memory menu in my last (already long) post, and people who don’t have such a scope might be interested what the memory menu has to offer in general, here are some screenshots.

Avg_Mem: memory options for average mode (all greyed out -> none  )
Eres_Mem: memory options for eRes mode (all greyed out -> none  )
Norm_Mem: memory options for normal mode (plenty  )







EDIT: As we can see in the first two screenshots, the residual trace has become part of the memory selection menu as well…

[nctnico]

    

[Performa01]

Measurement Menu

The automatic measurements are fine in general and I love them very much. I haven’t tried them all yet, but the ones I have used did a reliable job and gave me reasonable accurate results.

I very much appreciate the complete choice of input sources that include the math channel and even four reference waveforms, and also the broad range of measurement types, particularly the channel delay measurements.

There is a maximum of five measurements that can be displayed at the same time and of course they can be for different channels (Auto_Measurements, Auto_Measurements_Setup_Ch2, Auto_Measurements_Setup_Ch4).








On top of that, we can have all measurements specific to one channel (thus excluding the channel delay measurements, as they require a channel group) at once in an overlay window (All_Measurements_Ch4).




That works for one channel only, i.e. we cannot have more than one such window at the same time, but we can switch the input source anytime and the overlay contents switches accordingly (All_Measurements_Ch2).




Now let’s concentrate on the specifically selected measurements that are displayed on the bottom line right above the soft menu bar. For these we can also turn statistics on and get another overlay that displays all the statistical data (All_Meas_plus_Stat).




With all these goodies turned on, the instrument really looks quite scientific, doesn’t it?

What if we change our mind and want different measurements to be displayed? Well, we can uncheck the measurements no longer needed and select some others, of course. But lazy as we are, that’s not the way we are used to do it. We rather just select the new ones and expect the oldest selections to get unchecked automatically. This works – most of the time.

Suddenly I got into a state, where the selections in the ‘Type’ menu and the actually active measurements did not match any more. There are measurements selected that aren’t actually displayed and I would have to uncheck them to make them active – and vice versa. Attached there are three examples for this (Measurement_Mess_01 – 03):








It seems to be a common concept with this scope to speed things up by just processing differences, but in certain situations firmware loses track of the current state. We already saw this with channel traces disappearing when cycling through the acquisition mode menu, and we have it here with the automatic measurement type selection.

After I found this bug, I tried hard to find a way to reproduce it, but to no avail. I assume that it happens _sometimes_ when new measurement types are added (and we expect older ones to get deselected automatically), particularly when measurements for more than one channel are involved.

[Performa01]

FFT

FFT measurement was barely usable with V1 FW, at the very least it was very difficult to operate. The usability has been dramatically improved with V2. But is it also useful?

In general, we cannot expect to get a really useful spectrum analysis with just 8 bits of resolution. Even with an ideal ADC (and everything else ideal as well), the dynamic range is limited to less than 50dB, and in a real implementation, it’s more like 45dB. While this could fit several undemanding tasks, it is one of the reasons why a scope never can replace a real spectrum analyzer, where even the cheapest entry level units offer dynamic ranges in excess of 65dB.

On the other hand, a few dB of additional dynamic range can be squeezed out of even just 8 bits, when resolution enhancement techniques are applied. Let’s see what we get…

For FFT, vector display mode is to be used in order to get a readable spectrum display.
As window function, ‘Rectangular’ is pretty much useless, so we want to use one of the remaining three (Hanning, Hamming, Blackman). For the following examples, Hanning and Blackman have been used.

Since we always want a logarithmic display for spectrum analysis, I did not bother with the ‘Vrms’ units and set up a ‘dBVrms’ display right from the start. The horizontal scale ‘Hz/div’ was set one notch down from maximum, so we get as much information as possible without wasting any screen space (at maximum, only 10 horizontal divisions are used). In this setting the total bandwidth is 10kHz, of which 7kHz are displayed on the screen.
Vertical scale is set to 10dBV, which appears to be a convenient figure.
Signal source is a 1kHz sinewave at 1Vrms on channel 4. Please ignore channel 2, which carries just a sync signal and is not used for FFT. It is not possible to have FFT analysis on more than one channel at the same time, btw.

Just for kicks I’ve also set up an automatic measurement for the maximum level in the spectrum display (Vmax[M] in white color). Other than that, this scope doesn’t provide any assistance for signal analysis, as any modern spectrum analyser would. So we only can display the maximum amplitude, but not the corresponding frequency and there are also no computations for distortion or signal to noise ratio and the like.



As can be seen from the screenshot (FFT_1kHz_0dB_10dBV), the level measurement displays 0.00dBV, which should be right. But we see two spurious signals at 4 and 6 kHz, both just about 25dB below our signal. This doesn’t seem quite right, as the harmonic distortion of my signal generator is supposed to be better than -50dB. Let’s ignore that for the moment.


Just for fun,  let’s try to zoom in vertically, say 5dBV per division. Ooops … what happened to our maximum level measurement? We still see our signal at the reference level of 0dBV, whereas -200dBV would be way below the noise floor (FFT_1kHz_0dB_5dBV). BUG alarm!




Appart from that, it’s quite obvious that we waste half of the screen area (I am using the split screen setting here, full screen would also be available), because the reference level is not near the top. So I move it up by 30dB and at the same time, switch back to 10dB/div (FFT_1kHz_30dB_10dBV).



Okay, looks better now – but only at a first glance, because we now see two bugs at once. Vmax is now reported as -30.00dBV, which is clearly not right. The signal level cannot change at all, no matter how the display area is shifted and scaled. If anything, it could read +30dBV, as the reference level is now positioned to +30dBV and the displayed signal is exactly there. But in fact we did not actually change the reference level, but only shifted the displayed curve a little upwards on the screen.

The second bug that bugs me is the displayed spurious signals that cannot be there in reality.
As a comparison, I used a scope with a well implemented FFT analysis, that has proven itself in practice, and set it up very similar to the SDS 2304 scope. Just to be sure I set up twice as much bandwidth (20kHz) and doubled the number of bins accordingly, so it should be equivalent. Since I wasn’t interested in noise, I selected averaging mode – something the SDS 2304 doesn’t offer for FFT. The result convinced me, that my signal generator outputs a reasonably clean signal and the display on the SDS 2304 doesn’t show the truth. Cursor- as well as automatic measurements show that the distortion is down more than 50dB. Particularly, there are absolutely no spurs at 4 and 6kHz! Note that despite it’s just 8 bits, we manage to get about 55dB SFDR with this instrument (Pico_1kHz).




So something is wrong with the FFT on the Siglent. I already was about to cancel the test and post the buggy results, as I finally discovered that I had 70M of memory selected and that the spurious signals would go away at any other memory selection. Here’s an example for 28M of memory (FFT_1kHz_28M):



Even in peak detect mode, the strongest spurs (5, 6 and 7kHz) appear now >50dB below the fundamental, which means effectively nothing as this exceeds the dynamic range anyway. Well, this lets me continue the test and leaves the strong recommendation to not use 70M memory when doing FFT!

The FFT on this scope has no averaging for noise reduction, so it would be interesting to see what influence the acquisition modes have on the displayed spectrum. Normal and peak detect modes give quite similar results, so I won’t show a screenshot for the latter here. But what about averaging? See screenshot (FFT_1kHz_Avg4):



Memory is limited to 14k now and I have setup the test with this limitation in mind right from the start, so as not to run into aliasing troubles. I selected average mode with 4 as number of averages, so that a theoretical resolution enhancement of 2 bits could be achieved. Apart from two stronger spurs at 4 and 5kHz, that are 50dB down, nothing much has changed.

With eRes, it is something different. The noise suppression is quite strong, so this setup can be useful in certain situations. We have to keep in mind though, that eRes has a lowpass effect and might pretend harmonic levels lower than they actually are at higher frequencies (FFT_1kHz_Eres2).



As we know by now, the eRes bandwidth for 2 bits of resolution enhancement at 2GSa/s is 28MHz / -1dB and 52MHz / -3dB respectively. In this scenario, sample rate is just 200kSa/s, so we get a bandwidth of approx. 2.8kHz / -1dB and 5.2kHz / -3dB. Since our FFT-display shows 7kHz and the signal frequency is 1kHz it becomes obvious, that eRes already affects the third harmonic of the signal by more than 1dB.and the fifth harmonic by almost 3dB.
Considering this, eRes is not really applicable for FFT analysis after all, as with just 7/14k of memory, resolution enhancements has to be limited to just 1 bit so that the eRes bandwidth limiting would not affect the FFT bandwidth.


One of the major advantages of FFT is high frequency resolution at high speed – something that cannot be achieved with traditional (analog) approaches. Unfortunately, the SDS2000 fails to offer any of these two advantages. The display update rate is generally strikingly slow, at about 1 update per second, and at the same time my tests suggest that it does just a 1024 points FFT. As always, the actually usable frequency resolution is considerably  lower, as can be seen in the following screenshot, where an 1kHz sinewave is 100% amplitude modulated with a 30Hz sine. This is about the limit, where the two sidebands can be distinguished from the carrier (FFT_1kHz_Mod30Hz):



The settings for the above scenario were 5ms/div timebase, which results in a FFT bandwidth of 10kHz and then the maximum horizontal zoom for the FFT display was applied, which results in 100Hz/div. So this is 30Hz selectivity at a 10kHz bandwidth – and not 10Hz, as one might expect because it’s a 1024 point FFT.


The last test concentrates on the analysis of narrow pulses. Channel 4 is fed with a 10µs pulse at rise/fall times of about 2ns at a repetition rate of 1kHz, that is a duty factor of 1%.
FFT bandwidth was chosen to 50kHz for this test, where 35kHz get displayed.

In normal mode, we do see the spectrum, but not very well, as the amplitudes are close to
The noise floor and strong aliasing can be seen (FFT_1kHz_10us_Normal).




With average mode and 4 averages, the situation gets a little better, but only at low frequencies, as the aliasing becomes even more prominent (FFT_1kHz_10us_Avg4):



In this scenario, eRes with 2 bits of resolution enhancement brings a dramatic improvement, even though some attenuation on the higher harmonics is already visible here, which in turn also significantly reduces the aliasing (FFT_1kHz_10us_Eres2).




Conclusion:
Apart from the bugs described above (automatic measurement of max. level showing street numbers, 80M memory cause spurs), the FFT is kinda usable now – within the limitations of an 8 bit system, that is. The frequency resolution is quite poor with just (estimated) 1024 points and the screen update rate is exceptionally slow at about 1 per second.

EDIT: corrected estimation on SDS2000 FFT points to 1024.

EDIT2: Some clarification and clarification on FFT resolution and aliasing mentioned for the pulse tests.
EDIT3: Included the newest insights in the bandwidth limiting effect of eRes acquisition mode.

[Performa01]

Trigger / Automatic Measurement Bug

There’s another bug that shows if automatic measurements are used together with Math/FFT and acquisition modes Average or Eres:



The first screenshot (FFT_Eres_AutoMeasure_Bug_01) shows the situation with eRes acquisition mode, where it might not become obvious that the automatic measurements aren’t updated and just keep showing the results that were valid when the scope was last time in normal or peak detect mode.

Only hint is the trigger indicator, that says ‘Arm’ – even though the scope is actually triggered and the waveforms on the screen are indeed updated regularly. The problem becomes quite obvious though, when the channel 4 signal is removed – the scope still triggers on channel 2 as before and channel 4 becomes a flat line, but the corresponding automatic measurements keep showing the same values as before (FFT_Eres_AutoMeasure_Bug_02):

[Siglent]

@Performa01
Dear Performa01,

   Thank you for your patience and help us test the new firmware.
   What you write is very nice. It’s useful for us.
   If you have any question, Please contact us :
         support@siglent.com

Thank you for support Siglent,
Best regards.

[tautech]

New V2 FW update:
http://www.siglentamerica.com/USA_website_2014/Firmware&Software/firmware/SDS2000-V2.0-1.02.01.28R1.rar
3 MB

An error was made in attaching the SDS2000X series FW to the SDS2000 FW update link.
The wrong .ADS filename started like this: sds2kx and of course the FW would not load.

New SDS2000 V2 FW link:
http://www.siglentamerica.com/USA_website_2014/Firmware&Software/firmware/SDS2000-V2.0-1.02.01.28R1.rar

Yes I know it looks the same, but this one works.