Siglent SDS2000 new V2 Firmware

[Mark_O]

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

Well, there's always a tradeoff.  While the vastly smaller PNGs would write out to a memory stick a lot faster, it might take the CPU in the DSO longer to convert from BMP -> PNG than the time saved!  Since high capacity USB sticks are so cheap now, it hasn't bothered me all that much to be dumping BMPs.  I do agree though that RLE would be an obvious compression, which should be both easy to implement and fast to perform.  Still, not as easy as simply dumping the raw bit-map, which gets the job done.

On my WaveRunner I can basically write snapshots in about any graphic format I want, so I do PNGs there.  But that's really a PC in DSO clothing, so it has the horsepower to do that fairly effortlessly (along with a price-tag considerably higher than any of the Siglents).

I think we need to pick what we want to complain about, and for me this wouldn't be it.  I'm not sure what other affordable scopes "from this day and age use JPEG or PNG for screendumps".  Perhaps you could cite a few?

[nctnico]

My new Gw Instek GDS2204E for example saves screendumps instantly (less than a second!) in PNG format. The largest screendump I can find is 32kB and mind you: the GDS2204E also has a 800x480 screen just like the SDS2000! Sending a few screendumps in an e-mail (which I do regulary) is much easier with images which are a tens of kB than having to send several MB or needing to convert the images first.

[Mark_O]

My new Gw Instek GDS2204E for example saves screendumps instantly (less than a second!) in PNG format. The largest screendump I can find is 32kB and mind you: the GDS2204E also has a 800x480 screen just like the SDS2000!

That is excellent.  And it's not the only thing that Instek has done well on the 2000E series.  Their post acquisition Search capability is unique in it's price class, and something the competition should wake up and emulate.

But I was wondering about how other existing DSOs handled this, and the relatively new GDS-2000E didn't answer that.  I know from using them that both the Agilent X2000 and X3000 series (DSO's and MSO's) all support PNG format output.  So I checked on the Rigol's, and was a bit surprised to find that the 1000Z and 2000A both support a broad range of screen image formats:  “.png”, “.bmp8”, “.bmp24”, “.jpeg” or “.tiff” format!

So yes, your comment that the Siglent's handle only BMP format is a valid criticism, when compared against competitive units.

Sending a few screendumps in an e-mail (which I do regulary) is much easier with images which are a tens of kB than having to send several MB or needing to convert the images first.

Absolutely no doubt about that.  I'd never ship a BMP, but the extra step of running it through a converter is certainly a small hassle I could do without.  And since even the cheapest Rigol can manage PNG (and much more), I think Siglent should seriously consider rectifying that.  [ADDED:  And even if the Crunch+Save wound up taking longer than the current RawSave, I think it would be worthwhile, simply from the convenience standpoint.]

But I still don't think it's a huge consideration.

[F5D]

Any news of a new firmware version with bugfixes? Looking for a new scope and the SDS2000X hardware seems like a very good contender. However, would be nice to have the ERES and FFT working well, before making the decision. I believe the X-model uses the same firmware as the 2000?

[tautech]

Any news of a new firmware version with bugfixes? Looking for a new scope and the SDS2000X hardware seems like a very good contender. However, would be nice to have the ERES and FFT working well, before making the decision. I believe the X-model uses the same firmware as the 2000?

Note quite the same, there are different versions for each of the 1000X, 2000X and 2000 series.

Re new 2000X FW, later today is what I've just been informed.
Check here:
http://www.siglentamerica.com/support_software_15
http://www.siglenteu.com/gjjrj.aspx?id=15
http://www.siglent.com/ENs/gjjrj.aspx?id=15

[tautech]

New FW for the SDS2000 (not X) series:
http://www.siglentamerica.com/USA_website_2014/Firmware&Software/firmware/SDS2000%20P3301.rar


From the changelog:

1. Improved the user experience on the universal knob
2. Added virtual numeric keypad function in cases inputting large number is possible (push the universal knob to call it)
3. Optimized the persistence display in pass/fail mode
4. Added ASCII decoding
5. Fixed some bugs
a) Pushing the trigger level knob in AC coupled trigger mode does not bring the level back to zero
b) Value jumps up and down when setting baud rate in trigger setting
c) Arrow in decoding list displays abnormally
d) Digital channel display problem
e) All frames are not mapped to the display in sequence mode with frames quantity > 1024


