Siglent's new product- MSO/SDS2000 Series

[marmad]

Hi Res mode now seems to work as intended but is re-named Eres and has adjustable enhancement setting of 0.5 to 3 in 1/2 bit steps. 
I've not encountered this UI before and explanation would be appreciated.

Bit size equates to the sample length for the FIR filter - more bits equals a greater dynamic range but a smaller bandwidth (same as with MA filter, but more efficient). The trade-off between bits of res. and bandwidth is (approximately):

Bits / Bandwidth
0.5  / 0.500*Nyquist
1    / 0.241*Nyquist
1.5  / 0.121*Nyquist
2    / 0.058*Nyquist
2.5  / 0.029*Nyquist
3    / 0.016*Nyquist

It's great that Siglent has allowed user-adjustment of the HiRES/ERES mode; it's something that every manufacturer should include.

[rf-loop]

ERES
http://teledynelecroy.com/doc/differences-between-eres-and-hires
http://teledynelecroy.com/doc/eres-vs-boxcar-averaging



ERES FFT is very different compared to boxcar FFT.

[tautech]

Press the stop button in hires and average mode. Does the thin trace stay in this firmware version?

Yes for all acquisition modes.

[tautech]

Bit size equates to the sample length .......

Thanks Mark.

[9a4wy]

I am waiting for new firmware long time...EU siglent keep saying 6months that new FW is coming... but nothing happens
I am planing to buy 2 pieces more(SDS2202), but only when I see what is going on with new FW.
Is that stupidity with ROLL solved???...You can't see picture till the end of scan ...unbelivable (


 

[rf-loop]

I am waiting for new firmware long time...EU siglent keep saying 6months that new FW is coming... but nothing happens
I am planing to buy 2 pieces more(SDS2202), but only when I see what is going on with new FW.
Is that stupidity with ROLL solved???...You can't see picture till the end of scan ...unbelivable (

Can you explain this ROLL mode problem? 
Please tell all settings, signal etc and what is problem. exactly.
I do not have anymore old (current) official FW. I will look it using this latest factory beta test version.
(my opinion is that delay with new FW is least partially because it looks like they have done much more than just some bugfix repair)

[9a4wy]

I made a mistake...I mean in normal scan(YT, not ROLL)...timebase slower than 100mS does not show picture till end of scan....example...you have a slow changing signal that needs timebase 50s, 14div x 50s=700s.You are without trace till end of scan, 700seconds!!!..this is really bad news...I hope they will solve that...
another one...if you rapidly change amplitude or freq in WAVE GEN, it will lost calibration time to time...you need to calibrate it.
Can you check this bugs in beta version??
K

[marmad]

I made a mistake...I mean in normal scan(YT, not ROLL)...timebase slower than 100mS does not show picture till end of scan....example...you have a slow changing signal that needs timebase 50s, 14div x 50s=700s.You are without trace till end of scan, 700seconds!!!..this is really bad news...I hope they will solve that...

This does not sound like a bug but rather a by-product of delay caused by filling the buffer pre-trigger. Can't you just move the trigger position left (i.e. earlier in the buffer) to eliminate the delay?

[nctnico]

I made a mistake...I mean in normal scan(YT, not ROLL)...timebase slower than 100mS does not show picture till end of scan....example...you have a slow changing signal that needs timebase 50s, 14div x 50s=700s.You are without trace till end of scan, 700seconds!!!..this is really bad news...I hope they will solve that...

This does not sound like a bug but rather a by-product of delay caused by filling the buffer pre-trigger. Can't you just move the trigger position left (i.e. earlier in the buffer) to eliminate the delay?

There is no reason not to start displaying a signal no matter where the trigger position is at.

@9a4wy: if you want a SDS2204 + MSO + waveform cheap then check my Ebay auction (VAT invoice no problem):
http://www.ebay.com/itm/Siglent-SDS2204-200MHz-4ch-8ch-logic-oscilloscope-waveform-gen-/131595742016

[marmad]

There is no reason not to start displaying a signal no matter where the trigger position is at.

Of course there is. Why should the DSO display the signal before the trigger?

[rf-loop]

I made a mistake...I mean in normal scan(YT, not ROLL)...timebase slower than 100mS does not show picture till end of scan....example...you have a slow changing signal that needs timebase 50s, 14div x 50s=700s.You are without trace till end of scan, 700seconds!!!..this is really bad news...I hope they will solve that...

This does not sound like a bug but rather a by-product of delay caused by filling the buffer pre-trigger. Can't you just move the trigger position left (i.e. earlier in the buffer) to eliminate the delay?

Can not call bug. (If think that bug is thing where someone have programmed something and it do not work as he think he have write it)