Edit
fix URL

[rf-loop]

Small improvement-bugfix  in serial decoding.

It is not yet free of all bugs. One example is in image. When there is RX TX and here example TX (in this case CH2) is shut off it copy CH1 (RX here) to TX.
But, overall it works now lot of better!

Now it can decode and display also ASCII  as also HEX and Binary.
Hope they later do some finishing for visibility including also font in decode displays.

[rf-loop]

There is one open question.
Example. Sequence mode. If example in one sequence is 80000 segments. After these are acquired then acquisition of course stop and scope start do many things including display update for show waveform before it start new sequence. Question is, how many segments it display overlayed on the display before it start new sequence. It is least some hundreds in this case but how much really?

I might have finally found a way to estimate this. After several experiments I believe that the scope just displays any (the first  - or last – or whatever?) 750 +/-50 waveforms for every filled buffer.

I got these results rather consistently for 80000 segments at timebases from 1 to 10ns/div (used Ch. 4 again, but that probably doesn’t matter in this case). Not tested anything else yet.

It strongly looks like that last FW update have changed this.  I have not now enough time for test it using SDS2304 but with tiny fast test with SDS1202X give sign that now it overlay all acquired segments in sequence to display after sequence is ready. And fast look with SDS2304 looks like doing same. But, this lounge is not free. Price is that it need more process time between sequences depending amount of segments in sequence and also depending display settings.
But, imho this is low price for this improvement.

[Performa01]

It strongly looks like that last FW update have changed this.  I have not now enough time for test it using SDS2304 but with tiny fast test with SDS1202X give sign that now it overlay all acquired segments in sequence to display after sequence is ready. And fast look with SDS2304 looks like doing same. But, this lounge is not free. Price is that it need more process time between sequences depending amount of segments in sequence and also depending display settings.
But, imho this is low price for this improvement.

So this might be item e) from the changelog?

e) All frames are not mapped to the display in sequence mode with frames quantity > 1024

I think dead time in sequence mode is not that important anyway, as the whole idea of sequence recording is to capture any rare event within one sequence. Obviously, when we set up a sequence recording, we already need to have an idea of what we're trying to capture, so we can choose the parameters such as timebase and memory depth (which in turn determines the maximum acquisitions in the sequence buffer) appropriately.

On the other hand, if all buffer data is mapped to the screen and if the average trigger rate is actually higher than in standard recording mode (just with background history), it might have some uses in glitch finding.

That being said, I'm not a huge fan of the waveform update rate hype with some made-up test scenarios. Up to now I've always found other means to isolate glitches. But then again, a reasonable fast update rate does have its charm, particularly when the mask testing works the same speed, as is the case with these scopes. 

I have not updated my SDS2304 yet, but will certainly do within the next couple days and then have a brief look at what Siglent have given us.

[rf-loop]

It strongly looks like that last FW update have changed this.  I have not now enough time for test it using SDS2304 but with tiny fast test with SDS1202X give sign that now it overlay all acquired segments in sequence to display after sequence is ready. And fast look with SDS2304 looks like doing same. But, this lounge is not free. Price is that it need more process time between sequences depending amount of segments in sequence and also depending display settings.
But, imho this is low price for this improvement.

So this might be item e) from the changelog?

e) All frames are not mapped to the display in sequence mode with frames quantity > 1024

I think dead time in sequence mode is not that important anyway, as the whole idea of sequence recording is to capture any rare event within one sequence. Obviously, when we set up a sequence recording, we already need to have an idea of what we're trying to capture, so we can choose the parameters such as timebase and memory depth (which in turn determines the maximum acquisitions in the sequence buffer) appropriately.

On the other hand, if all buffer data is mapped to the screen and if the average trigger rate is actually higher than in standard recording mode (just with background history), it might have some uses in glitch finding.

That being said, I'm not a huge fan of the waveform update rate hype with some made-up test scenarios. Up to now I've always found other means to isolate glitches. But then again, a reasonable fast update rate does have its charm, particularly when the mask testing works the same speed, as is the case with these scopes. 

I have not updated my SDS2304 yet, but will certainly do within the next couple days and then have a brief look at what Siglent have given us.

Yes, roughly agree.

But I see it important if all segments are mapped to display after sequence ready. This way after sequence is easy to see  if acquired segments have some anomalies. (I do not mean "usual" thinking about rare random glitch hunting)

What I hope Siglent also improve. History view function need develop so that there is more tools. When we stop scope for looking normal bacround stored history or sequence mode captured segments I hope they add user adjustable cumulative overlay mode when run playback and/or least persistence in playback. Even many old HP have this overlay mode when playback stored segments. Fast way to look if there is anything what need look more deeply.

[Performa01]

But I see it important if all segments are mapped to display after sequence ready. This way after sequence is easy to see  if acquired segments have some anomalies. (I do not mean "usual" thinking about rare random glitch hunting)

What I hope Siglent also improve. History view function need develop so that there is more tools. When we stop scope for looking normal bacround stored history or sequence mode captured segments I hope they add user adjustable cumulative overlay mode when run playback and/or least persistence in playback. Even many old HP have this overlay mode when playback stored segments. Fast way to look if there is anything what need look more deeply.

I fully agree

Sorry if it sounded like I wouldn't appreciate the fact that now all data are mapped to the screen - of course I do! After all - like you said - we can see any anomaly at a glance and can thus decide whether it's worth investigating the sequence buffer.

Yes, analysis tools - there has already been something in that direction in the V1 FW if I remember correctly. But this is an area where we should start thinking from scratch what would be really useful.

Search for arbitrary trigger conditions and/or retroactive mask test within the sequence/history buffer might be a first idea. But with all data mapped to the screen now anyway, we could just set up the trigger or mask test without even looking at the sequence buffer and then run another test to find the abnormal acquisition...

[timofonic]

Any crazy mind wish to compare Rigol vs Siglent?

[rf-loop]

Any crazy mind wish to compare Rigol vs Siglent?

And comparable Rigol is what? Of course also boot and shoe can compare but...

If buyer is thinking between example Rigol DS1000Z or DS2000A  and Siglent SDS2000 or 2000X he do not know what he need.  There is tens on different scopes what can infinitely compare and compare and then also frequently come new models and also FW's and features are all time changing so really important thing is get answer to question "What I really need?" 

         

[tautech]

Here's a vid demonstrating the V2 FW Sequence Function with a SDS2000X series DSO:

https://youtu.be/nZTQBi4PAkg

[tautech]

New FW released for SDS2000 series....not X
Version: P38.7

http://www.siglentamerica.com/USA_website_2014/Firmware&Software/firmware/SDS2000-firmware-P38.7.rar
3.4 Mb

Changelog from the website:

1. Supported measurement in Roll mode at run state
2. Added slew rate+ and slew rate- measurement parameters and Updated the description of some parameters
3. Disabled insignificant measurements on FFT
4. Fixed some bugs
  a) Incorrect timing in finite persistence mode
  b) Values change on trigger delay, level, offset etc. when adjusting horizontal, offset and level position back and forward
  c) Unmatched side lobe suppression with blackman or hamming windows in FFT mode
  d) Skew between analog and digital channels out of spec
  e) Freeze problem in some specified case
  f) Measurement statistic does not Update in some cases
  g) Incorrect measurement on ROV?FOV?RPRE?FPRE

[TheDefpom]

I have been using my SDS2102 the past couple of days on the latest firmware, using my logic probe function (digital), and have found several little bugs.