This is other kind of "bug". This is "bug" in design in latest official public FW. (this I can confirm because I remember this detail well)

Before trigger position, this delay can not remove. It need acquire pretrig buffer area until trigger time position. After trigged and possible fine adjusted it can push it to display and continue visible acquiring until trace ends.
If it works like this, then if user set example trigger time position to left border of display (even to zero pre trigger buffer) he can see continuous draw*) just after it first time have find trigger event. If there is continuous signal there can now see continuous visible trace update even if there is 50s/div selected - if want sit and look.

*) just like analog scope with extremely low horz speed and CRT memory (or very long persistence) on.


Just check that this is exactly how Rigol 1000Z works with very low horizontal speeds. After it finds trigger event it show pre trigger trace and continue visible acquiring.

[Wuerstchenhund]

It's great that Siglent has allowed user-adjustment of the HiRES/ERES mode; it's something that every manufacturer should include.

Being able to control ERES has been pretty much standard with LeCroy DSOs (not including the low end rebadges, though)  for at least 15 years.

But it's nice to see it on a low end scope.

[marmad]

Can not call bug. (If think that bug is thing where someone have programmed something and it do not work as he think he have write it)
...
Before trigger position, this delay can not remove. It need acquire pretrig buffer area until trigger time position.

Yes, exactly what I just said. This seems to be a regular complaint that keeps coming up from inexperienced users of these new, inexpensive DSOs that have massive amounts of memory and extremely slow horizontal time settings in YT mode. The DS2000 goes to 1ks/div - try using that in YT without adjusting the amount of pre-trigger buffer - it's impossible.

[nctnico]

There is no reason not to start displaying a signal no matter where the trigger position is at.

Of course there is. Why should the DSO display the signal before the trigger?

Still early for me  . You are right!

[marmad]

Still early for me  . You are right!

Thank goodness! I thought I had missed something obvious again! 

[9a4wy]

come on guys...it should enter some kind of SCAN mode ...like TEK low budget scopes...
I can see some advert here, so I am done...
K

[marmad]

come on guys...it should enter some kind of SCAN mode ...like TEK low budget scopes...
I can see some advert here, so I am done...
K

It's not an advert - I don't own this DSO. But if you don't want the trace to be tied to a trigger, isn't that what ROLL mode is for (SCAN mode, but starting at right of screen instead of left)?

I'm not saying there aren't other ways it could be implemented, but the logic of how it works makes perfect sense to me.

EDIT: BTW, I don't know how familiar you are with segmented memory, but sometimes that is a better solution than using extremely slow timebases.

[rf-loop]

come on guys...it should enter some kind of SCAN mode ...like TEK low budget scopes...
I can see some advert here, so I am done...
K

SDS2000 have
- Scan mode aka Roll mode. Continuous visible acquire with low speed timebases. As you told you need sit 700second and watch screen until you see something. Why do not use Roll mode. all is visible in real time. Oh...there is not trigger..

- Normal low speed acquire up to 50s/div. If you set normal trig mode and set trigger for something and you set it for waiting and then you sit 700s seconds eyes to screen and waiting..  in this point I need ask what are you doing? And why? Any other way to do it more clever?  If you work like this, how you can earn your money.

- segmented memory acquire.   There you can acquire trigged events. Example if you have 5ns pulse every around one hour and you need know 1000 sequential pulses timing and pulse shape, just turn this mode on and start... after 1000 hour just watch every 1000 5ns pulse and measure every pulse, you even know exact time when every pulse have acquired. But you do not know what have happend between these pulses but you know that there have not been trig event (or if there have been you see it)

- normal acquire and when ever you want you can stop and  look history back, up to 80000 frames back depending horizontal speed and memory setting. SDS keep this history available when ever you stop acquire...just go to history and look last acquired waveforms history.. (max 80000)


 

[nctnico]

come on guys...it should enter some kind of SCAN mode ...like TEK low budget scopes...
I can see some advert here, so I am done...
K

SDS2000 have
- Normal low speed acquire up to 50s/div. If you set normal trig mode and set trigger for something and you set it for waiting and then you sit 700s seconds eyes to screen and waiting..  in this point I need ask what are you doing? And why? Any other way to do it more clever?  If you work like this, how you can earn your money.

This is actually somehting the SDS2000 also sucks at. To make sure I just tried with the trigger point set to the left most side of the screen bu the SDS2000 acquires the full trace before displaying anything    It this a problem at low sweep speeds? Most definitely yes!
For some measurements I want a single long sweep which starts at a trigger point but I also want to see if it goes wrong during the measurment so I can abort the measurement and start it again without waiting for the acquisition to complete. My Agilent MSO7104 (SDS2000 replacement) works that way and it was most helpful for a project I did a couple of months ago where I needed acquisitions which where 15 seconds in length. Roll mode is just useless because I wanted to record clean sweeps with data from one measurement. Stopping roll mode manually is also prone to mistakes. Besides that there is no peak detect in roll mode on the SDS2000 so there is another problem there.