When viewing digital, and the B1 line at the bottom of the screen shows the value, if you zoom, the line does not expand with the sample (as shown in first 2 images, so you cannot zoom into the value.

When switching zoom on and off, of you were set to low in the channel height setting (to fill the screen), it forgets that when turning zoom back off, and goes back to middle.

If you then set the height to low again, and there is a sample on screen, the sample stays at the middle point, whilst the lines move to the low one (it may also do this in reverse, I didn't try).

If using Normal triggering, to get a sample at each change, and you try to adjust the timebase to be 50ms (more than 20ms), the digital turns off, and it goes to auto triggering, when turning back to 20ms it stays on auto triggering (why does it change trigger modes?), also if the Source menu is not being displayed at the time, it also forgets which triggering input that was selected, and swaps to CH1 instead of whatever digital channel was selected, even when switched back to digital.

I wish the digital did not stop at the 20ms time, and allowed it to sample for longer time periods, it shows as 14Mpts being used, but the scope is capable of more than that, even if it reduced the sampling frequency in order to get a longer capture time.

I also noticed that even though I had turned off lines D5, D6, D7, somehow they got turned back on again, I didn't notice when.

[tautech]

Thanks Scott
When using slower than 20ms the scope goes into Roll mode but if you stay at 20ms and then if using the Zoom function the zoomed traces can be displayed at slow timebases as seen in your #5 image.

If you can add the image # to the text it may make things a little easier to follow.

I've just got a SDS2kX series (very similar) with MSO so I can work through these issues with you if that's any help.
Maybe we can do a workshop at your place to zero in on any issues?

Rob

[TheDefpom]

I also just found this bug... at a certain timebase (500us) it glitches the display, showing high and low states at the same time, until you change the timebase to 200us, and then switch it back to 500us again, then it displays correctly, odd.

I just adjusted the memory depth to 14M (it had reduced itself to 1.4M) and the glitching went away, I also noticed the sample was not actually correct, as it is supposed to trigger on D0, and yet there was data showing before D0 ? closer inspection shows the data to be garbage.

[tautech]

I see some triggering issues, you have selected CMOS levels and rising edge, is this appropriate?
Are the TTL or User defined trigger settings better?

[smarteebit]

I'm waiting for nctnico pouring oil on the flames. That should be funny.

[nctnico]

I'm waiting for nctnico pouring oil on the flames. That should be funny.

I just sit and watch the sad story continue
In a contorted way I'm glad I got so angry that I dumped the SDS2000 and bought some different scopes which just work otherwise I'd be like this:

[tautech]

I also just found this bug... at a certain timebase (500us) it glitches the display, showing high and low states at the same time, until you change the timebase to 200us, and then switch it back to 500us again, then it displays correctly, odd.

I just adjusted the memory depth to 14M (it had reduced itself to 1.4M) and the glitching went away, I also noticed the sample was not actually correct, as it is supposed to trigger on D0, and yet there was data showing before D0 ? closer inspection shows the data to be garbage.

Scott, from the info we have above I have some feedback from Siglent.

First Roll mode.
Particular to the SDS2000 series we know that Roll mode is auto engaged at slow timebase settings.
This can be overridden in both the 2000 and 2000X but each with a different method.
SDS2000: Select Horizontal key and then YT
SDS2000X: Select Roll key and toggle between Roll and YT modes.

Observed high and low glitches. (screenshots)
When the screenshot is taken (we think due to the display update) we get a displayed state where the high and low states at the same time are captured but not all the time or repetitively.
Stop the waveform for confirmation of the correct waveform.

As for the other decoding issues they are decoding setup as discussed privately and you've indicated that you'll do more with decode in the following days.

[TheDefpom]

Thanks for the feedback.

The display glitch shows up on normal trigger mode (taken 1 sample only) so it is not an issue with repeated triggering causing a doubled display), it is only triggering once in this case.

[TheDefpom]

I am just doing some more testing, if I stop the scope (from in Normal triggering), the data at the bottom does indeed scale with the sample (it does not do this when in normal trigger mode and has only been triggered once, displaying the same sample).

If I stop the scope when I have the glitch present, the glitch goes away, in the same was as if I change timebases, OR if I adjust the trigger position in either direction.

HOWEVER, the sample displayed is not correct, if you look at the first screen shot below, this sample is at 1ms, that is the true sample taken, the second screen shot (under exactly the same conditions, same sample etc) with a faster timebase of 500us if very different, not just twice is big, as you would expect it to be, as per the third screen shot, which is the 1ms sample, stopped and with the timebase increased to 500us (to be effectively the same), these are all set at 1.4M memory, which is when the glitch occurs (it doesn't do this at 7M etc)

Also I checked the YT vs ROLL setting, I already have it set to YT, perhaps this setting should "stick" regardless of timebase setting, so it stays set on the selected mode (digital) triggering, and trigger input. Don't forget it also changes the trigger input from my configured D0 inpu, to CH1 and jumps to auto triggering at the same time, even if I put the timebase back to 20ms CH1 stays, as does Auto trigger (but it does turn digital back on), basically it fails to remember the set configuration and return to it properly, it goes to some kind of defaults overriding what was set, ideally it try to be less smart here, and lets me do what I am trying to do, even if it will be slow to update the screen, I tried setting YT at the slow timebase and then set my trigger back to normal, and the trigger input back to D0, it works fine (but slow as expected).

[TheDefpom]

Also, if you look at the glitched screen shots, it looks like it is overlaying two samples of two different timebases, as they line up perfectly with some of the sample at the other timebase.