[rf-loop]

come on guys...it should enter some kind of SCAN mode ...like TEK low budget scopes...
I can see some advert here, so I am done...
K

SDS2000 have
- Normal low speed acquire up to 50s/div. If you set normal trig mode and set trigger for something and you set it for waiting and then you sit 700s seconds eyes to screen and waiting..  in this point I need ask what are you doing? And why? Any other way to do it more clever?  If you work like this, how you can earn your money.

This is actually somehting the SDS2000 also sucks at. I just tried with the trigger point set to the left most side of the screen bu the SDS2000 acquires the full trace before displaying anything    It this a problem at low sweep speeds? Most definitely yes!

Of course it need do better. 
It need do so that when in trigger time position trigger event find  it show what it have acquired and continue visible acquire to end of trace.
As I say trigger time position I mean it. I did not say there NEED be long pretrigger  buffer before trigger.  If peoples in Siglent want, they can easy do it so that trigger time position can adjust (related to pre trigger buffer) , other end down to zero pre trigger buffer (left side as in analog scope) and other end up to max pre trigger buffer if user select so.

Lets hope.

Scroll mode works continuously and so on but, without trigger, so in some cases when user want trig with extremely low horizontal speeds then it is not solution.

In future, of course peak detect works also in Roll mode - sure.   If not, I will eat handfull of shit.

[marmad]

This is actually somehting the SDS2000 also sucks at. To make sure I just tried with the trigger point set to the left most side of the screen bu the SDS2000 acquires the full trace before displaying anything    It this a problem at low sweep speeds? Most definitely yes!

OK, well that seems wrong. I misunderstood and thought the OP just meant the pre-trigger buffer - i.e. the part of the trace before the trigger point. If I put the DS2000 to 500s/div (for example), and move the trigger point to the far left, it works like SCAN mode after it captures a trigger - and starts displaying the slow sweep exactly as you described.

[rf-loop]

If I put the DS2000 to 500s/div (for example), and move the trigger point to the far left, it works like SCAN mode after it captures a trigger - and starts displaying the slow sweep exactly as you described.

This is how also SDS2000 need work. If user select trigger position so that there is not pre trigger then there is not. It need be under user control. Not so that where ever you move trigger position it still try keep pre trigger buffer before trigger position.  Equipment need be slave and user is master. Not opposite.

[TrioTest]

I have it on good authority that there is a new firmware release coming for the SDS2000 series.

I have a beta-version of it (1.02.01.01.19) and loaded it into an SDS2012.   Loaded OK.   Haven't had time for an in-depth study of it, but so far so good.

I have asked for a list of the improvements over version 1.01.01.37.2  but I have not recevied it yet.   

Siglent was responsive and sent me a beta-copy because of a time-stamp bug we experienced when saving long CSV files to USB.  This bug is definitely fixed.  If I hear more about the improvements in the new version I'll post it here.


Siglent in Aussieland is here:
http://www.triotest.com.au/shop/search?controller=search&orderby=position&orderway=desc&search_query=siglent&submit_search=Search

[rf-loop]

I have it on good authority that there is a new firmware release coming for the SDS2000 series.

I have a beta-version of it (1.02.01.01.19) and loaded it into an SDS2012.   Loaded OK.   Haven't had time for an in-depth study of it, but so far so good.

I have asked for a list of the improvements over version 1.01.01.37.2  but I have not recevied it yet.   

Siglent was responsive and sent me a beta-copy because of a time-stamp bug we experienced when saving long CSV files to USB.  This bug is definitely fixed.  If I hear more about the improvements in the new version I'll post it here.


Siglent in Aussieland is here:
http://www.triotest.com.au/shop/search?controller=search&orderby=position&orderway=desc&search_query=siglent&submit_search=Search

Please read even some before messages in this thread before...
https://www.eevblog.com/forum/testgear/siglent's-new-product-msosds2000-series/msg748808/#msg748808
Right place to reports is Siglent at this case. This what you have is factory beta, not public beta and it is still under development before we get public version.

Of course something what allready is now repaired and ok is ok but... there is still things what may and what need change before we get first publig  2nd  generation SDS2000 FW. It is not yet ready at all for release.

[rf-loop]

One of several things repaired. Here one example.
Gated (gate is between A and B gate markers) measurements and cursors in zoomed window.